IoT Logic Portability

In the analog world, an input device directly controls an output device. Think about a switch, which regulated power to a motor. If the switch got turned on, power flowed, and the motor turned on. We then got into variable speed and bi-directional motors. So we changed the input device. For bi-directional motors we 2 switches, with mechanical interlocks, and the variable speed motors got different amounts of voltage or current. Mechanical interlocks and automation gave way to electronic on the PCB, and then to software based interlocks & automation.

As data moves ever so freely through devices, networks, networks of networks, and the cloud, the input trigger and processing can literally happen almost anywhere. It could happen on the input device, output device, the gateway, the cloud or even on mobile UI devices. As an engineering manager, catering to the today’s requirements leads to adding logic in certain places (e.g motor vs gateway vs cloud). However, from a product & technology strategy, change is the only thing that is constant. We need to plan for change! As requirements change, the location of the logic will have to change. Therefore, not only is it important to locate logic at the appropriate level of the IoT stack and on the appropriate device, but also have a framework that lets you move this logic easily between the different parts of the IoT stack.

For example, let’s take a simple shade motor in a home or building. The shade reacts to button pushes from the wall-controller; apps on laptops, phones and tablets; light & occupancy sensors; weather patterns; time-clock events (astronomic and time of day); remote signals coming from the Internet and even machine learning. This poses many challenges, for example:

1. What happens when conflicting commands, like an up and a down command, are received at similar times?
2. How should each message be prioritized? Should a sensor take precedence over an App on the phone?
3. Should it be command driven (e.g. a sensor command it to do something specific) or should it be event driven (e.g. a sensor transmits it’s state, and the motor decides whether it needs to react)
4. Where should the command/event processing occur? Should all command/event processing be done at the motor, the gateway or even perhaps the cloud?

Image of an Industrial IoT system

Most of the problems described above are solvable through software logic. The location of the logic/code though is not obvious. And if it is obvious today, as business conditions change, it is not so obvious months, or even weeks from now.

So if the domain logic can be described, discussed or learnt (the value creation piece), then why does it take so long to code or make it portable? Let’s look at the challenges of logic portability. Each part of the IoT stack has a different programming technology:

1)      We will start with the edge node – this is the device or component of the device, which contains the processing/electronics that interacts with the sensors and actuators. The software on the edge node used to run on bare metal, which means the software on the runs directly on the hardware without an associated operating system. This approach is starting to become less popular with the advent of modern embedded chipsets (like Quark from Intel) and RTOS (like VxWorks from Wind River). Current approaches usually involve an RTOS (Real Time Operating System), with application level programming done in C or C++.

The first mission of the local control software on the edge node to protect itself. No matter what conflicting commands the device may receive, it is the responsibility of the “real-time” control system to not do things that would damage the device or cause injury to others. A conflicting command could include things like an up, followed by a down command coming to a motor. It is the responsibility of the edge node to release the up command, before executing the down command. This is an example of a software inter-lock. More sophisticated devices will have more sophisticated logic.

2)      Next is the gateway. A gateway is typically a device that connects 2 networks and routes data between the two networks. An example of a gateway, in the industrial domain, would a device that connects a Modbus network with a TCP/IP LAN network. In this example the protocol as the well as the physical layers are different.

The Gateways today typically run programs written either in C or C++. However, customers are also starting to use scripting languages like Python, Ruby, Lua and even JavaScript. Enterprise friendly languages like Java are also being considered.

So depending on the requirements of the system and the team capability, a gateway either looks like an embedded device (#1) or closer to a cloud instance (#3).

It is also important to note than in some cases the gateway is going away. For example a thermostat, used to talk via Zigbee/Zwave, which would then communicate to a LAN network via a gateway. We are starting to see Wi-Fi thermostats eliminating the gateway. In the transportation industries, some devices are starting to talk directly via cellular networks. In smart cities, narrow band networks (like Sigfox and LoRa) are starting to emerge as strong candidates. In the last example, a gateway is usually managed at a city level by the network vendor as opposed to a device vendor.

3)      The cloud servers (what is commonly referred to as the backend), meanwhile are predominantly using scripting languages like Python, Ruby and JavaScript. Some web applications use enterprise friendly Java and .NET.

In many cases, intermediate services, data storage and rules engines in Wind River Helix Device Cloud, Amazon EC2, Microsoft Azure or IBM’s BlueMix are being used. These then get integrated with the application backend. So the logic is created, edited, deleted through APIs.

The client side, what runs in your browser, meanwhile, is dominated by HTML5, JavaScript and CSS.

4)      Lastly mobile applications are either written in native languages (Java for Android, Objective-C/Swift for iOS). There has been a growing movement to start using HTML5, JavaScript and CSS through app development platforms like Apache’s Cordova, Adobe’s PhoneGap, and Intel’s XDK platform. While there is momentum there, there are pros & cons to each approach. Therefore, based on the developer team (and their background), certain approaches are recommended.

Here-in lies the problem for logic portability. Each part of the IoT stack is dominated by its own programming language and tools. So let’s say we wanted to do health monitoring of the edge node, like the motor that we used as an example earlier. When we start out, we don’t have enough correlated data. What causes a motor to fail? To figure this out, sensors, which measure temperature, humidity, vibration, etc. are attached and the motors are deployed in harsh, real-world conditions.

Since the IoT device manufacturer doesn’t want to burden all their products with this high sensor cost, they decide to add them to their high end products (where this is a higher Average Selling Price and less tolerance for failures). The manufacturer is in the learning phase, and it wants to collect as much data as possible. The best place to collect all this disperse data is in the cloud. So the motors send all the data back to the gateway, which will send it to the cloud. With enough data, inferences can be made (either through statistical programming or through machine learning). The company now has a better idea of when and how failures are occurring. It creates “Failure Logic” that can predict failures from a stream of data coming to the cloud.

From the learnings, however, they also realize that most of the data coming back is not that important. A very small fraction of the data (usually less than 5-10%) can predict the failure. So back-hauling all the data doesn’t make sense anymore. They would like to deploy the “Failure Logic” to the gateway and prevent the extra data from coming to its cloud. This will also let them equip their mid-end product line with this logic. However, due to every part of the stack being different, the logic is not easily portable. A different team needs to recreate the logic for the gateway (if one exists).

After some time, the company has gained even more experience and realizes that the logic can be embedded right into the electronics of motor control unit. In doing so, they can equip all their products with this logic. As a bonus, if the cause of the failure is detected early, the motor can self-regulate and prevent the failure. However, to deploy the “Failure Logic” to the motor, yet another team would need to re-create the logic. As we move through the IoT stack, the same logic had to be recreated multiple times. With each re-creation, the code base is different and similar bugs have to be found and fixed over and over again.

IoT Design Center

Given the right architecture and experience, this logic portability problem can be avoided and solved with minimal porting efforts in the future. Many tools, like FPGAs, logic scripts (in Lua or JavaScript), machine learning abstraction layers (both training and classification), common protocols (like Thread) can be used to solve the above problems. However, it needs to be envisioned early on in the design process.

A holistic end to end architecture, which encompasses the edge sensors & actuators, input devices, gateways, cloud, and mobile devices has to be created. This architecture then needs to be phased into products to ensure that value is being created immediately, while a company works towards its future goals.

Thus, the Wind River  IoT design center was formed with a mission to “Help customers harness the potential of IoT through connected, secure, turn-key solutions.” Through this center of excellence we provide IoT consulting services around:

1. Business models
2. Product strategy
3. Technology strategy
4. OT/IT  system integration
5. Project delivery
6. Helix Device Cloud and Device Management
7. RTOS, Linux Operating systems