Network your devices correctly
Today, new concepts, new products, and new technologies continue to be researched, tested, and brought onto the market. The spirit of invention is active at all levels – and so is a state of constant revolution. We can help you to keep a clear overview: For your application, your challenge, your change, and your transformation.
Contact us right now, or browse here first to get an idea of what it’s all about.
Data transport essentials
Transporting data sometimes seems complex in today’s world of the megabit, gigabit, and 5G. And sometimes, it really is complex. But it can also be very simple on occasion, for example if you want to send data to the cloud using MQTT (Message Queuing Telemetry Transport).
As you’re going to see, it also makes sense to distinguish between the IoT and Industry 4.0 when considering data transport.
Protocols at application layer
Initial thoughts about data transport generally turn to communication protocols. As is known from TCP/IP and the ISO OSI model, there are protocols at different levels. Above all, we’ve specialized in data processing, so the session/application layer in the OSI model (layers 5 to 7) or, accordingly, the application layer in the TCP/IP model. In the case of the MQTT protocol, for example, this application layer receives a message in MQTT message format from the underlying transport layers. This message can then be analyzed in data processing. Naturally, for the development of entire systems, we can also advise you on data transport in the lower, transport-oriented layers of the TCP/ IP or OSI models.
Let’s briefly deal straight away with an issue that we often get asked about: All protocols in the top layer support secure data transfer, generally via TLS or comparable encryption protocols such as SSH. The DTLS protocol was created on the basis of TLS, enabling secure transmission via the transport protocol UDP. As an additional step between the transport protocols and application layer protocols such as HTTP, the use of an encryption protocol enables secure data transmission. Instead of HTTP, for example, you get HTTPS, which has been used for some years now to display Websites (like this one!), too.
IoT protocols for IP (OSI layer 7)
To start with, familiarize yourself with a small selection of IoT protocols:
- MQTT (Message Queuing Telemetry Transport) is an extremely popular binary protocol (M2M communication) that supports publish-subscribe.
- Binary means that unlike normal text, none of the data at protocol layer is easily readable by humans.
- Publish-subscribe is a communication mechanism akin to sending info letters to all interested parties. There is a sender who provides the information, a broker who accepts delivery of the information, and receivers who have deliberately chosen to receive information on a specific topic (e.g. the temperature in Berlin) and have registered to do so.
- HTTP (Hypertext Transfer Protocol) is the best known protocol that everyone who’s called a Web page via a browser has used. HTTP is mainly used to load Web pages in a Web browser. Communication takes place in accordance with the request-response mechanism (client-server model).
- Request-response as a communication mechanism means that a corresponding reply is returned or expected for each query. Generally, the questioner actively waits for the response, which arrives quickly. However, it is also possible for the questioner to wait passively for an answer (for example, in an e-mail conversation).
- AMQP (Advanced Message Queuing Protocol) is a binary publish-subscribe protocol. It provides more functions than MQTT but is more complicated and more resource-intensive.
- CoAP (Constrained Application Protocol) is a binary protocol that masters both public-subscribe and request-response communication mechanisms. It can be seen as a restricted, really slim version of HTTP for machine-to-machine communication.
- XMPP (Extensible Messaging and Presence Protocol) is a text-based publish-subscribe and request-response protocol that was originally designed for message exchange in chat programs.
- DDS (Data Distribution Service) is a binary publish-subscribe protocol that is trying to establish itself in the IoT and in Industry 4.0. It is particularly suitable for machine-to-machine communication.
Industry 4.0 protocols
Among other things, Industry 4.0 describes communication inside production plants. Here, it seems understandable that the direct connection to the cloud is not in the foreground. At least, not from the perspective of the machine wanting to communicate with other machines.
Here is a selection of protocols that is by no means exclusive:
- Once you start learning about Industry 4.0, you’re bound to come across OPC UA (Open Platform Communications Unified Architecture). You’ll quickly realize that OPC UA is much more than just a protocol. OPC UA has the potential to become the de facto standard for industrial plants. It’s a good idea to understand the concepts a little better. That’s why we go into more detail in the next section.
- ProfiNet has a long history, and is one of the traditional industrial protocols. It has been subject to constant further development and is therefore one of the most widespread specifications. In addition, it works well with OPC UA. ProfiNet is the Industrial Ethernet variant of the traditional Profibus, a fieldbus that is not based on Ethernet.
- Modbus TCP is the Ethernet variant of the traditional Modbus (a fieldbus) and is particularly suited to smaller systems. As a result, Modbus TCP is frequently found in this segment, too.
- EtherNet/IP (Ethernet Industrial Protocol) is another protocol specification that builds upon Ethernet and meets special industrial requirements using TCP and UDP. Today, it is the most widespread Industrial Ethernet variant by far.
- Ethernet – or, to be more precise, Industrial Ethernet(s) – denotes the modern variants of machine-to-machine communication in industrial plants. Fieldbus can be seen as the predecessor.
Data transport in Industry 4.0 applications
In the context of Industry 4.0, protocols can be subdivided into three categories:
- Industrial Ethernet protocols (e.g. ProfiNet, Modbus TCP, EtherNet/IP)
- Fieldbus protocols (e.g. Profibus, Modbus RTU)
- Wireless protocols (e.g. GSM)
Fieldbus is the classic technology that can now be found in almost all Industry 4.0 applications. It found its way into factories before the time of Ethernet. Industrial Ethernet is enjoying significant growth rates, but at present, the industry-wide market is split equally between the two technologies. The wireless protocols do not yet play a major part in the industrial sector. This is completely different for IoT applications, where we often depend on technologies without a wired connection.
OPC UA is taking on a special position among the Industry 4.0 protocols. OPC UA is based on Internet Protocol (IP) and calls for a corresponding network as its basis.
OPC UA supports the common synchronous (client/server) and asynchronous (messaging) communication types. OPC UA uses the common IoT protocols here, such as MQTT for messaging. In addition, the JSON format used in modern software applications is used and supported.
Information models can be defined in detail – including with vendor-specific properties – on the basis of the Core Information Model Layer of the OPC UA specification (or protocol):
To sum up, we can say that OPC UA works in an extremely standardized way on Industry 4.0 applications. As a type of super-protocol, it can therefore solve interoperability problems up to cloud level. OPC UA is supported by a huge number of OPC Foundation members (see https://opcfoundation.org/members) including large software companies such as Microsoft and IBM as well as German small and medium-sized businesses, smaller consulting firms, and – of course – Siemens and other groups.
Data transport in IoT applications
With regard to used protocols at application level, Industry 4.0 and the IoT show considerable differences. In the IoT area, no fieldbuses are used: Most of the infrastructure uses Ethernet as the basis or else a wireless technology such as Bluetooth or WiFi (we won’t go into further detail about these here). In the IoT, too, the communication paths are less clearly structured/prescribed. This means, for example, that there might be multiple (IoT) gateways between a sensor and the data sink in the cloud or the visualization (MES, ERP).
Security then becomes a central issue, particularly in the case of critical applications. The generated data is transmitted securely using symmetrical and asymmetrical encryption. But what about the generation of data? How do we know that we can trust the source of the data?
Trusted execution environments in brief
Trusted execution environments (TEEs) can help here. A TEE ensures that programs and data cannot be read or changed from outside without authorization. Due to these properties, TEEs are used, for example, in payment solutions – both traditional chip card approaches and today’s smartphone apps.
Generally, TEEs appear in two different forms: Integrated into the main processor (in the case of smartphones, ARM TrustZone is usually used as the solution here) or as a separate chip, often called a secure element. This hardware support contributes to protecting against runtime accesses to sensitive storage areas, input/output (I/O) devices, and persistent data. TEEs can also provide many of the mechanisms that are provided by other trusted computing primitives (e.g. the Trusted Platform Module or TPM), such as remote checks.
As one of the first steps in the IoT landscape, it is important to establish an encrypted and authenticated connection between the devices as well as to a cloud or to an individual back end. To enable this, a public key infrastructure, which forms the basis for TLS, is generally created. The required cryptographic keys and certificates can be kept safely in a secure element that is integrated into the device.
The following diagram shows the hardware security elements and their integration into the AWS IoT Greengrass. The software enhances the cloud functions on edge devices and offers a hardware-root-of-trust storage of private keys in order to enable hardware-secured message encryption.
Blockchain and distributed ledger technology
You’ve surely heard of Bitcoin, and you know that a digital currency is ideal for machine-to-machine payment. And that a blockchain can be used when machines need to negotiate contracts. Why? With blockchains, we combine trusted communication, decentralized protection, and data immutability. Isn’t that exactly what we need?
Let’s get started: Bitcoin is a specific implementation of Blockchain technology. Blockchain is, in its turn, one of the best known incarnations of distributed ledger technology (DLT). Mostly, it’s all about saving data securely in a distributed environment without an intermediary (such as a bank).
The technologies differ, among other things, when it comes to properties such as the number of achievable transactions per second (TPS) and the underlying data structure. Note that distributed ledger technologies are currently still in the fledgling stage – even if major investments have already been made in Bitcoin technology and its adaptation.
There are various different implementations of DLTs, and the applications are diverse. For example, in the IoT environment, the following specific distributed ledger technologies are of particular interest to us:
- IOTA offers possibilities for the efficient use of micropayments. In the industrial environment, machines will be able to make purchases on the basis of sensor data, for example.
- Ethereum enables the use of smart contracts. This allows machines to enter into contracts that are associated with actions in certain (negotiated) conditions.
At present, good advice is a rarity – and it’s hard to separate the hype from the reality. Successful projects have indeed already been realized with DLTs. We believe that DLTs will find their niche in future (however large that niche might turn out to be). In any case, it makes sense to take a look at this aspect, and perhaps even investigate it further.
Data transport in projects
Greenfield projects are rare. This is because greenfield projects are projects that have practically no links to the past. Some startups are able to enjoy this luxury, but even these are soon caught up in the past – at the latest when, for example, the new products and ideas need to be made available for the existing framework, too.
Brownfield approaches are the norm in all areas of software development. And this is one of our strengths as an independent service provider. Often, tailored solutions that can also deal with unexpected situations are needed.
The choice of the right protocol is sometimes really easy: When there’s actually no choice at all. But often, you’re faced with a decision as to how to connect up new sensors. Or you need to think about how you can now transport data to your cloud application.
Various criteria play a role here, including these:
- Existing infrastructure, devices, and procedures
- Existing application landscape
- Preferred architecture/interaction patterns
- Enhancement possibilities and integration capability
- Resource consumption
Linking data in all the right places
Whether it’s Industry 4.0 applications or the IoT: Protocols are right at the crux of the matter in this digital era of networked devices. In one case they are a given, and in the other they are not. However, you always need to think about which road you want to go down, and why. Don’t leave your choice up to chance – make a well-informed, deliberate decision!
Security plays a vital role in the networked world. Unsecured communication can quickly become public, causing your customers’ trust in you to disappear. It’s important to pay attention to data security and data protection right from the start, and doing so will save you hassle and negative publicity later on.
We’ll help you to choose
As an independent service provider, we’re familiar with all common protocols. Starting with REST-based protocols through binary protocols, point-to-point protocols, and publish-subscribe protocols to machine-to-machine and sensor-to-cloud protocols as well as synchronous and asynchronous varieties. When helping our customers to make the right choice, we first look around in all directions. Then we quickly home in on the best options: Usually, there’s a small selection of choices that differ from each other only slightly. Security always plays an important role.
Let us take part in your project right from the start. Together, we can get everything right!