1 2 3 Previous Next

Smart and Connected

313 posts

Omate announce the ARM powered Omate X Smartwatch. the first commercially available wearable to use MediaTek's Aster (MT2502) platform, and instead of running on Android, it'll be  Nucleus RTOS to handle all the notifications.





ARM has publicly released the Server Base Boot Requirements (SBBR) Specification, a follow-on companion to the Server Base System Architecture (SBSA) specification. The SBBR defines the ARMv8 platform firmware abstractions necessary for OS deployment and boot, HW configuration and management, and power control of SBSA compliant systems with the intention of supporting today’s prevalent server OS’s.



Quick Overview


When ARM announced the Server Base System Architecture (SBSA) specification this past January, it was the culmination of over 3 years of ARM and ARM partner discussions and collaboration around the goal of being able to deliver an industry standard server platform. Being an industry standard platform runs orthogonal to the ARM ecosystem’s broad direction of embedded platform applications, but is an absolute must if ARM partners are to successfully design and market data-center servers. Being an industry standard platform maximizes customer OS choice as it minimizes new product development cycles in the OS kernel. Providing an industry standard server platform enables heterogeneous datacenters where the end-users software and OS of choice can run side by side on both ARM-based servers as well as legacy server hardware.

Another key factor that I’d like to highlight in regards to the SBSA Specifications is the industry-wide guidance and collaboration that has gone into aiding ARM’s technologists in authoring these standards. Partners, such as RedHat, have trumpeted the call for standards and best practices for server platforms:

"We are excited to help drive various server standardization efforts around the ARM Architecture, in particular the SBBR, which we deem critical to the commercial success of ARM in the Enterprise", said Jon Masters, Chief ARM Architect at Red Hat. “Together with other ecosystem partners and Operating System vendors, we have built a strong foundation for a common ARM server platform".


In short, ARM’s new SBBR specification is a key standard to providing innovative, best-fit datacenter solutions based on the ARMv8 architecture.


What’s in a Name?  What’s in the SBBR Spec?


First off, the Server Base Boot Requirements specification covers much more than just “Boot” support. It leverages (and in the process, often extends) the existing, prevalent firmware standards as the specific contact (or should I say contract?) points between the OS and the platform hardware. Let’s take a closer look at what is in the spec:


UEFI Boot Support – SBBR leverages the UEFI 2.4 standard and the UEFI Forum’s governance model for extending the UEFI spec as needed to enable UEFI Boot mechanism on ARM-based systems.  UEFI covers both boot-time and minimal run-time interfaces as well as memory maps and pointers to other abstractions such as ACPI and SMBIOS.

ACPI Support – SBBR leverages the long running yet newly minted ACPI specification, which was very recently updated to ACPI 5.1 by the UEFI Forum. ACPI describes the tables and methods used to configure platform hardware, drive system and device power states, as well as describe the hardware functionality present for the OS. The SBBR spec spells out the ACPI structures, tables, and methods necessary for describing the server hardware to the OS. The ACPI 5.1 is publicly available and includes support of ARM-based platforms.


Please go here for further details on UEFI and ACPI 5.1: Specifications | Unified Extensible Firmware Interface Forum

SMBIOS Support – SBBR lists the common SMBIOS table structures and records required for server deployment and platform asset management.

Multiprocessor Support – SBBR covers two possible methods for the booting of additional symmetric application processor cores within a single ARM platform.

First, the recommended PSCI method that is further detailed in the ACPI spec, and second, the older MP Parking protocol that was originally cooked up by Microsoft in their work supporting ARM-based devices.



Leaving Legacy Behind


One item to note is the lack of “legacy” platform requirements.  Starting clean, with modern server designs in mind for an ARM Server platform has both advantages and disadvantages. While there is a great deal of work being done up front in specifications and coding, the ARM ecosystem isn’t hindered by the inclusion of legacy HW, firmware, and OS baggage. The firmware in an ARM server does not include legacy BIOS API’s. The SOC hardware does not include legacy IO address ranges nor does it include interrupt controllers first mapped out by the IBM PC back in the early 1980’s. Not being tied to legacy implementations reduces cost and complexity of ARM-based SOC’s while also allowing for greater flexibility and innovation, which brings us back to the need for clearly defined abstractions, which are keenly delivered here in the SBBR Specification.

While we won’t be supporting MS-DOS here, we are laying the groundwork for support of your favorite server OS.


For further reading, the SBBR spec is publicly available here:

ARM Information Center

I recently spoke to Pablo Valerio from EETimes on how ARM sees itself in the fast paced wearables market.  You can read the Q&A that Pablo published by following the below link.


Q&A: ARM Mobile Targets Wearables | EE Times

RedHat Enterprise Linux or (RHEL) is a key server software platform that is deployed in many enterprise verticals today including Finance, Telecom, and Government and in Traditional Enterprise as well. Many end users today are looking for innovative solutions that can help them reduce their TCO by delivering more performance/watt/$/cu. Ft. The ARM partnership and their SoC platforms are bringing more workload optimized solutions but with a standards framework. RedHat is working with ARM to bring even more choice their customers.


RedHat has been engaged in with the ARM Server community for a long time and today marks in important milestone in that journey. RedHat announced the Red Hat ARM Partner Early Access Program today. With support from key partners including AMD, AMI, AppliedMicro, Broadcom, Cavium, Dell, HP this represents a broad range of partners from for the Server Ecosystem. In addition, today AMD announced the availability of their Opteron A1100 developer kit targeting a broader set of the firmware and software communities.


RedHat has been engaged with the ARM ecosystem on multiple fronts with their participation in Linaro with the Linaro Enterprise Group, and with the Server Base System Architecture development. Recognizing the need to enable the software and OEM development community to rapidly develop and deploy systems, ARM and partners drove collaboration with key Software, OEM and Silicon partners to help drive standards at the hardware level that can simplify software and systems development. Jon Masters from RedHat has a written a great blog on his experiences with the development of these standards in the ARM server community. Just last week there was also the release of the ACPI 5.1 Specification that included support for ARM another important milestone for community


Red Hat’s announcement today expands the reach of the ARM server community. Many of the emerging workloads are more suited to the ARM partnership approach of delivering the right size compute with innovative system integration to deliver more value to end users.

Hot off the presses from the UEFI Forum, the ACPI 5.1 Specification [July 2014] has been published. ARM support in industry standards continues to advance.



Quick Background

The ACPI Specification defines a common set of firmware interfaces between the OS and the hardware platform that enable configuration and power management of the computer system and its devices. ACPI is a prevalent abstraction method used today in PC, Workstation, and Server platforms.



Why is this ACPI 5.1 Spec release significant?

Well, to start, this is very first release of the ACPI Specification by the UEFI Forum. It is an achievement accomplished in roughly six months after years of work to move ownership of the ACPI document into a more open and widely collaborative forum as a working group under UEFI.  Instead of being legally owned and driven by a few (five to be exact) key PC industry players, the ACPI spec is now open to input from dozens of UEFI Promoters and Contributors. Amongst the list of UEFI Contributors are ARM and Linaro, as well as many other partners from the ARM ecosystem.


“After the announcement at Linaro Connect last October about asset transfer of the ACPI Specification to the UEFI Forum, we have seen very enthusiastic participants from the ARM community including silicon providers, OEMs, as well as open source and commercial OS vendors,” said Dong Wei, UEFI Forum vice president and co-chair of its ACPI Specification Working Group (ASWG).


Furthermore, this new release of ACPI 5.1 is important in enabling ARM technology to play more broadly in the aforementioned PC, Workstation, and Server markets.The original ACPI standard grew out of existing, legacy PC implementations. As such, it had several gaps for supporting hardware platforms based on SOC’s using the ARM architecture. While some of our partners began the process of adding support for ARM platforms in ACPI 5.0, it wasn’t until the migration to the UEFI Forum and ACPI 5.1 that ARM and its partners could really become involved and drive the necessary functionality.  If we take a closer look at the ACPI 5.1 specification, we can see the differences.



ACPI 5.1 Support for ARMv8 Platforms

Here is a quick summary of the changes added to the ACPI specification in support of ARMv8 platforms. As you can see, several of these items tie into existing ARM SBSA platform standards.

  • SBSA compatible Improved GIC and GIC Virtualization support
  • SBSA compatible Memory-mapped Generic Timer support
  • SBSA Compatible Watchdog timer support
  • Power State Coordination Interface (PSCI) support
  • SOC Custom clock support


With the advent of ARMv8 64-bit server platforms from our silicon providers and OEM/ODM partners,  ARM and its software partners are working to enable timely ACPI support on prevalent open-source software.


Dong Wei continues, “I am very glad to see Linux developers already contributing patches that provide Linux ARMv8 support compliant with ACPI v5.1. The successful testing of these patches on 64-bit ARMv8 reference platforms is an early confirmation of the superb quality of work the ARM community has contributed. Congratulations to the team.”


We at ARM will continue drive the definition and enablement of industry standards, such as ACPI, in support of 64-bit ARMv8 platforms. We anticipate that future innovation and architectural advances will continue to drive releases of the ACPI Specification through the UEFI Forum and we invite all our partners to participate in this endeavor. We’ll keep you posted on our progress.


For further details and light reading, the new ACPI 5.1 Specification is available here:  http://uefi.org/specifications


Author's Note: As a member of the Server Marketing Biz Dev team at ARM, I am glad to note the progress of industry standards such as ACPI and look forward to sharing more success stories as the ecosystem advances in support of ARM in the datacenter server space.

Never to be overlooked is the importance of monitoring connected Internet of Things devices, at both a personal and global scale. You need to know the status of your device; its health, battery, connection status, etc. One way to do that is through a realtime customizable dashboard, enabling you can track, monitor, and visualize your connected devices.


Enter: freeboard.


freeboard is a web-based tool that allows you to build fully customizable and interactive user-interfaces for your connected IoT devices, from dashboards, to consoles, to control panels.


And freeboard now supports PubNub, meaning that you can now monitor your IoT device's health and status in realtime. Apps and connected devices running on the PubNub Data Stream Network can now integrate data streams with the open source freeboard and customize how the information is displayed.


Monitoring is a powerful tool for any IoT use case. Say you have a number of 3G-connected, GPS-enabled, air-quality sensors attached to city-sponsored rental bikes that can track the air quality down to each city block. When in use, these specially equipped bicycles provide real-time location-tagged air-quality data that is used to create a crowdsourced pollution index map for others bikers to use when planning their routes. All that information can be displayed on a realtime dashboard that looks like this (see it in action here):




Integrating PubNub and freeboard


Both freeboard and PubNub believe in the same core design principles: ease of use, simplicity, and the idea of "it just works." In the video below, Jim Heising, maker of freeboard, gives a brief demo of using PubNub with freeboard. Additionally, feel free to check out the freeboard GitHub repository.


As we become an increasingly connected world, the importance of monitoring our devices will increase as well. Don't be left in the dark when it comes to your IoT devices!

Hi All,


My post maybe a bit controversial for this “Smart Connected” forum as it talks against IoT, pervasive connectivity or sort of “Making everything Smart” revolution. However, I thought it would be nice to get the esteemed views from the members of this group.

Please have a look at my post at Are Smart things making us smarter? | praxthoughts. I eagerly look forward for your feedback.




It wouldn’t be a false statement that we’re now living in a world of ecosystem. Instead of looking at the capability of a device and/or the SoC, the strength and support of an ecosystem has become a deciding factor for consumers. This trend is even more evident as the boundaries between service, software, and hardware are blurred, while ecosystem becomes a more important differentiator. This could explain why we have seen a huge increase in the numbers and sizes of developer conferences hosted by more tech giants in a wide range of market segments. And, ARM is no exception to this as we offer several resources to address developers’ needs. For examples, although not a conference, the ARM® Connected Community is an online platform intended to help developers learn and collaborate with other developers across various market segments. Additionally, mbed.org, initiated by ARM and a few ecosystem partners, enables developers in the embedded and IoT space, by supplying them with development platforms, information and tools needed to create devices with ARM-based microcontrollers.

What is most essential for the ecosystem is the availability of hardware platforms for developers.  With that said, I am happy to introduce HardKernel’s newest development platform, ODROID-XU3. In the past, few development platforms have included access to some of ARM’s most advanced technology, such as big.LITTLE™ technology with HMP (Heterogeneous Multi-Processing) and the Mali™-T628 GPU. ODROID-XU3 packs Samsung’s brand new Exynos 5 Octa (5422) processor, reinforced with HardKernel’s strength in peripheral designs and monitoring tool that enables developers to monitor the workload and power consumption of the quad core Cortex®-A15 processors, quad core Cortex-A7 processors, Mali-T628 MP6 GPU, and DRAM, respectively. In addition, developers can choose between Android 4.4.2 and Ubuntu 14.04 to run Khronos™ OpenGL® ES 3.0 and OpenCL™ 1.1 Full Profile with full source code access. Now that the latest and most advanced ARM technology is available to developers, they have the ability to take their innovation beyond mobile and into new and even unimaginable segments and I am thrilled to be able to witness this.

Please see the specification table for ODROID-XU3 below, and you can find more details at http://hardkernel.com/main/products/prdt_info.php?g_code=G140448267127.


Samsung Exynos5422 ARM quad core Cortex-A15 processor 2.0GHz / quad core Cortex-A7 processor 1.4GHz


2GByte LPDDR3 RAM package-on-package (933MHz, 14.9GB/s memory bandwidth, 2x32bit channel)

3D Accelerator

Mali-T628 GPU MP6 OpenGL ES 3.0 / 2.0 / 1.1 and OpenCL 1.1 Full profile

Energy Monitor

Measure the power consumption of big cores, LITTLE cores (in a big.LITTLE configuration), GPU and DRAM individually.

Accurate current sensors and voltage sensors are implemented on PCB for energy measurement.


On-board Audio codec / Standard 3.5mm headphone jack

HDMI Digital audio output

Optional SPDIF optical output (USB module)

USB3.0 Host

SuperSpeed USB standard A type connector x 1 port


SuperSpeed USB Micro A-B type connector x 1 port

USB2.0 Host

High Speed standard A type connector x 4 ports


HDMI, DisplayPort

Storage (Option)

eMMC module socket : eMMC 5.0 Flash Storage (up to 64GByte)

MicroSD Card Slot (up to 64GByte)

Fast Ethernet LAN

10/100Mbps Ethernet with RJ-45 Jack ( Auto-MDIX support)

Gigabit Ethernet LAN(Option)

USB3.0 to Gigabit Ethernet adapter (USB module)

WiFi (Option)

USB IEEE 802.11b/g/n 1T1R WLAN with Antenna (USB module)

HDD/SSD SATA interface (Optional)

SuperSpeed USB (USB 3.0) to Serial ATA3 adapter for 2.5"/3.5" HDD and SSD storage

Power (included)

5V 4A Power

System Software

Ubuntu 14.04 + OpenGL ES + OpenCL on Kernel LTS 3.10

Android 4.4.2 on Kernel LTS 3.10

Full source code is accessible via our Github.

Case (included)

Mechanical case & cooler (98 x 74 x 29 mm approx. )

PCB Size

94 x 70 x 18 mm approx.

When developing IoT devices in the lab, network connectivity is fairly easy. With a couple of devices and a server running on the back end, connectivity is seamless and low latent. However, deploying that IoT app on a global scale, to thousands or even millions of users simultaneously, is a whole other ball game. Unfortunately the Internet isn't just one network, and considerations include heterogenous networks, including cell towers, slow connectivity, fast connectivity, proxy servers, and firewalls; all things that can disrupt connectivity.InternetOfThingsHorizontal1.png

At June's MIT Technology Review Digital Summit, PubNub CEO Todd Greene took to the stage to discuss the need for a new type of network for connecting Internet of Things embedded devices. In doing so, Todd also presented the five challenges of Internet of Things connectivity. Check out video of Todd's talk below, or keep scrolling to see the 5 challenges of IoT connectivity:

At PubNub, we think a lot about IoT connectivity. So to make PubNub the best network for connecting and signaling between Internet of Things devices, we first had to understand the challenges of doing so. Presenting the 5 challenges of IoT connectivity:

1. Signaling

With connected IoT devices, reliable bidirectional signaling is essential for collecting and routing data between devices. That's where IoT data streams comes into play. Devices may be talking to a server to collect data, or the server may be talking to the devices, or maybe those devices are talking to one another. No matter what the use case, data needs to get from point A to point B quickly and reliably. You need to be 100% sure that that stream of data is going to arrive at its destination every time.


2. Security

Security is a huge umbrella, but it's paramount in Internet of Things connectivity. For example, what good is a smart home if anyone can unlock your doors? Here are three specifics:

  • Authorization: When sending or receiving a stream of data, it's essential to make sure that the IoT device or server has proper authorization to send or receive that stream of data.
  • Open ports: An IoT device is dangerously vulnerable when it's sitting and listening to an open port out to the Internet. You need birectional communication, but you don't want to have open ports out to the Internet.
  • Encryption: You need end to end encryption between devices and servers.


3. Presence Detection

It's important to immediately know when an IoT device drops off the network and goes offline. And when that device comes back online, you need to know that as well. Presence detection of IoT devices gives an exact, up to the second state of all devices on a network. This gives you the ability to monitor your IoT devicesand fix any problems that may arise with your network.


4. Power consumption

Thousands of IoT devices signaling and sending data between one another takes a toll on power and CPU consumption. With all this communication, you need minimal battery drain and low power consumption. You can't afford to use up 100% of an IoT devices's small and expensive embedded CPU power.


5. Bandwidth

In addition to power and CPU, bandwidth consumption is another challenge for IoT connectivity. Bandwidth on a cellular network is expensive, especially with hundreds of thousands of IoT devices on a network sending request/response signals to your server. That's a huge server issue and a requires a large scale server farm handling all this data. You need a lightweight network that can seamlessly transfer data between devices and servers.


Connecting IoT Devices with PubNub

IoT connectivity should be a forethought before deployment, not an after thought. Having scalable IoT network to connect devices and servers is critical for a large scale IoT app. It's essential to consider these five IoT connectivity issues. These are the types of Internet of Things challenges we've solved at PubNub. With over two hundred million connected devices connected to our global realtime network in fourteen data centers, we average 50 to 60 thousand transactions per second, peaking at over 3 million. PubNub is used to stream data and signal for hundreds of different IoT uses cases including:

  • Automotive: Connected cars need a realtime communication layer to stream data and signal between their fleet, dispatch, and the consumer on the app. Examples: Sidecar, Lyft, Easy Taxi, Gett, Zoomy
  • Home Automation: A realtime network can be used to signal and trigger actions for smart devices and home automation solutions. Examples: Insteon, Revolv, Vivint
  • Wearables: IoT wearables require a low latent, lightweight network to stream data between the device and a server. Battery, CPU, and bandwidth consumption are all important considerations that must be taken into account. Examples: 3rd Eye, AllJoyn


By 2020, it's estimated that there will be between 20 and 30 billion connected devices on the Earth. As a result, how we connect those devices should take precedence as the IoT field grows exponentially.


Blog post originally publish here: 5 Challenges of Internet of Things ConnectivityPubNub

Wearable devices have been creating quite a stir in recent months. From wrist bands through to watches to glasses and beyond, there is huge interest on how this exciting new technology segment will develop. At ARM we have been working hard with our partners to enable a wave of exciting innovative wearable devices such as Omate, Fitbit and Pebble.


Last week Google held its annual developers conference ‘Google IO’ in San Francisco. A lot of attention was on wearables based on the recently announced Android Wear operating system and featuring devices in the shape of the Moto 360 and LG ‘G’ watches and the newly announced Samsung Gear Live.  Given the huge impact that Android has had on the smartphone space it is not surprising that the Android Wear devices have been hotly anticipated.

LG ‘G’ Watch Teardown


Samsung Gear Live Teardown



We see that both watches are powered by the Qualcomm Snapdragon 400 which is packing ARM Cortex®-A7 processors running the new Android Wear operating system. AnandTech provided some additional detail on these teardowns in their article.


The challenge when designing a wearable device such as a watch is to couple small form factor with long battery life, after all the watches only have a capacity of around 300mAh due to their relatively small size as compared to almost 3000mAh in a typical high end smartphone.


ARM Cortex®-A7 represents the perfect balance of performance coupled with ultra-low power ensuring that the Android Wear watches deliver the very best user experience. It is exciting to see how ARM and its partners lead innovation in the wearables space and in turn bring new ultra-efficient classes of wearable devices to reality.


While I am not sure we are going to be able to put these devices back together, we hope that you manage to get your hands on an ARM-powered Android Wear device soon and join the wearable tech revolution!

By Joe Basques

Managing Editor, New Tech Press


A recent report by IBM said 2.5 exabytes of data were created every day through 2012. This is almost nothing compared to what we will collect in 3 to 5 years as the Internet of Things moves into reality and everything from milk jugs to the clothes we wear will contain sensors actively collecting data.


Two of the biggest challenges businesses face today are where to begin when developing their Strategic Big Data Plan, and how to lessen the “creepy factor” so customers willingly consent to contributing their data.  Gartner predicts that one-third of Fortune 100 companies will experience an information management crisis by 2017, due to the fact that many U.S. companies don’t have a clear data strategy.


As part of our ongoing series looking at the latest in Big Data, we sat down with @Anne Buff, Business Solutions Manager and Thought Leader for SAS at Enterprise Data World in Austin Texas to discuss Big Data Strategy and how companies overcome the “creepy factor” to provide a high-value proposition to their customers.


Click here to see the video

We've posted the newest technology tutorial in the ARM IoT Tutorial series, this time on device management for IoT using the OMA Lightweight M2M standard. The tutorial slides are available here:


Tutorial on OMA Lightweight M2M


There is also a video version of the tutorial on ARMflix:


OMA Lightweight M2M Protocol (OMA LWM2M) Tutorial - YouTube


Design Patterns for an Internet of Things

A Design Pattern Framework for IoT Architecture

Design Patterns are reusable solutions to common problems

Design Patterns provide well known ways to solve design problems commonly encountered in a particular discipline or problem domain. As an example, three different design patterns to handle traffic flow at a road intersection are stop signs, traffic lights, and roundabout. Each have advantages and disadvantages specific to particular traffic patterns and other contextual factors.


IoT presents design problems in many areas and at many levels in the system. There are many diverse use cases, with different resource constraints, and with many standards, products, and technologies available. How do we determine which are appropriate, what the specific advantages and disadvantages are without a context from which to evaluate their use?


Design Patterns are building blocks of architecture

Design patterns provide a way to build an end to end solution in well specified ways and to provide an understanding of the use of different components of the system in a system context. A reference architecture can be constructed from a set of design patterns, and from this the behavior of the system may be modeled and understood.


Up to this point I have focused on a set of design patterns around data models and information models for the Internet of Things, and most recently began investigating an open stack approach, where use-case appropriate end to end solutions can be built from various components and design patterns.


Next I would like to look at a set of system design patterns useful in the construction of IoT architecture solutions, with a focus on common patterns for interoperability. I have divided the design patterns somewhat arbitrarily into areas of information models, interaction models, application programming models, infrastructure models, and use case patterns.


The design pattern examples were drawn from www and internet, best practices and standards, those which appear to be successful and well known, and those which satisfy some need or solve some problem. These are only examples and not meant to be exhaustive. However, the intention is to enable covering most common IoT use cases using a set of design patterns which can use  well known standards and practices.


Each of these areas is further decomposed into a spectrum of higher level patterns built on lower level patterns. I present only a few examples of common design patterns; this is not meant to be an exhaustive treatment of the subject.

Design patterns for connected things represents the fundamental proposition of an Internet of Things; that is connecting things using networks and software. Here are some examples of fundamental design patterns for IoT:


  • Software connected to thing via a network: The fundamental proposition of the IoT is that connected software is a higher value than embedded software. Connected software is less resource constrained and can integrate more diverse data sources.


  • Virtualization: Software connecting to an abstract representation of the thing. Virtualization makes it easier to create reusable software and devices.


  • Virtualization through middleware: Allows many (web) applications to interact with things. Middleware can cache the state of the thing and minimize network traffic and power drain on constrained devices, and can also serve as persistent end point for things that aren't reachable over the network due to power cycling, firewalls, etc.


  • Middleware Platform: Allows many-to-many interactions between applications and things. Enables realization of connected environments and network effects. Can provide standard interfaces for things and application software.
  • Thing-thing interaction: Things that contain some application software interact directly with other things on local networks

Design patterns for IoT use cases describe the system level use case mapped onto high level design patterns like gateways and web services:


  • Devices talk to other devices peer-to-peer: Local network connectivity enables proximal ad-hoc networking, service federation and chaining, media stream continuity.
  • Personal tracking device uses smartphone as gateway: Common pattern for bluetooth and WiFi connectivity.
  • Smarthome local application controller and gateway: Application gateway pattern.

  • Monitor a large number of devices over a large area: Collect, filter, analyze pattern used in Smart City, surveillance systems, large scale resource monitoring.

  • People interacting with autonomic feedback loops: General purpose use case involving people and automation in defined roles. Autonomic control relieves people of the job of monitoring, but lets them be involved in high level control and exception handling.

There are many more design patterns at all levels of design. The following list contains some more common patterns based on modern web patterns and practices that are relevant to IoT architecture.

Design patterns for information models consist of lower layers of data models and representation, upon which are built higher level encapsulation and function. Some examples of information model design patterns:

  • Structured data: XML documents, JSON objects
  • Web Objects: Multiple resources at a URI endpoint, object encapsulation
  • Virtual Objects, Smart Objects: A set of resources that represent a physical thing or other data source
  • Composite Objects: Virtual Objects composed of resources from other objects
  • Hypermedia, HATEOAS: Applications use pointers to URI endpoints that externalize application state
  • Semantic Hyperlinks: Hyperlinks with embedded semantic tags, e.g. relation=value
  • Information model: Collection of semantic hyperlinks describing a resource
  • Context model: Information model layer describing context of a set of resources
  • Binding model: Information model describing dynamic binding of actions to resources
  • Resource Directory, Catalog: A collection of model instances describing sets of resources
  • Resource constructor: Information model that informs the construction of resource instance
  • Access control model: Information model that specifies access control policies and constraints for a set of resources

Design Patterns for Interaction describe how different parts of a system interact and communicate with each other, including communication protocols. Some examples:

  • REST: REpresentational State Transfer, design pattern allowing for externalization of application state in reusable, shareable resources
  • Asynchronous Events: State updates propagate through the system as they occur
  • Resource Binding: Associating a resource with an action, bridges REST to Asynchronous Events
  • Observer Pattern: A binding of resource updates to a protocol action or handler
  • Publish/Subscribe: A communication pattern where a client registers interest in a topic by subscribing, updates to a topic are published to all subscribers
  • Broker: A central service to connect publishers with subscribers
  • Proxy: A machine that provides an interface on behalf of another interface
  • Protocol Bridge: A bidirectional translator between two protocols
  • Resource Discovery: A process where resources are found by specifying attributes
  • Resource Registration: An endpoint informs a resource directory of it’s resources
  • Sleeping/Non-reachable Endpoint: An endpoint is not reachable and must participate in protocol by initiating all interactions with reachable or always-on endpoints

Design patterns for Application Programming describe ways that software and interfaces are created, managed, deployed, and used in IoT applications:

  • REST Objects: Mapping of REST API resources onto program objects in the application language, using libraries
  • Event handler, onEvent: Application code that responds to asynchronous events
  • Event driven flow: A set of application handlers that operate in an event driven graph containing series cascade and parallel constructs
  • State Machine: A logic construct where a next state depends on a set of inputs and the current state, evaluated by a set of logic rules associated with each state
  • State Externalization: The ability to create stateless application software by mapping application state onto external resources
  • Rule oriented programming: Using a set of rules or rule language to program state machine logic
  • Abstraction of applications: Stateless application software uses application templates for reusability
  • Application templates: Abstract application components with well defined interfaces
  • Modular applications: Applications consisting of one or more reusable components
  • Applications run anywhere, location independent applications: Application components can run anywhere, in devices, on local network servers, in gateways, in edge servers, in cloud, on user devices.
  • Discovery and Linking: Integrates resources into applications by resolving resource links, sets attributes in application objects
  • Object Constructor: Creates application software objects from metadata models

Design patterns for infrastructure describe how different network and device technology is used to solve problems with the physical infrastructure of IoT. How do low power devices connect to wireless sensor networks and ultimately connect to services and applications:

  • 6LowPAN edge router: Moves packets from 6LowPAN network to IPV6, does header compression
  • WSN access point: Mediated access from WSN network to IP backbone using a joining protocol e.g. WiFi
  • Mesh routing: Routing network protocol messages through other endpoint nodes in a network
  • Application gateway: Device with both network connectivity and the ability to run application components locally
  • Behind-NAT connectivity: Using reachable service or broker, applications and devices connect to each other from behind NAT firewalls
  • M2M WAN: Wireless Service Providers specialize in M2M and provide wireless WAN networks, e.g. SigFox

Design patterns for IoT security describe design patterns for IoT security problems.

  • Access control using data models: Semantic hyperlinks control access to resources based on the embedded metadata
  • Social to physical graph relationship: Well defined concepts of ownership and access delegation between people, entities, and things
  • PGP and asymmetric public-key cryptography on devices: Ways of creating SSL sessions and signing data between devices and applications
  • DTLS over UDP: Security for resource constrained devices
  • End-to-end encryption: Transmitting and storing encrypted data independent of channel encryption                                                                       
  • Device Management: Using device identity, registration, and secure key exchange


There is no one “reference” architecture for an Internet of Things. Design Patterns are a way to construct architecture solutions for specific use cases and use case classes.


The work to find system architecture solutions to Internet of Things problems has led to an obvious conclusion that there is no single architecture appropriate for most IoT use cases. The full spectrum of IoT presents a broad range of diverse use cases and resource constraints, and thus motivates a range of architecture solutions. Still, we would like to ground the discussion in a reference set of technical concepts, to help promote a unified understanding and break down the silos of thought around IoT architecture. We would also like to find opportunities for standardization and commonality.


Different architecture solutions are appropriate for different use case classes, and architecture is expected to be reusable within a particular class of use cases.Therefore it makes more sense to talk about IoT architecture as a set of Design Patterns, working together to achieve an end-to-end solution for some problem.

It's a given, this year more CIOs will shift their focus from selective IT efficiency to overall IT effectiveness. In 2014 and beyond, enterprise IT leadership will be judged on their ability to meet the demands of tech-savvy Line of Business users.


This is the type of meaningful progress that CEOs have been anticipating. But that organizational realignment won't always translate into higher budgets. Here's why.


According to the latest market study by International Data Corporation (IDC), worldwide IT spending will increase by just 4.1 percent in constant currency this year -- that's down from their previous forecast of 4.6 percent and also down from 2013 growth of 4.5 percent.


IDC believes that pent-up demand should eventually drive more business technology capital spending in the second half of 2014, as some organizations replace ageing infrastructure -- including servers, storage and networking equipment. So, what caused this dip in IT spending?


"As smartphone growth continues to cool from the phenomenal expansion of the past few years, tablet shipments have also performed weaker than expected over the past couple of quarters," said Stephen Minton, vice president at IDC.

Cloud Services will Disrupt Traditional IT Budgets


Around 10 percent of software spending will have already moved to the cloud by the end of 2014, while Infrastructure as a Service (IaaS) will represent 15 percent of all spending on servers and storage.


While this shift is creating significant disruption, it's also driving equally significant short-term opportunities for smart CIOs and IT managers that can successfully deploy cloud-based solutions.

Meanwhile, both cloud and traditional IT spending will be driven by the underlying demand for server and storage capacity, fueled by the data generated from the previous explosive growth of mobile devices in the workplace.


The opportunity to extract value from this accumulated Big Data repository is also driving strong demand for analytics tools. How they decide to deploy these tools will be the subject of much debate among IT leaders.


Many organizations will choose a gradual journey to adopt cloud services -- with security, reliability and regulatory factors in mind, they'll likely deploy more open hybrid cloud solutions.


Global Pockets of New Business Technology Spending


Based upon IDC's regional assessment, Western Europe is forecast to reach IT growth of 2 percent in constant currency terms, as most countries continue to shake off the debt crisis and return to a more stable business climate.


Similarly, business confidence is gradually improving in the U.S. market, after the sequester and government shutdown of last year. Server and storage spending will rebound to positive growth after last year's slowdown, while IT services growth will accelerate to more than 2 percent.


In Canada, IT spending growth will accelerate from 3.3 percent last year to 5 percent in 2014 -- mostly due to stronger spending on PCs, servers and storage.


Japan is a different story. The prior demand was largely consumed in 2013, when the government's deflation-busting policies boosted business confidence and when IT buyers moved to take advantage of lower prices before new taxes came into effect at the beginning of 2014.


As a result, IT spending in Japan increased by 3.4 percent last year, but will decline by 1 percent in 2014.

I don't know about you, but when I look at my smart phone in the palm of my hand, I am awestruck. I am awestruck at its functional magic and how such devices have transformed society in less than a decade (with more to come).

Then I think about the Internet of Things (IoT) and get that same feeling. A recent (and excellent) World Affairs Council panel, hosted by Cadence, laid out the promise and some of the potential peril with the coming IoT buildout. IoT will surely help society do more with less, drive efficiencies, and light a fire under economic growth, but concerns around change-averse industries and user privacy may delay that promise, the panel agreed.

The sold-out event featured executives from GE, ARM, eBay, and Cisco and was moderated by Aleecia McDonald, director of Privacy at Stanford Law School's Center for Internet and Society.  (Right, from L-R, panelists Stephen Pattison, ARM; Katherine Butler, GE Software; Guido Jouret, Cisco; Steve Yankovich, eBay; moderator Aleecia McDonald, Stanford)Internet of Things World Affairs Council Panel At Cadence

"I think this is going to be a new industrial revolution," said Stephen Pattison, vice president of Public Affairs with ARM. "If we get IoT right, it will unleash economic growth and embrace whole swathes of people all over the world, creating jobs, delivering services, making lives better for everyone."

Guido Jouret, vice president and general manager of Cisco's IoT Group, teed up the potential that comes with billions of new connected devices--27 billion of them in the next few years.

Today, about one percent of devices with electrical connections are connected to a network. By 2030, the world will need 40 percent more energy, and half the planet won't have access to clean drinking water. Half of all food is wasted or rots, he added.

"We know that the answers are not 'let's grow more food or find more water.' We have to take advantage of the infrastructures we have today, and one of the ways to do that is by connecting the unconnected."

Pattison said one aspect of IoT--the industrial Internet--has "enormous relevance for the future," especially the prospect of repatriating manufacturing to countries and regions that have lost that to lower-cost areas.

"Once you get IoT in manufacturing, that whole dynamic changes," he said. Factories can be remotely managed and don't have to make the same thing day in and day out, he noted.

But where some industries stand to benefit enormously from IoT technology, others may actively hinder its growth and adoption.

For example, "The medical environment has done a great job resisting change," Jouret said. "It's all about expert knows best. 'Just take (our) advice.'"

Technology isn't the major challenge to the growth of IoT, although there are some areas of improvement, notably algorithms and artificial intelligence, according to McDonald, who noted that AI has for decades been called the technology for "20 years from now."

Jouret acknowledged that while algorithms today aren't as robust as they should or will be, systems benefit from massive amounts of data.

"The weakness in the algorithms has, to some extent, been offset by the richness in the data. Brute force Big Data approaches provide pretty good results," he said.

Jouret cited Google Translate as example of an AI-driven application that's not perfect but works for many users.

Panelists generally agreed that the industrial applications for IoT will surge much faster than consumer applications because the business models--and efficiency gains--will be compelling. In addition, the privacy concerns are less.

But privacy will play some role in industrial applications and for more consumer-facing uses it threatens to stall growth, the panelists agreed.

Said Katherine Butler, general counsel with GE Software:

"A lot of IoT will get built out by industries. The front end of that on the consumer side is one that needs a different debate. It should not just be the application of the technology without a thoughtful discussion, and we're going to absolutely have to do that on the consumer side so people do understand what's happening with their personal data."

Pattison went further, saying that even devices in the industrial space need to be considered:

"The IoT will surround you with objects that stream data. Sensors won't have user interfaces and it'll be harder to set permissions for where the data is going and how it's going to be used. So unless we get a framework for how we handle data, we run the risk of more freak events...and debates that head off course and to some extent holds up this future development."  

He called for "more sensible, measured debate" that involves a variety of stakeholders who establish a framework in which consumers can feel confident about how their data is handled. And this needs to be led by industry, he added.

But IoT technologies empower people and hold the promise of changing the relationship between doctor and patient.

Steve Yankovich, vice president of Innovation and New Ventures at eBay, used a crowd-sourcing example and concerns about privacy. What if a patient with heart trouble was perfectly willing to share data among a group of patients with similar conditions to crowd-source his own treatment?

"If you think it's going to help save your life, you're going to let your data go," he said.

On the other hand, in response to an audience question about whether we can ever hope to wrestle back control of our data from companies, Yankovich offered a different example: The connected home. Today's vision sees various consumer appliances connecting to the cloud to manage energy or order goods to replenish, say, refrigerator stores. But we could architect the smart home such that it's a walled garden and only specific requests leave its confines, he argued.

"The algorithms and business logic stays in the home," he said. "'What you can do for me' is all that leaves the building."


Brian Fuller

Related stories:

--Embedded World 2014: Confronting IoT, Automotive, and Security Challenges in Electronics Design

Filter Blog

By date:
By tag: