IoT Platforms – Part Two: Local Intelligence Platforms


Internet of Things hardware and software platforms provide local intelligence sitting between the intelligent things and the internet/cloud applications. In some cases, the bulk of the end-to-end solution’s intelligence and intellectual property resides in these local platforms.


In IoT Platforms–Part One: A Framework for Understanding This Maze, we laid out ChainLink’s IoT (Internet of Things) Platforms Framework and discussed hardware platforms and Device Management Platforms.In this article we examine Local Intelligence Platforms and Gateways. Local Intelligence in the context of IoT refers to processing that happens between the sensors/devices and the wide-area internet connection. For more background on the concept of local intelligence and real-world examples, see Distributed Intelligence in the IoT and IoT Distributed Intelligence Examples.

Figure 1 – Local Intelligence within ChainLink’s IoT Framework

Local IoT Intelligence Ranges from Very Simple to Very Complex

The complexity of local intelligence for IoT varies tremendously. At one extreme might be remote sensors with built-in cellular communications capabilities. In that case, there is relatively little local processing going on, perhaps monitoring the sensor readings to only transmit data when the readings change beyond a certain threshold. At the other extreme are large-scale site-wide systems such as manufacturing plants, oil platforms, smart mines, and smart office buildings. These tend to be architected with a hierarchy of devices, subsystems, cells, lines, and so forth1 that exchange data and control messages, forming a sophisticated web of local intelligence.

Designing these complex systems requires a Systems Engineering approach and often involves systems engineering tools2 that help designers model, simulate, design, and build these local intelligence systems. Increasingly systems from different providers use open APIs and standard protocols to communicate between heterogeneous components and subsystems.

Offline Systems and Knowledgebases

Source: NIST
Figure 3 – Schematic of Automated Welding
Distributed Intelligence Components

Local intelligence often uses data and instructions generated by offline systems. For example, in the automated welding of automobile chassis on a plant floor, there are several pieces of data/knowledge generated offline that are used by the local system to direct the robots performing the welds:

  • CAD drawings — These are created by vehicle designers and define the shape of the chassis, materials, joints/weld points, and other details needed by the autonomous welding robots.
  • Welding Knowledge Bases — Contain knowledge about materials, voltages, sequences of welds, number of welding passes, optimized welding paths, and so forth.
  • Predictive Process Models — Predictive algorithms that model and define the optimal movements, actions, and results for the welding robots for a broad range of tasks and circumstances.

It may be a stretch to designate these offline systems as IoT platforms, but certainly the knowledge and data generated by them clearly comprise an essential input required for the successful real-time execution of the tasks at hand by these IoT systems (in this example the automated welding system).

Custom Embedded Code

The majority of local IoT intelligence exists as custom code written for specific embedded processors. In that sense, the platforms involved are the traditional embedded processing tools, such as embedded microprocessor platforms (e.g. ARM and many others) and software tools (Real-time OS, development environments). In the past, I would have said it is a stretch to call these IoT platforms. However, increasingly these are being used to support IoT implementations and many are being marketed as IoT platforms. We discussed these in part one of this series in the section IoT Platforms from the Chip Makers.

Local Intelligence ‘Appliances’

In addition to the intelligence provided by embedded processors, there are a growing number of standalone local computing appliances designed to provide intelligence within IoT systems. We are using the word ‘appliance’ in a broad sense here to include:

  • IoT Gateways — we are seeing more and more IoT gateways, designed specifically to sit between the Internet and the ‘Thing’ in IoT.Intel, Advantech, Freescale, NEXCOM, TI, and others have introduced IoT Gateway products and/or reference designs. Some appear to be simply rebranding of existing broadband gateways. These products provide connectivity for non-IP devices, but most can also do filtering, processing, transformation, aggregation, and other functions on the IoT data, as well as sending control message back to the IoT devices.
  • Edge Processors — Edge processors come primarily from network device companies to fulfill the need for more server-like processing combined with their network router capabilities (e.g. for providing deep packet inspection). Some companies (e.g. Cisco with their Fog Computing Platform for IoT) realize this architecture can be useful for IoT solutions.
  • Smart Readers — Providers of RFID readers are building increasing amounts of processing power and intelligence into some of their readers (such as Impinj’s xArray). These can provide local intelligence and processing for RFID and other local IoT devices.
  • PLC, DCS, SCADA Processors — Programmable Logic Controllers (PLCs), Distributed Control Systems (DCSs), and Supervisory Control and Data Acquisition (SCADA) processors provide local intelligence in various industrial automation settings, such as factory automation, building automation (e.g. elevators), material handling systems, and so forth.
  • Appliances — Computing appliances, such as those from IBM and others, are being repurposed or specifically designed to address IoT requirements.

Thus a broad range of local computing ‘appliances’ provides the infrastructure for local intelligence well beyond the processing power embedded in the things themselves.

Distributed Workflow/Analytics Systems

There are several companies providing distributed workflow and/or analytics platforms aimed specifically at IoT. In some cases these are companies that set out to build an IoT application and decided they needed a way to distribute the intelligence across the IoT network. One example is Entrigral whose TraxWare includes workflow ‘Bots,’ local agents that provide workflow logic that can be distributed across cloud, desktop, mobile, and edge devices. GlobeRanger’s iMotion Platform provides a componentized workflow architecture that makes it easy to build and distribute IoT applications. Some, such as Reylabs and ParStream, provide distributed IoT analytics platforms.

Domain-specific Local Algorithms

Source: Impinj

Some companies are focusing on solving domain-specific problems using local intelligence (algorithms executing partially or exclusively in the local IoT environment). One example is Impinj’s Item Intelligence. This involves taking in raw RFID reader data and turning it into higher-level intelligence about an item with the environment. Higher-level applications are not interested in every individual RFID item data read by the reader. Rather they are interested in item-level intelligence — i.e. meaningful events such as an item was moved from the back of the store to the shelf on the sales floor, or it was tried on by the customer and then put back on the shelf, or it was moved to the wrong location. Creating this type of intelligence requires building up a rich library of algorithms over time to interpret the low-level reader data. Those algorithms take many man-years of engineering effort to refine. They constitute deep domain-specific knowledge that runs largely in the local processors (in this case smart RFID readers and local appliances). That intellectual property is often very specific and hard for others to duplicate without a lot of time and effort.

Source: Image by Driving_Google_Self-Driving_Car.jpg: Steve Jurvetsonderivative work: Mariordo, CC BY 2.0, via Wikimedia Commons

Autonomous vehicles represent another example of domain-specific algorithms. In this case, solution providers are building up libraries of algorithms for all the various sensors so that they can recognize the enormous variety of environmental circumstances they may encounter on public roads and be able respond appropriately and safely. Domain-specific algorithms are often not run exclusively locally, as part of the intelligence may reside up in the cloud. However, often a major portion of the accumulated intelligence resides locally because of various requirements, such as the need for very low-latency real-time responsiveness, the ability to continue operation in a disconnected mode when no network is available, and network bandwidth constraints that mandate processing enormous quantities of local data and converting it into much smaller packets of higher-level intelligence.

Local Intelligence IoT Platforms Take Many Forms

We have just scratched the surface of the types of platforms that help enable local intelligence in the IoT. It should be apparent that they are quite varied, including hardware appliances, distributed modular intelligence systems, and a huge variety of domain-specific local processing systems. This is an area of IoT that doesn’t get as much attention as it deserves, but is a hugely important component of many IoT systems.

1 The hierarchy of local intelligence obviously differs from one environment to the next — i.e. in a manufacturing plant it might be embedded-controller | device-level PLC | work cell-level PLC | production line controller | site-wide controller.In a mine it might beembedded-controller | vehicle sub-system controller | vehicle master controller | mining truck coordination system | mine-wide management system. — Return to article text above
2 For example PTC’s Systems Engineering Solution. — Return to article text above

To view other articles from this issue of the brief, click here.

Scroll to Top