Internet of Things
The Internet is probably the most magic word in daily use. This mystery results from many of its features, but I will mention only three.
The first is the incredible straightforward use. For example, my less than 4-year-old granddaughter can easily rise a favorite cartoon using the Internet. In the case of a TV, she brings me two remote controllers she asks for a movie.
The second feature is the unprecedented complexity of the matter, so everything that is under the hood of the mouse clicking on the icon and in effect raising the movie. I realized this by listening to a lecture given by my research fellow who is working on selected aspects of improving Internet performance under certain specific conditions. Then I asked myself how many people in the world know what is the IP protocol, IP address, subnet mask, DNS, DHCP, routing, WWW server, etc. Fortunately, everyone knows Internet Explorer, Chrome, Firefox, and similar software.
The third one is an example of how the Internet influences the behavior of its users. Recently, I advised students about the excessive dependence on the Internet, stating that physics rules say that still, we require water and food to survive, but not the Internet. The answer was very silver-tongued: “We need only the Internet because if we have the Internet we will be able to organize the water and food for ourselves”.
Google search is usually just the first step in a typical Internet usage scenario. In the next one, we get hundreds of selection proposals. In this case, we have two options: switch-on thinking or trial and error method. Imagine, however, a situation in which instead of someone in the chair in front of the computer “a machine” would sit. For example, a washing machine that needs information about the promotional price of electricity to switch on the laundry when the electricity is the cheapest – of course, the washing machine must be sure that the price is provided by an eligible organization. Or car keys that want to tell me where they are at the moment, so I don’t have to ask my wife – in this scenario, I must be sure that the information will not be used by a thief. It can also be a blister of drugs that wants to inform its factory where it was sold, to allow global distribution tracking and selective population health dependence research – now the factory must be sure that it isn’t an imitation.
The example we will use in the next sections is a set of unmanned boilers spread geographically, which have to be monitored and remotely controled. They produce a lot of process data describing the state and behavior of each boiler. In case some alarms have been raised a serviceman must be called to investigate and fix the problem. So we are facing the following problems:
- Mobility – the serviceman must be informed in any localization in the service area (say agglomeration)
- Navigation – The serviceman must be routed from the place currently he is to the affected area
- Remote control – the serviceman must be able to control remotely the industrial object (in this case the boiler) to avoid any catastrophic behavior
- Data reusability– the data must be also available and shared by others helping him minimize danger and fix the problem in shortest possible time
If you want to learn another ton of examples, google the phrase “internet of things examples”.
This way we have entered the Internet of Things (IoT) domain of the Internet applications. The IoT already exists, although the scenarios mentioned above are still waiting for implementation. One of the obstacles, in this case, is the necessity to eliminate the client-server communication pattern and Google from the usage chain. Such an attempt is Object Oriented Internet (OOI) technology based on the OPC Unified Architecture(OPC UA).
IoT Data Acquisition
Let’s return to the examples of the IoT mentioned above. Do you think a box (or even pack) of cigarettes could be the “thing”. It has a bar-code, so it is the source of data. Is it the sensor – NO because the bar-code reader (industrial scanner) is the sensor in this case. Can we recognize the bar-code reader as the “thing” – again the answer is NO if the goal is to provide a GLOBAL cigarettes tracking system. The same applies to drugs for example. Is it an IoT solution – my answer is YES, no doubts. Is it SCADA/DCS –the answer is NO, because the server ( underlying communication engine) cannot poll all possible places spread over the world where the box could appear. There are two reasons:
- It is impractical or even impossible to manage such a huge set of addresses
- The server doesn’t know when to poll because the relevant data appear as an event instead of a process state value
Assuming that the server is interested or even allowed to collect product data of one vendor only – not all codes fetched by any bar-code reader are relevant to the server.
Is the “thing” smart – I don’t think we can call the bar-code something smart. Is it controllable – NO. The most interesting observation is that we can recognize this use case as an IoT application, but we have not mentioned OPC, AMQP, MQTT, SOA, Internet, WI-FI, wireless, Modbus, etc. at all, but only that we have important mobile data and the solution is globally scoped. It is good because we can check the available technology capabilities against this application requirements. As I have said selected communication technology is not the goal, but we must know how it scales to applications like this.
Now, let’s replace the word GLOBAL by LOCAL (for example cash desks farm in a shop) and the same application is no longer an IoT deployment, isn’t it? It is true even if the cash desks are interconnected using the IP protocol (e.g. Intranet)!
The similar analysis we can do in case of boilers set. In the above example depending if the application is local or global the following data acquisition patterns can be applied:
- Data polling – for local approach – continuous checking of the sensors to see what state they are in, usually in multi-point or multi-drop communication (a communication engine with multiple devices attached that share the same line) by sending a message to each device, one at a time, asking each to respond and send new data.
- Data subscription – senders of messages containing the process data fetched by the sensor, called publishers, do not prepare the messages to be sent directly to specific receivers, called subscribers, but instead, they categorize published messages into topics without knowledge of which subscribers, if any, may receive the message. Similarly, subscribers express interest in one or more topics and only receive messages that are of interest, without knowledge of which publishers, if any, there are.
It is worth stressing that in both cases reusability of the fetched data is assured. In data polling scenario the server coupled with the communication engine may be connected to by many clients at the same time. In data subscription scenario the publisher is responsible for multicasting the data to all attached subscribers directly or indirectly using a broker.
To deploy the IoT scenario:
- The mobile data must be sent over the Internet (or Intranet) using messages;
- The payload of these messages is consumed asynchronously by a server (e.g. OPC UA Server) responsible for exposing it in an address space;
- The applications (e.g. OPC UA client) process the exposed data to reach selected key performance indicators (KPI).
It is required that the payload of the messages is formatted in a standardized way to be factored on the fetching site (publishers) and meaningfully consumed by the analytic application (subscriber).
Now let’s analyze the impact of the data acquisition pattern on the application behavioral model.
Using data polling we must deal with the synchronous data acquisition pattern. In this case, the application must follow the interactive behavioral model, because it actively polls the data source for more information by pulling data from a sequence that represents the process state in time. Such behavior is represented by an iterator, which is used to iterate through a data stream. The application is active in the data retrieval process – it controls the pace of the retrieval by sending the request messages at its own convenience. This enumeration pattern is synchronous, which means that the application might be blocked while polling the data source. Such a polling pattern is similar to visiting the books shop and checking out a book. After you are done with the book, you pay another visit to check out another one. If the book is not available you must wait, but you may read what you selected. This solution is well suited for the local approach.
On the other hand, in the reactive behavioral model, the application is offered more information by subscribing to a data stream, and an update is handed to it from the source. The application is passive in the data retrieval process: apart from subscribing to the source data stream, it does not actively poll the source but merely reacts to the data being pushed to it. In this case, the application will not be blocked by waiting for the source to update. This is the push pattern employed by IoT. It is similar to joining a books club in which you register your interest in a particular genre, and books that match your interest are automatically sent to you as they are published. You do not need to wait but you must read what you get. Employing a push pattern is helpful in many scenarios, especially if data is available asynchronously as events. It is the case I have mentioned as the IoT examples including, but not limited to the boilers set.
Object-Oriented Internet (OOI)
The widespread use of the HTTP and hypertext makes it possible to freely publish new information and expose it in the context of its description. Google search machine uses it to help us find the information we are looking for. Unfortunately, this is a human-centric environment that cannot easily be adapted to an application-centric approach and Machine To Machine communication, which is required to provide distributed enterprise management and real-time process control.
In this open source project, a new architecture is presented that can provide a generic solution for publishing and updating information in the context that can be used to describe and discover it. It is proposed to distribute the data publisher tasks to three functional classes:
- Semantic Data: information context management using the object-oriented programming paradigm
- OPC Unified Architecture: a predefined fixed set of services to access data and meta-data
- Dynamic Data Binding: a pluggable custom process Semantic Data binding components
In this project conceptual documentation and software supporting a new Machine To Machine (M2M) communication architecture is to be researched with the goal to provide a generic solution for publishing and updating information in a context that can be used to describe and discover it by software applications. It is implemented based on the OPC Unified Architecture PubSub protocol – a newly emerging industrial integration standard that fulfills the proposed architecture requirements.
The workspace of the project is available at https://github.com/mpostol/OPC-UA-OOI. The detailed description of the Object Oriented Internet paradigm is captured in the ebook: Object-Oriented Internet.
Reactive Smart HMI Powered by OOI
Modern control systems much appreciate the graphical user interfaces. “A picture is worth a thousand words”, but it seems that the future of Human Machine Interfaces in automation is far beyond that.
As opposed to the SCADA term, a lightweight local user interface of a machine is sometimes referred to as the human-machine interface (HMI) – in this context, it is an embedded part of the machine. SCADA, on the other hand, is an all in one software package that consists of tightly coupled components implementing functionality to operate a system as a whole. It is worth noting that in spite of application kind this interface is a place where interaction between someone responsible for making a decision and something responsible for the decision execution occurs. This post address the question what are the consequences if this interface is used, for example, to start drilling by a CNC machine, in one case, or alternatively to start moving remotely say the load of 200MW from one power plant to another one in another case. After all, in both cases, the operation can be initiated by pressing a virtual “ACCEPT” button on a touch screen. However, is it a sufficient reason to call this interface as an HMI device in both cases, and what is more important, can we use the same or similar solutions in all circumstances to decrease development and deployment costs?
In any case, while interacting with a machine or with a system finely we operate a process. To operate effectively we must fulfill the following requirements:
- Output interface – provide a representation of the process behavior and its current state
- Input interface – provide sensors to allow entering the operator decision;
- The vendors of modern solutions – that meet highly demanded customer expectation – for this purpose employ 3D graphic, touch screen, voice recognition, motion tracking, and many other technologies.
However, communication with the user is only one aspect that we must focus on. To recognize others we have to look under the cover.
Automated processes are dynamic and stateful, so the interface has to provide an informative context for decision making. To reach this goal the process behavior must be tracked all the time by processing its variables to optimally adjust the screen content and expose the most important elements in an instant of time. Once there are more and more process variables within the automation systems, one has to choose, how to organize the structure of the control system and mappings with visualization purposes. Each variable can be recognized as a set of attributes: value, quality, timestamp, and meaning. First tree attributes can be simply expressed as simple (primitive) or complex numbers and bind to the graphic on the screen in a generic way. The fourth (meaning) attribute is usually assumed that it does not change over time, and therefore the interface behavior and appearance is designed (hard-coded) to express it in a communicative way. For example, we can distinguish a selected part of the screen to allow a serviceman to communicate with a remote boiler located somewhere.
Unfortunately, this design time approach is often too rigid to seamlessly adapt for example exchange of the device by a new one from another vendor. To avoid this unnecessary design cost and avoid proprietary solutions we need a next-generation solution that can be called “Semantic HMI”. Semantic HMI is an approach that relays on discovering the meaning of process data using the meta-data provided by the plant floor measurement and control devices, like analyzer, PLC, DCS, etc. In this approach, the meta-data must be provided as a context for the real-time process data and processed simultaneously by a smart enough semantic HMI.
OPC Unified Architecture (UA) technology meets all the requirements, because:
- It is a platform neutral standard allowing easy embedded implementation
- It is designed to support complex data types and object models
- It is designed to achieve high-speed data transfers using efficient binary protocols
- It has broad industry support beyond just process automation and is being used in support of other industry standards such as S95, S88, EDDL, MIMOSA, OAGiS
The connection between HMI, as the decision entrance device, and process control device, as the decision execution device, may engage many technologies (e.g. RS232 serial bus located inside the box containing both, Internet, wireless connection, etc …). Unfortunately, the vulnerability of the communication medium is only one measure of the security issues severity. Directly related decision cost and its consequence make together another measure that must scale the required security robustness. In other words, without authentication of the transferred data, data sources and users we cannot expect and rely on responsibility. Even in the completely shielded control rooms of the nuclear power plants, at the end of the day, we must know who is responsible for pressing the virtual “ACCEPT” button if any problems occur. On the other hand, can you imagine a message on the screen saying “you must log in to continue…” in a really critical situation in places like that.
There are more and more modern solutions of HMIs: advanced graphics, with high resolutions and touch screen, high IPs for front panels, faster CPUs, integration with modern operating systems, etc. However, they must offer much more to be used as a decision entrance device in applications like process control of municipal-wide heat distribution network located in the city of Lodz Poland (750k citizens), supplied from three plants with total thermal output power of 2560MW producing hot water distributed using ~800km of pipes interconnected by ~8000 nodes deployed in 2009. In an application like that, the most important features are the openness to be seamlessly pluggable, visualization flexibility to expose process data in the context of process metadata, and appropriate security precaution to provide selective availability to control functions. It seems that using new standards, like OPC UA and new technologies, mentioned above could cause synergy effect leading to reusable out of the box products withstanding even most demanded requirements.
Proof of Concept
Let’s return to the IoT boilers case. The Object-Oriented Internet project and derived solution CrossHMI of the Human-Machine-Interfaces implemented using small, mobile devices proves that the presented solution is feasible and scalable. The goal is to provide a mobile application that is able to gather data from geographically spread devices and present the data in the human-readable form using semantic data and publication and subscription communication on the based on the OPC UA international standard. We are using the semantics (strict typing approach) to describe the Data Transfer Graph transported over the Internet using OPC UA PubSub over a variety of protocols, e.g. UDP, MQTT, AMQP.
Thanks to Android-based mobile device user of this HMI is additionally instructed about the geographical location of the affected industrial processes and mobile HMI. Thanks to semantic data the HMI may be prepared in advance or dynamically updated to handle data published by the process. Using Xamarin technology we obtained the cross-platform mobile application.
- eBook Object-Oriented Internet
- Object-Oriented Internet home page
- OPC Foundation extends OPC UA including TSN down to field level
- IoT versus SCADA/DCS Data Acquisition Patterns
- OPC UA Makes Smart User Interface Possible
- CrossHMI open source project
- OPC UA Information Model Deployment
- OPC Unified Architecture Specification Part 14: PubSub Release 1.04 February 06, 2018
- OASIS MQTT Version 3.1.1 specification
- amqp-core-overview-v1.0 OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0
- OOI Releases Page
- Data is Data: It Doesn’t Matter Where It Comes From!
- Internet of Things (#IoT) How it Works
- IoT Paradigms