IASA identifies the Internet of Things, or IoT, as a key game-changing technology and an industry trend.  The internet of things is defined as a communication pattern between an embedded compute function – that is, a CPU or other computation device, within another machine or object – which can connect to either other IoT objects and/or a service provider network (or the Internet) for context-aware capabilities.  Typically, the “thing” which has onboard computation capability achieves higher-value capabilities by the interaction with its environment, other “things” in the same domain, or even other computational capabilities on the network.  This trend is evident in many different industrial domains and the enhanced capabilities have widely varying value propositions.  For example:

• An automobile may have an array of sensors onboard, local and broadband communications, and a telematics control unit, to both coordinate movements to avoid accidents with other cars and provide geolocation data to the driver’s parent, as well as bring services into the vehicle such as maps or entertainment.
• A wristband with sensors for heartbeat and geolocation may be able to transmit data back to the owner’s running log in the cloud and provide fitness coaching and directions to the jogger
• A drone with a camera may be able to overfly a farmer’s field and send back imagery which can be combined with weather data to provide optimal watering and fertilizing instructions to the robotic tractor following behind
• An automated home or office might contain sensors for heating and cooling and communicates with the occupant’s cellphone to warm up the space when returning from a trip away or identify when electricity usage is suboptimal (lights on at night, for instance) to a building manager
• A chemical manufacturer has an older plant that gets retrofitted with some electronic control systems which can predictively alert headquarters when a high-value pump may be nearing its maintenance or failure window, automatically requesting a technician visit.
• A parent working with their daughter on a school science project uses some off-the-shelf components to build a system for the science fair to monitor her blood pressure during the day, which a local healthcare provider notices and helps the parent make a new product for the local employers to distribute to their employees to stay healthier.

This trend and type of distributed system creates new business models and benefits consumers with new capabilities for traditional devices, makers, product owners, and system architects.  IoT development can be undertaken by hobbyists through to large-scale product companies in dynamic industries.  The importance of this trend lies in its ability to transform product markets and bring enhanced capabilities – often higher efficiencies, dramatically lower costs or new contextual awareness – to the end owner and operator.

Early Machine-to-machine (M2M) communications consisted of remote machines relaying data to a central computer which acted in a supervisory or controlling role. Decisions were centralized, with unidirectional data flow and security based on isolated network segmentation.  One change which helped start a broader IoT trend has been the gradual adoption of standard internet networking protocols over previous analog or proprietary ones.  In IoT, many systems designers still choose proprietary networking connectivity providers – using open standards protocols on network segments which may offer improved SLA over other options (such as public Internet).  The proprietary or multi-vendor (“open”) network segments are interoperable by the choice of the IP protocols and bridging sometimes does occur.

The convergence of information technology and operational technology (“IT/OT convergence”) was also observed in the early 2000’s as some of these formerly isolated systems could be augmented with communication processes to provide insight into operations and manufacturing processes on a much larger scale, or across geographies.  This provided essentially data streams from distributed sensors to a central computing capability to provide better analysis, like telemetry sent from a rocket back to earth.

Finally, advancements in the robotics fields generated interoperable and significantly smaller (and hardened in some cases) components for the distributed systems so that hobbyists and device manufacturers could explore compute and sensing capabilities in new classes of manufactured products.  Communications modules and sensor modules both became smaller, to the point where it is feasible to put combinations of capabilities – including compute, storage and networking – in form factors as small as a coin.  Typically, these “mini-computers” or embedded computers could now run standard operating systems and programs, and track sensor data from their local environment in real-time.  This data can be processed on the “thing”- or device – or could be shared with proximity devices (peers) or sent to more powerful compute capacity located elsewhere – in a manufacturer’s datacenter or a cloud-hosted environment.  The communications with the device can also be bi-directional, allowing commands, applications, multi-media or other information to be sent to the device as well, enabling new capabilities and new sources of value for commercial systems.

An area of related interest is the nature of these “back-end” or aggregated services provided: with the advanced in machine learning, artificial intelligence and data warehousing, the processing of device data streams from many hundreds of thousands of independent[1] “things” gives unprecedented ability to analyze varied deployments in different conditions and locations to provide insights into how they may be optimized.  This is discussed in the trend on business intelligence elsewhere in the ITaBOK.

[1] Who could ever need more than 100K things?  Brian and Shri, 2016

The architect faces both a novel challenge and can add significant value in the design and implementation of IoT devices for their organization.  The IoT trend – though it may be enabled by technology changes- is fundamentally a new business model which enables devices which previously had little or proprietary connectivity outside their “boxes” to add new services which are context-aware for the owner or user of the device.  We have seen some of these above and have a longer list of use cases below: new ideas for these technologies emerge daily!  The architect has two main roles through the design of such a system: 1) to work with the business stakeholders to conceptualize the business model and develop guideposts like cost and schedule for the system implementation, and 2) simultaneously develop the prototype solution in a rapidly changing technical landscape while planning for the future.

From a business model perspective, there is usually a starting “device” which we will modify with hardware, software and connectivity to add capabilities.  The architect will develop the technical specification for these changes and likely contribute to the overall roadmap for this new device, whether that is taking a CF lightbulb and adding programmability to it or a larger set of systems like an automobile or skyscraper and providing incremental value propositions over a longer expected lifetime.

Some of these starting devices may already be in the marketplace or they may be repurposing an internal device or tool into the consumer marketplace.  The architect should consider lifecycle concerns as part of this roadmap: for instance, when will v1.0 ship, how will consumers get the device and get connected, what will support look like, what if a change to the device needs to be made or an upgrade is available (migration between versions)?

One critical business decision to make is how the device will be sold: will it be direct to consumer? Through an established channel? Will it be the same business model we’ve had in the “unconnected” version – a single transaction, or a monthly revenue stream?  Will the consumer aggregate the capabilities themselves – as in a toolkit – or are we providing a true solution out of the box?

While planning the evolution of the connected device, the architect and business manager will likely go through deployment phases such as:

1. An initial business proposition
2. An initial (“working”) prototype for internal users or key early customers
3. A first version in market (possibly a minimum viable product)
4. Subsequent improvements to either that initial version or fully new purchased IoT devices per roadmap

At each of these phases, the IoT product owner will assess functionality, risk, cost and schedule to the next phase.  The architect can change technologies for each or any component in the system as the prototype evolves to version 1.0.  It is important to ask the stakeholders what their priorities are: whether final system operating costs or speed to market, whether specific functionality or lower risk profile.

The diagram below gives us a first look at this distributed, “Internet of things” systems architecture and the components we will talk about in later sections.

The device, or “thing,” which will be connected to its environment is represented by the blue gears on a blue background.  It would typically contain a CPU – often described in domain terminology as an MCU, TCU, GPU, etc. – with onboard storage, networking components, power, and sensors.  This is usually fabricated on a “green board” or prototype board or normal motherboard backplane (at scale), and these components will live in a single assembly (mounted in the original device).  The communications components are often prefabricated microchips with communications antennas built in for protocols such as Zigbee, X10, TCP/IP (WiFi or even self-routing), or Bluetooth.  The sensors similarly are “off-the-shelf” and may be cameras, infrared, temperature, motion, location/position (including GPS), pressure/impact, voice or sound-activated or recording, equipment monitoring[1], etc.  These are a critical part of the business case and may have industry standards which apply to their usage.

The device often has an interface for the owner, operator, or user to interact with directly, either on the device itself (such as a touchscreen) or able to communicate remotely to the device, such as a Google Nest™ unit which interacts with the home HVAC system located elsewhere.

[1] Such as for a pump

Image courtesy of Brian Loomis, BVStrategic.com, 2016

The device may interact with the local environment (shown as a cloud, representing weather sensed by the device) and may have local-area communications with other similar devices.  If the device does not have a direct human interface, we call in “headless” indicating that the device is controlled remotely, for instance on an underwater robot.

Finally, IoT devices usually communicate over wide-area networks to a datacenter for additional processing.  This wide area network could be a private network or over internet, possibly even a connection supplied by the owner of the device (e.g., home WiFi connection or a tethered phone IP connection).  The backend datacenter could be a public cloud service or private datacenter hosting as well, and information services provided there can be either sent back to the device or may be accessible through other means (see discussion below).  The diagram is representative only.  Many IoT systems do not have all of these components.

Use cases for IoT

There are a myriad of different use cases so far developed for Internet of Things and this section only provides a short list of some possible areas.  IoT applies in almost every industry and each domain has many current exploratory use cases under active prototyping.

Some example industries, with associated use cases, include:

• Agriculture – automated tractors, surveillance drones
• Automotive – V2V communications (accident avoidance), self-driving cars, infotainment, performance
• Construction – smart buildings
• Fashion – color-changing fabrics
• Health – air & water purity, wearables for exercise, tracking metabolic processes (insulin)
• Industrial (process and discrete manufacturing) – predictive maintenance, robotics for hazard remediation / environmental monitoring
• Military – drone swarms, surveillance, force protection
• Realty and property management – single family home sales, big data market assessments, low-income housing
• Retail sales – proximity detection and advertising
• Rocketry – video feeds, weather

The following image represents the companies involved in just the “wearable” market as of a couple of years ago.

Image courtesy of Craig Dudenhoofer, http://wearableworld.com, 2012

This section describes some of the changes which are important for the architect to understand on the technical side of the design of IoT systems.  Many of these areas have changed significantly over the last ten years or are new areas unfamiliar to architects who have worked primarily on software-only projects.

The IoT system (as shown above) is a composed system of both hardware, software and networking sub-systems.  The hardware components of the actual device are small board-sized elements and require electrical engineering as well as embedded systems skills.  Some typical backgrounds for architects in this area would include experience with Windows Embedded devices, small AMD or Intel boards (e.g., Galileo), or maker experience with hobbyist boards like Arduino or Raspberry Pi.

The networking experience required ranges quite broadly depending on the use case: if the operator of the device is using wireless home or business-provided internet routing, then traditional TCP/IP methods are all that is required.  If the device has peer-to-peer capabilities, then familiarity with the selected standard is useful.  If the device has WAN communication capability – as found in automotive or robotics applications – then the architect will need to understand private networking as provided by AT&T, Orange, Verizon, Deutsche Telekom, Cisco, etc.

The architect will also need to select much of the software platform for the datacenter, including ingress or ingestion of telemetry from the large number of devices, parsing and routing of this telemetry to command and control systems and back to devices, interaction with user and datacenter (possibly by mobile phone), and any higher level analytical capabilities.

Many of these skills may be new to the architect, and by virtue of selecting many of these technologies, the architect may play a role in training the broader team on these.

As the business case for IoT is often different from previous product implementations, the architect should evaluate the quality attributes for the ones which are most important in this specific development.  Some of the attributes which can be significant for IoT projects include:

Cost: the architect may have to build a new cost model for the IoT device, including both initial deployment costs (which may include previously inconsequential costs like new product marketing, logistics, etc.), and operating costs.  The parameterization of this cost model should be revisited frequently as the IoT application goes from prototype to selection of version 1.0 vendors and more is known about the adoption curve.

Security: since the device is connected either to other devices, the Internet or back-end datacenter assets, and possibly contains PII, a full security risk profile and remediation effort should be undertaken.  The device could be hijacked, leading to PII loss, corporate data loss, or potentially modifying the object’s behavior in illegal ways.

Scalability: One of the goals for most IoT projects is the large number of connected devices, often numbering in the millions.  The architect plays a critical role in identifying and correcting scale issues as the system is developed; these could arise in any implementation area from the on-device performance, to the network traffic to the ingest and message routing in the datacenter.

Performance: Often being a consumer-facing device, performance can be measured with HMI metrics.  There may be other, domain-specific metrics required such as safety-critical response timing or verification of command transmission.

Reliability: If the product is a new offering, the usability and reliability of the device for purpose affects market perception and ultimately sales of the device.

Usability: Also, if the product is new in market, the purchaser or owner of the device should be able to quickly determine that it is working initially.  Prior internal product offerings may not have been subject to rigorous user-acceptance criteria and some “productization” may be required in this area.  For example, if the onboarding of the device requires network access, the device may have to alert the user to enter a passcode, which – if a complex process – could lead to dissatisfaction.

Manageability: Speaking to later in the lifecycle, there will ultimately need to be at least software changes to the device either to fix known issues or to add new capabilities.  The architect should be able to sketch out how these updates will happen.

An end-to-end high level architecture of an IOT system would consist of the following elements:

• A large number of connected devices. These are the sources of data and the “remote-controllable” devices.
• An aggregator device or service for these peripherals which would act as an internet gateway for these devices
• A cloud service which would be responsible for logically aggregating the peripherals for the end-user, like the Azure IOT service, or services running off Amazon AWS.
• A comprehensive protocol system that enables end-to-end communication between the cloud, the router and the peripherals. Examples are RESTful API/HTTP, MQTT, AMQP, CoAP, etc.
• An access system for end-users to retrieve information from, or control, peripherals
• A comprehensive security architecture for data privacy

The High-level architecture for non-cellular network-based IoT infrastructure is shown in the figure below.

Technologies like LoRA(TM), SigFox, Ingenu and the 3GPP technologies ( Nb-IOT, LTE Cat 1 and Cat-M) attempt to provide reliable, low-power and efficient data transfer to a large number of IoT nodes spread over large areas (as opposed to the non-cellular versions, which operate over smaller areas). These technologies target applications which have small data transfer needs.

• Nb-IOT: Supports tens of kbps (bandwidth), and is designed to work at extremely low battery power especially in deep coverage. According to the GSMA, it can support up to 10 years of battery life. It should be able to coexist with 2G, 3G and 4G mobile networks. It uses the licensed spectrum for wireless communication. Does not support connected mobility.
• LTE Cat 1: Supports higher peak data rates, and also supports VoLTE. Has full mobility support.
• LoRaWAN: Driven by the LoRa Alliance(TM). It uses a significantly different technology in the Baseband and network access than the 3GPP-based networks. The underlying PHY uses LoRa(TM) (licensed by SemTech). The data rates for LoRaWAN range from 0.3 kbps to 22kbps and one GFSK data rate at 100kbps for Europe. In North America, the data rate is 0.9 kbps due to FCC regulations. LoRa nodes talk to a Concentrator (or a gateway) which is connected to the internet infrastructure for connectivity.