Logo Hilscher

Using Industrial Raspberry Pi as a Device-to-Cloud Solution

Hilscher’s Industrial Raspberry Pi offers network connectivity for both real-time Ethernet and conventional Ethernet. This makes it ideal for gateway applications at the boundary of IT and OT networks – known as the “edge” – so it can contribute to the intelligent networking of machines and devices around the world via the Internet and the cloud. In this new technology briefing, and with special reference to six leading cloud service providers, Hilscher Product Manager Armin Beck, explains how the Industrial Raspberry Pi can effectively help in the Device-to-Cloud hierarchies demanded by next-generation IIoT systems.

 

 

Device-to-Cloud (D2C) concept – many Question Marks

 

As data from the field takes precedence in the race towards better asset management, the “Internet of Things” services offered by modern cloud platforms look set to become powerful “back ends” supporting centralized device and data management for plants.

 
But many questions arise.  Should a connected device make itself known to the cloud automatically or should it be set up manually? How does data get into the cloud after that? Are there consistent methods of data transfer, or even a standard? Are cloud manufacturers providing support? What about security? Which cloud manufacturers should automation users engage with?  These are the typical questions of device manufacturers today, who are working towards a complete Device-to-Cloud (D2C) communication concept.

 

Sending data to the cloud

 

Hilscher’s Industrial Raspberry Pi is an excellent platform for the acquisition and transmission of data to the cloud. The data acquisition stage, thanks to the embedded real-time Ethernet controller, is extremely simple thanks to Docker technology. Docker is a way of “containerizing” applications so that they run in a virtual CPU on a single computing platform, separated from one another so that no application can compromise the others.

   
An application exchanges the process field data to and from the respective bus master in a protocol-neutral way, with data flows defined easily by the Node-RED tool. Ready-to-use container examples for the Node-RED tool, or programming examples in C-code, are installed in just a few minutes for PROFINET, EtherCAT and EtherNet/IP, thanks to Docker. These and many other examples are available free on the Docker “hilschernetpi” repository. (GitHub can also reveal the container source code, enabling functions to be added to containers - or merged - to create custom containers easily.)

 

Finding suitable clouds

 

The D2C message exchange highlights the possibility of using the Industrialized Raspberry Pi as a “digital twin” – the digital equivalent of a real-world device in software - along with the assignment of transmission services and the specification of unique data IDs.  A further criterion for a suitable cloud is the provision of SDKs (software development kits) in order to equip devices with cloud communication services.


SDKs in the programming languages Python, node.js, JAVA or C/C++ are needed.  The SDK implementation should be well documented and underlined with examples to ensure rapid and successful development. An exemplary offer is to have published the SDKs on open source platforms like GitHub. This creates not only the necessary trust in the implemented security, but also embodies seamless documentation down to the last detail.


During the data transfer itself, TLS secured communication is also obligatory and has to be supported in all cases. It is of less importance which of the conventional IoT protocols - MQTT, AMQP, CoAP, OPC UA or simply REST API - are used for the transfer by the SDKs. Thanks to their small protocol overhead, they all fulfill the requirements of IoT-oriented communication within embedded devices with limited resources.

 

The More Cloud Domains the Better

 

The suitability of an IoT cloud can be measured by its supported domains. The device-management domain is one essential. Here the IoT device - or entire fleets of them - are onboarded and registered in the cloud where profiles are created. They are then visually managed according to type, location or group.


This is refined by the device-monitoring domain, which lists devices according to their transactions and displays them in an activity monitor or enables the definition of metrics to filter and respond to certain messages. This is perfected if the deployment-management domain is supported as well, enabling applications and updates to be loaded onto devices from the cloud.


The prerequisite for that is of course the implementation of relevant services in the device, which depends on how comprehensively the SDKs are incorporated. For higher security a prescribed operating system may have to be integrated, as some clouds demand. In fact, to meet the highest standards of security and device integrity, the use of certain CPUs will become obligatory in future.


The data-management domain handles the devices’ data and must be present. For simple data handling without the need for developing and using applications, devices can be grouped and configured to exchange data locally, or indirectly via the Cloud, using packet forwarding. However, the real benefit of a perfect cloud is its offerings to handle the “big” data with specific applications so data can be processed with a program of the user's choice. In the best case, such applications can even be deployed onto the devices themselves and executed locally on-premise.

 
Professional clouds also offer forwarding to the analytics domain, which enables the analysis of mass data for the purpose of predictive maintenance and malfunction or forwarding to the visualization domain for the graphical preparation in web-based HMI solutions.

 

Using the Leading IoT Clouds

 

If a device manufacturer starts to implement cloud support in his products, he must understand that he hardly has any influence on the cloud that the end customer chooses. So, for the broadest possible market coverage, it would be wise to support multiple platforms.


The most realistic approach to this is to offer connectivity to the “top dogs.” It is a truism that the longer the cloud provider has been established, the more he is in line with the market and the more domains he supports. This increases the chance that the devices end user will be able to get his data processed for the intended purpose and therefore implicitly increasing the sales volume for the manufacturer.


Hilscher has addressed this in their Industrialized Raspberry Pi by creating Docker container applications for the six leading cloud providers - Amazon, Microsoft, Google, IBM, SAP and Alibaba. These are available for download now. The handling of each container, from its start to the setting of its parameters all the way through to data communication, is extensively documented. Once loaded users can adapt the containers or modify them for their preferred framework conditions.

 

Experiences with the Top Six Cloud Platforms

 

All of the six above offer a free trial of their cloud services. Although services may be limited (either temporarily or functionally), they offer the chance to test the platforms. Online help is available, but additional support is usually available on a monthly paid-for basis too.


All the platforms have the ability to select an IoT service out of the many cloud options. Instant support is then provided via a wizard or clickable key visuals, which guide the user through any further steps of the online web interface. This is important as there are usually 20 or more available configuration dialogs when using IoT services.


The registration of IoT devices is very similar for all services. Whether it’s called a product, object or device, the data for name, location, etc. can be manually entered. In return, the user receives specific authentication details for secure communication to and from the device. It would be ideal – as is the case with Amazon – if users could subsequently receive these details as personalized SDK parameters and anchor them directly to the device with the SDK, so that it finally registers to the cloud automatically.


Google and Microsoft have gone one step further and announced that in future they want to use secure CPUs, which will register and log into platforms autonomously when they are integrated in embedded devices. However, usable services based on this premise are not expected for another two or three years.


As a preliminary step towards “total integration”, Microsoft is delivering Windows 10 IoT Core which can be installed on the Industrialized Raspberry Pi via SD card and which registers directly to an Azure account using the Windows 10 commissioning tool. After that, further services - such as Azure IoT Edge - can be immediately installed from the Cloud onto the device to operate “remote” cloud services or data analysis software locally.


Among available SDKs, a preference for the script language Python is evident. All six providers offer implementations for this language. However, the Javascript-based and nodejs SDKs are also popular. All Industrialized Raspberry Pi cloud container examples use one of the available SDKs and come with the corresponding language interpreter preinstalled for immediate use. Users only need to add their specific authentication credentials according to the instructions to communicate with the corresponding cloud channel immediately.

 

Long-sighted Integration Concept

 

Unfortunately, with the need for SDKs and the need for manual interventions, we are still some way off from the ideal IoT device. That device would automatically register itself in the Cloud to receive instructions from there as to its purpose and from then on would operate autonomously and could be diagnosed and managed centrally.


The prerequisite for such a concept requires a considerable expansion of the basic SDK, including the software running on top of it, plus the implementation of accompanying functions in the cloud. Developing and maintaining this type of ecosystem on an individual basis is almost impossible however, as it would tie up vast amounts of development resources.


The Cloud providers Google, Amazon and Microsoft have recognized this “problem” and offer a complete Device-to-Cloud solution in addition to the SDKs. Microsoft is pursuing a management and software deployment concept based on Docker, the same technology as used in Hilscher’s Industrialized Raspberry Pi.


For this reason, Hilscher has opted to use Microsoft's software elements in the next revision of their device solution.  Microsoft’s “Azure IoT Edge” reference architecture covers device and cloud environments in one. It lays the foundation for centralized cloud-oriented device and data management and will be offered by Hilscher on all their Edge devices.

 

 

Above Figure. Hilscher’s future Device-to-Cloud reference architecture

 


The architecture consists of the “Edge Platform” bridge (shown in orange) hosting different back end services, a REST API (blue) granting access to the front end “Edge Portal” (red) as a web-based user interface for maintaining the Edge Device fleet with. On the other side, there is the Docker-based “Edge Agent” (red) as its counterpart running in the Edge devices.


The whole ecosystem is based on Microsoft Azure technology but is relevant to other cloud platforms too. This way, the data remains in customer hands right up to reaching the final customer application (shown in green).

 

Complete device solution

 

Services like the central coordination and monitoring of entire device fleets, the remote deployment of local software, software license management, cloud communication in accordance with the highest security standards, and update and patch management are the requirements for a comprehensive D2C solution. Hilscher’s initiative in bringing more intelligence to the IT and OT convergence within existing enterprise structures is underlined by the need for a perfect interplay of edge devices, cloud bridge and cloud. This makes it the logical next step in the development of the Industrial Raspberry concept as that moves towards being a future-oriented, complete IoT device solution.