Implementing Industrial IoT Sensors

How applying REST architecture principles when creating a temperature sensor, for example, could deliver both cost and time savings.

The Industrial Internet of Things (IIoT) promises new levels of operational efficiencies for companies that use it by combining advanced analytics with ubiquitous sensing and IT technologies. As with most emerging technologies, it may be difficult to separate the hype from the reality. You might find yourself asking, “Is IIoT real, or just fluff?” and “How is IIoT different than traditional industrial automation?”  Allow me to quickly address both of these questions and in the next section I will address how you might go about designing an IIoT device.

Industrial IoT found its roots in the consumer IoT movement where smart devices, combined with cloud-based analytics, can provide insights to the consumer on everything from sleeping habits to improving their golf swing. Once industrial markets saw the utility of IoT, they began to explore the possibility of its use. Thus, IIoT was born. Now IIoT is one of the fastest growing segments of IoT with a compound growth rate of 28% (IIoT World, 2018). The IIoT phenomenon is certainly real.

The IIoT Industrial Internet of Things differs from traditional industrial automation in three significant ways. First, where industrial automation focuses primarily on the instrumentation and control of specific processes, Industrial Internet of Things seeks to gather data from virtually every measurable performance aspect of operations. The combination of this ubiquitous sensing with the second distinction of IIoT, advanced analytics, promises actionable business insights to improve efficiencies to the automated facility. The third and final distinction of IIoT is leveraging IT technologies and methods to reduce deployment time and costs while strengthening cloud analytics and back-end IT systems.

IIoT Sensor Example
To make this discussion more concrete, let’s take the example of a temperature sensor. In an IIoT context, it acts as a micro server. It is capable of measuring temperature in a variety of temperature scales. To make it useful for control applications, it can also compare the current temperature measured by the sensor with several different temperature thresholds. Since this device is stand-alone, we also may want to add identifying information like model number, as well as logging capabilities. A block diagram of this device is shown in Figure 1.

Figure 1: Block Diagram of Temperature Sensor

Client-Server Architecture
As a server node, the services the sensor might offer to authenticated clients are: getting the current temperature, setting temperature limits, viewing identifying information, subscribing to alarm messages, and interacting with the device’s logs. There are a variety of ways this can be done, but the model that has gained wide acceptance in the IT realm is REST application interfaces.

Representational State Transfer (REST) is an architectural style based on five key principles: stateless client transfers, cacheability, layered system, optional code on demand, and a uniform interface. A brief run-down of these principles and how they apply to IIoT is given below:

Stateless Client Transfers—The server does not keep track of client state between transactions. Every client request provides enough context for the server to determine the appropriate response. This is essential in IIoT if servers are to be implemented with microcontrollers and limited hardware resources.

Cacheability—Allows static information about a specific server node to be stored on client systems. The first time the client reads the data from the server, it is stored in memory on the client side. Further accesses to the data can be done directly from the client’s memory. This can greatly reduce network traffic and improve scalability.

Layering—The architecture allows for intermediate servers to proxy (layer) information from servers downstream. This allows for intermediary nodes to aggregate representations of our sensor nodes and act as transparent gateways.

Code on demand—Servers can temporarily enhance the capability of clients by sending them code to execute. This has more applicability in the broader web context but could be used by more complex IIoT endpoints such as motors to offload computation intensive operations related to client requests.

Uniform Interface—Server requests are made to specific device resources using pre-defined operations. Messages are self-descriptive and contain all the information required to perform an operation. Although many options for protocols exist, HTTP (the same protocol that your web browser uses to get web pages) is by far the most prevalent.

RESTful Services
Applying the principles of the REST architecture to our temperature sensor, we can categorize our services into three basic types: GET, PUT, and DELETE. A GET service, given a valid resource identifier, will return information about that resource to the requesting client. A PUT service, given a valid resource identifier and data, will update the existing device state using the provided data. DELETE will delete the specified resource from the device. All the device information except the current temperature and logs can be cached. The temperature set-points can be PUT, and the logs can be erased with DELETE. This is summarized in Table 1.

Table 1: Methods Supported by Example Temperature Sensor Resources

The advantage to taking this RESTful services approach is that each of the methods for interacting with our temperature server (GET, PUT, DELETE) are already defined within the HTTP specification and no unique protocol work needs to be done. Web programming APIs already contain all the necessary support to connect with our devices and virtually any web programmer can quickly write a few lines of code to interact with our new device.

Data Model
The last hurdle we face in implementing our temperature sensor device is how we actually represent the device. In other words, what URLs will our device respond to, how will it react, and how will it represent the data that it returns to the client. Answering these questions is known as “data modeling” among IT professionals, and it represents the most complicated, and potentially most rewarding, elements of migration toward Industrial IoT. A good data model will allow for devices of the same general type (such as temperature sensors) to be recognized and used in a “plug and play” fashion within the network. A bad data model, or many different data models, defeats interoperability. Here again, though, there is significant opportunity to leverage from IT. Below is a portion of the representation for a temperature sensor for a server CPU as defined by the Redfish API. Although not perfect for a stand-alone sensor, many similarities can be seen with the temperature sensor we have discussed.

Table 2:  Temperature Sensor Rom Redfish 1u Server Mock-Up (Dmtf, 2018)

Ongoing Work and Getting Involved
The Device Management Task Force unveiled its Redfish API in 2015 for secure management of converged, Hybrid IT and software defined data centers. It defines various data models (or schema) for IT and cloud-based systems and has been gaining momentum as a best practice among cloud solution providers, including the Open Compute Forum. In 2018 the Redfish standard has been adopted by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).

At PICMG we seek to accelerate the adoption of IIoT in the markets we serve by providing meaningful open specifications and design guides to aid our member companies in creating high-quality, interoperable computing solutions. We are doing this by leveraging our historic strengths in industrial computing, expanding our community of practice to embrace a wider audience of IoT developers, and building partnerships with other IIoT-focused standards organizations.

On May 10th, 2018, the DMTF and PICMG announced their alliance to extend the Redfish API to support Industrial IoT. If you or your company are interested in joining PICMG in this effort, please contact us at


DMTF. (2018). Simple Rack-mounted Server. Retrieved from Distributed Management Task Force Redfish Developers Hub:–1U–Thermal

IIoT World. (2018). Top Three Leading Industrial IoT Factors That Are Spurring Measurable Value In 2018. Retrieved from IIoT World:

Doug Sandy is the Vice President of Technology for PICMG with over 24 years of industry experience in the embedded computing, industrial automation, telecommunications and cloud computing spaces. Doug has worked as Technical Fellow, Chief Technology Officer and Chief Architect for major corporations including Motorola, Emerson, and Artesyn Embedded Technologies. Sandy has focused much of his career advancing industry standards that provide multi-vendor interoperability and COTS solutions such as DeviceNet, ETSI NFV, and the PICMG families of specifications. He now enjoys training the next generation of engineers at Arizona State University’s Polytechnic Campus where he is a full-time educator and program coordinator for software engineering capstone projects.

PICMG is a not-for-profit 501(c) consortium of companies and organizations that collaboratively develop open standards for high performance industrial, military/aerospace, telecommunications, test/measurement, medical, and general purpose embedded computing applications.

There are over 150 member companies that specialize in a wide range of technical disciplines, including mechanical and thermal design, single board computer design, very high speed signaling design and analysis, networking expertise, backplane and packaging design, power management, High Availability software, and comprehensive system management.

Founded in 1994, PICMG’s original mission was to extend the PCI standard to non-desktop applications. The formal name of the organization is the PCI Industrial Computer Manufacturers Group.

Key standards families developed by PICMG include COM Express®, CompactPCI®, AdvancedTCA®, MicroTCA®, AdvancedMC®, CompactPCI® Serial, SHB Express®, and HPM (Hardware Platform Management).


Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis
Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.