IIoT edge development - Prototyping devices - Embedded.com

IIoT edge development – Prototyping devices


Editor's Note: The Industrial Internet of Things (IIoT) promises to provide deep insight into industrial operations and enhance efficiency of connected machines and systems. Large-scale IIoT applications rely on layered architectures to collect data from a broad range of sensors, move data reliably and securely to the cloud, and perform analysis required to deliver that insight and efficiency. In Industrial Internet Application Development, the authors provide a detailed examination of the IIoT architecture and discuss approaches for meeting the broad requirements associated with these systems. 

Taken from Chapter 3 in the book, this excerpt describes how developers can build prototype devices able to to collect and communicate data to higher level applications. This excerpt is presented in the following installments:

Prototyping devices

Implementing HTTP connectivity

Using WebSockets

Using Modbus

Using OPC UA protocols

Adapted from Industrial Internet Application Development, by Alena Traukina, Jayant Thomas, Prashant Tyagi, Kishore Reddipalli.

Chapter 3. IIoT Edge Development
By Alena Traukina, Jayant Thomas, Prashant Tyagi, Kishore Reddipalli

This chapter describes the process of prototyping a device for beginners. We provide detailed instructions on how to assemble four different prototypes, and how to build and run simple IoT apps for the prototypes, together with sample source code. Finally, we explore the Predix services that can be used to store, analyze, and merge the sensor data from the prototypes.

In this chapter, you will learn about the following topics:

  • Choosing hardware for prototyping

  • The Open Systems Interconnection model and its layers

  • Application-layer protocols—HTTP and WebSocket

  • Industrial M2M protocols—Modbus and OPC UA

  • Assembling a device for a prototype

  • Preparing an SD card for a prototype

  • Building and running simple IoT apps using the HTTP, WebSocket, Modbus, and OPC UA protocols

  • Data management services in Predix

Hardware for prototypes

This section overviews the available variety of hardware that can be used for prototyping, and gives some tips on choosing the hardware and a data exchange protocol to ensure communication between the components of a prototype.

Variety and cost

One can find a variety of open source hardware for prototyping—Arduino , Raspberry Pi , Orange Pi , LinkIt , BeagleBone , and Tessel . Most of them are really cheap; you can buy an Orange Pi for just $33. The price usually depends on how powerful the board is and what interfaces it supports.

In addition to a board, it is possible to purchase a starter kit that usually costs about $70. It includes a few sensors, a small display, lamps, cables, and a breadboard for connecting it all without soldering. The price of a single sensor starts from $1.


The most popular boards are Arduino and Raspberry Pi. Each of them has different modifications. If additional features are required, such as Wi-Fi, Bluetooth, USB, HDMI, or more powerful hardware, it is recommended to compare the modifications to find a board that fits one's exact needs.

Comparing options

All boards are quite small—about 8 cm wide, 5 cm high, and 2 cm thick (without a box). More powerful hardware will have bigger dimensions (for example, Intel NUC is 35 x 25 x 4 cm).

The most significant parameter is connectivity options, as not all the boards support Wi-Fi or Bluetooth. GSM, GPS, a camera, an FM module, and other features common for mobile phones are usually not available either, and one needs to buy them separately.

Another important parameter is the number of connectors for sensors. One needs to understand what sensors are required and whether they are compatible with a chosen board. The number of pins can be extended by connecting special additional boards to the existing ones.

Supported sensors

Some connectors on a board may support only analog sensors, while others are only digital.

Digital sensors output a discrete signal, meaning that there is a limited set of possible values for that signal. For example, temperature sensor DHT11 outputs an integer in a range between 0 and 50.

On the other hand, analog sensors output a continuous signal, meaning that there is an infinite number of possible values for that signal. For example, temperature sensor TMP36 can measure temperature from -50°C to 125°C including floating point values such as 11.9°C.

While converting one type of the signal to another is possible, it requires additional components and complicates the design.

Choosing hardware

When choosing hardware, one has to take into consideration its intended purpose, its size, the connectivity options, the architecture, and whether it can work with analog and digital sensors, as well as software requirements.

For prototyping, the best choice is Arduino or Raspberry Pi. However, for industrial IoT tasks, it would be better to use (mini) Field Agents by GE or Siemens solution.

In our case, we chose Raspberry Pi because it is an open source solution featuring versatile usage options. With support from a huge community, users get access to a wide variety of compatible extensions and software solutions that can help to speed up the development process.


Strong communities have been formed around the most popular boards. They offer a range of software with drivers for the most widely used sensors. There are also some hardware initiatives that sell extensions for boards, enabling one to easily scale a device. Some of the major communities include the following:

Following the links, you can find a lot of examples for different experience levels.

You can try to reproduce an existing project, following the provided detailed instructions. Another option is to create something unique. If all you have is an idea and you do not know how to implement it, consider discussing it at a specialized forum.

Choosing a data exchange protocol

You need to choose a proper data exchange protocol to establish efficient communication between the prototype components. The choice is largely dependent on the communication function for which you intend to use the protocol. The functions are described by the Open Systems Interconnection (OSI ) model. Note that some protocols can cover multiple functions.

The OSI model divides a communication system into a number of abstraction layers (originally seven, as shown in the following table). Each layer is responsible for its specific jobs (functions), servicing the instances from an above layer and requesting services from an underlying one.

The following table shows seven layers of the OSI model:

Layer Protocol data unit Function
1. Physical Bit Transmitting and receiving of raw bit streams through a physical medium
2. Data link Frame Dependable transmission of data frames bounded by two nodes connected by a physical layer
3. Network Packet Configuring and managing a multi-node network, involving addressing, routing, and traffic control
4. Transport Segment (TCP)/Datagram


Dependable transmission of data segments bounded by points on a network, inclusive of parting,

acknowledgement, and multiplexing

5. Session Data Governing communication period, that is, consecutive change of data in the form of multiple back-and-

forth conveyance between two nodes

6. Presentation Data Transcription of data among a networking benefit and an exercise, including character encoding, data

confining, and encryption/decryption

7. Application Data High-level APIs, together with resource sharing, remote file access

Unlike web applications, IoT devices send really small amounts of data, but frequently. This means that transfer of IoT data can be optimized on the application (P2P, AMQP), transport (Modbus, OPC UA), network (Zigbee), or even physical (NB-IoT) layers (see the preceding table).

Devices may be connected directly to a cloud, through a hub, or in a mesh network where they can communicate with each other.

The subsequent chapters cover the following four protocols in more detail—HTTP, WebSocket, Modbus, and OPC UA.

Reprinted with permission from Packt Publishing. Copyright © 2018 Packt Publishing

About the authors

Alena Traukina is IoT practice Lead at Altoros. She has over 12 years of experience in delivery and support of business-critical software applications and is one of the first GE's Predix Influencers.

Jayant Thomas (JT) is the director of software engineering for the IoT apps for GE Digital. He is responsible for building IoT SaaS applications using the Predix platform, and specializes in building microservices-based architecture, reactive, event-driven systems.

Prashant Tyagi is responsible for enabling the big data strategy at GE Digital for the Industrial Internet that leverages IT and Operational data for predictive analytics. He works with all the P&L verticals (such as oil and gas, power generation, aviation, healthcare, and so on) to enable their IoT use cases on the data and analytics platform.

Kishore Reddipalli is a software technical director and expert in building IIoT big data and cloud computing platform and products at ultra scale. He is passionate in building software for analytics and machine learning to make it simplified for authoring the algorithms from inception to production at scale.

2 thoughts on “IIoT edge development – Prototyping devices

  1. “It is this most important phase that truly matters before any end product could finally be produced. Hence, it needs to be emphasized on in order to derive with the best results anticipated. Without much time and effort, intended results could be sacrific

    Log in to Reply
  2. “I reckon that when you're trying to get all these different components of the system to work together, it would definitely get more complicated as you add more nodes. But if you wanted these facilities to work well together, then you just have to put in

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.