BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY IN SYSTEMS

Managing Networked Small Devices

M2M Communications – There is a Better Way.

For controlling simple devices connected to local networks and also accessed via the Web, simplicity is the best approach.

BY WILFRED NILSEN, REAL TIME LOGIC

  • Page 1 of 1
    Bookmark and Share

Article Media

If you had walked into any call central office 30 years ago, you would have found a server machine and a host of dumb terminals complete with busy data operators handling the data. Fast-forward past that to PCs with their distributed intelligence, and suddenly the server was out of fashion and PC sales soared. Powerful local work stations were now the way to go, and the central server was cast aside for a peer-to-peer arrangement.

You find a similar chain of events in industrial automation. The wood pulp production facility 30 years ago sported a central controlling device supervising all operations. Somewhere in the control room, a DEC PDP-11 or similar with its flashing lamps on the multitude of I/O cards kept tabs on sensor inputs in order to control dumb actuators and valves from one central point. Machine-to-machine (M2M) communication provides the industrial parallel to the boom of the PCs. M2M and its distributed intelligence is the rage, with the related demand for all devices—sensors, valves, actuators or whatever—to communicate to all other components on an equal footing. Today’s current hype is attempting to get the sales off the ground.

The benefits of distributed intelligence, we are told, are clear. This is the dawning of an age when manufacturing equipment, airport baggage handlers, escalators and domestic appliances become capable of alerting their service providers before failure occurs. Retailers can now be routinely informed of every item in their stock, its source, its whereabouts and its destination. Extensive climate control and smart energy systems provide real-time feedback that optimizes even the most power-hungry processes.

And, there is no shortage of vendors looking to help to make this halcyon vision reality. Open your favorite browser, type M2M, and look through the high ranking search results. Repeated references to the “Cloud” and “extremely flexible M2M pricing plans” promote the belief that the fully distributed intelligence of independently Cloud-communicative devices is the only way to achieve these goals. Many companies would have you believe that the ideal solution for your state-of-the-art wood pulp plant is to use Cloud services for all actuators and sensors, where the online services are based on web services and communicating via the hypertext transfer protocol over secure sockets layer (HTTPS).

But is that really the case? 

The HTTPS solution incorporates several good features. M2M communications are secure, can use HTTP authentication, and can typically traverse outgoing firewalls. However, the cost of M2M development and system overhead rises sharply when all devices are fully intelligent and also HTTPS communication savvy. In addition, the poll-based nature of HTTPS makes for a very inefficient protocol.

A better, more economical approach reserves multidirectional communications for nominated supervisor devices and restricts slave sensors to a limited set of communication options. And, nothing is lost. This approach offers no less information since all nodes are accessible from outside the local network. The simple slave devices require less development, lower component costs, and the overhead cost of Cloud access and its associated “pricing plans” is then limited to the supervisors.

Let’s take a closer look.

M2M and Poll-Based HTTPS Make an Unhappy Couple

These dumbed down slaves clearly offer the potential for significant cost savings. What’s much less obvious is that their more restricted communications implies a second advantage of much better responsiveness than the much lauded approach of universally applied, poll-based HTTPS.

To understand why, first consider how a poll-based HTTPS system works. Only the client can connect and send asynchronous messages to the server (Figure 1). The server cannot send an unsolicited (asynchronous) message to the client, but must wait for the client to connect. In our wood pulp system, the actuator client opens a connection and asks the server for a command, the server responds, and the client closes the connection. This sequence repeats indefinitely with the client asking if it should move the actuator, and the server responding yes or no.

Figure 1
In a poll-based HTTPS system, only the client can connect and send asynchronous messages to the server.

Simply put, in a poll-based HTTPS system, the server cannot simply tell the actuator to move. Instead, the actuator has to repeatedly ask (poll) whether it is time to do so. Of course, most of the time the answer is “no”—but the overhead of the server repeatedly saying “no” to many actuators that do not need to move inevitably delays responding “yes” to those that do.

You may think that sending a simple HTTPS message from the device and receiving a simple HTTPS response from the server does not impose a lot of protocol overhead. However, under the hood, each communication involves a long sequence of commands sent between the client and server (Figure 2).

Figure 2
The handshaking sequence for the three protocols TCP/IP (blue), SSL(red), and HTTPS (green) is extensive. The more frequent the polls, the greater the overhead on the server.

A standard TCP/IP socket connection avoids this overhead. By definition, it is persistent, meaning that once the communications channel is open, it stays open. This persistence removes the need for synchronization. More importantly, it can also handle simultaneous bidirectional messages, so clients can “listen” for instructions without having to poll for them.

Imagine a car journey to a theme park where the kids don’t ask “are we there yet?” once every few seconds, but instead wait quietly to be told when they have arrived. The TCP/IP solution offers a similar advantage over poll-based HTTPS—and what’s more, it is much easier to arrange than quiet kids!

This solution may be implemented entirely locally to the plant, but the more likely scenario is that we will want the cool Internet access boasted by the HTTPS-based M2M sites. In that case, the client device will need a “listen server,” and the communications protocol will need to permit the penetration of firewalls and proxies. By applying a protocol that starts out as HTTPS to overcome the security issues and then morph into a secure persistent socket connection to remove the polling overhead, we arrive at a solution that offers the best of both worlds as depicted in Figure 3.

Figure 3
With IoT and M2M, many companies propose that all actuators and sensors use the Cloud to provide the web services that communicate over HTTPS. In contrast, an application server, such as Real Time Logic’s Mako Server, offers a simpler protocol that generates a persistent connection via TCP/IP and offers fast, predictable response times and much reduced costs.

Applying the Theory

Let’s take a look at how this concept could be implemented in a typical industrial facility. As you can see in Figure 4, in a private plant network, the firewall protects the local network reducing the need for further sensor and actuator security measures.

Figure 4
Providing local communications using dedicated low-cost local servers and optional external H2M communications via the Internet retains full functionality with reduced initial cost and lower ongoing overhead.

From the actuator’s perspective, the server fills the role of an application server local to the plant. The actuator can communicate with the server in real time with little network overhead and provide Internet access by initiating communication over HTTPS and then morphing it into a persistent and bi-directional TCP/IP connection—that is, a socket connection on a local secure network.

As well as filling the role of application server, the server also acts as a bridge between the local secure network and the Cloud—in effect, a server “broker.”  External access to the actuator is only accessible via the server. The server is therefore responsible for providing the human presentation logic—that is, the data relating to the user interface—and no such presentation logic is required in the microcontroller-powered actuators.

The plant’s firewall can be configured such that it enables access to the server, only permitting external users access to the web application(s) following secure login. The external user will not gain access to the local actuator before his/her credentials are accepted by the web application running on the server. Used in combination with a local secure network, the net result is that the actuator needs no extra security such as HTTPS and SSL.

The server broker concept becomes an even more practical proposal when combined with an advanced web application server specifically designed to make the most of the limited resources found in such embedded environments. Such application servers enable developers to design the M2M communication and the human presentation logic in a scripting language, which optimizes the development process too. This results in an architecture and a tool chain that are efficient in terms of development time, hardware cost and overhead cost of access to the Cloud (Figure 5).

Figure 5
The C code in microcontroller-based actuators and sensors communicates using standard sockets with an M2M script application running on the application server. The human operator accesses the M2M web application via HTTP (local access) or HTTPS (remote/external access). The two scripts, the web application, and the M2M application running on the application server together act as the broker.

Shoring up for the Rugged Environment

When doesn’t this work? When you hit the rugged environment. In the hot, dirty, high-stress environment, the local application element of the server’s role means that we no longer have the luxury of isolating the electronics away from the harsh environment of our wood pulp plant, where the likes of a Raspberry Pi would not be well-suited to the extremely humid conditions.

Clearly, you need to select the tool chain carefully. In extreme environments, select ruggedized industrial controllers designed for such environments that can deploy the same application servers, development environment and even application script as for the budget hardware solution. By doing this, you can run the same plant controller application script with any of these hardware solutions.

Mitsubishi’s C Controller is one example of such a solution (Figure 6). Mounting on standard Q series hardware and thus integrating seamlessly with other Q series CPUs (PLC, Motion, Robot, CNC), proven Q series I/O, networking modules and motion control cards, the C Controller CPU provides a flexible, reliable, readily expandable, rack-based PC-less solution as part of a multi-disciplinary automation platform. Since the Mako web application server comes pre-installed on the iQ Platform’s C Controller, it’s quick and easy to develop the web solution reliably, and to use the same web solution as may be used elsewhere in cheaper offerings such as the Raspberry Pi.

Figure 6
A ruggedized board, such as Mitsubishi Electric’s iQ Platform, is designed to operate in extreme, rugged environments, and the controller includes an advanced web application server that enables developers to design the M2M communication and the human presentation.

Because M2M promises such a financial burgeoning, many typically large-scale companies are attempting to elbow their way into what has been a traditionally small footprint space. While their initiative and investment speed the evolution of this technology, developers and system designers need to remember that these players are not accustomed to scaling down. They may not be promoting the most efficient options.

Certainly, the cloud is key to this M2M Internet of Things revolution in communication. But the optimal solution is unlikely to involve the indiscriminate application of Cloud-based communication for every device specified for every project. Keep your system simple and you’ll not only reduce development time and overhead, but your system will be more maintainable and less prone to failure.

Real Time Logic
Monarch Beach, CA

(949) 388-1314
www.realtimelogic.com