Author: Andreas Foltinek, IMACS GmbH<\/p>\n
Remote data communication between technical systems is as old as the systems themselves. With the ever-expanding and faster web infrastructure, it's a natural step to utilize it for technical systems, leading to the established terms IoT and IIoT. Based on Linux\/Windows or similar operating systems, implementing IoT capabilities from a software perspective is now manageable. Unfortunately, however, Linux-based systems and similar systems are unsuitable for many applications for a variety of reasons (component\/manufacturing costs, boot process, complexity, stability, energy consumption), especially when higher production volumes and thus increased efficiency are required. Implementing IoT on "small" embedded targets, on the other hand, presents a greater software challenge. The following practical report demonstrates that even with the resources of smaller 32-bit single-chip controllers, typical IoT features such as TCP\/IP protocols, web client\/server functionality, push mechanisms, and firmware updates via the cloud can be easily implemented \u2013 while also meeting current security standards. The following section explains the experiences from several such projects regarding hardware, toolchain, RTOS, stacks, drivers and their special features in integration, commissioning and daily use.<\/strong><\/p>\n To implement an IoT-enabled device or integrate an IoT interface into a device, the relevant use cases and the resulting requirements should first be clearly defined. The following aspects should be considered:<\/p>\n What is the primary function of the device?<\/p>\n Which connection technologies should be used? The following are generally available and established:<\/p>\n The latter form a separate class of systems and, due to their technology, require significantly fewer resources; however, they are therefore only relevant for a specific application area. These will not be considered further below.<\/p>\n The initially obvious use of secure tunnels (e.g., VPN) is unfortunately ruled out in most cases due to the complex installation or lack of acceptance. For the straightforward installation and operation of an IoT device, a free internet connection should suffice.<\/p>\n However, this means that attacks in various forms (eavesdropping, manipulation) are possible at any point in the connection. The use of established, sometimes even directly readable, formats\/protocols (XML, JSON, HTTP, etc.) further exacerbates this issue.<\/p>\n Therefore, the following protective mechanisms (individually or in combination) should be planned:<\/p>\n The following variations are also possible when using certificates:<\/p>\n In addition, customers increasingly want to use the existing IoT interface to connect directly locally (via mobile device) or with "external," non-certificate-supporting systems (e.g., smart home, building technology, etc.). The procedure described above applies depending on the type of communication (client\/server).<\/p>\n What does "narrow" mean? To keep costs as low as possible, targets of the Cortex M3\/M4 or PIC32 MX\/MZ class were used, with processor-internal memory ranging from 256kB flash, 128kB RAM, 80MHz to 2048kB flash, 512kB RAM, 200MHz.<\/p>\n Even with the smallest hardware configuration, less than 50% of resources were required for IoT functionality, despite LAN and WLAN support. A 100 Mbit Ethernet interface with an external PHY and the controller's own MAC unit was always used, and WLAN and Powerline LAN via SPI were added in various combinations.<\/p>\n To implement the primary IoT capability, only a serial EEPROM (for storing access data) was required. To meet application-specific requirements (offline buffering, updates, logging), this was supplemented in some cases with a data flash, a USB master interface (for memory sticks), and an SD card. The PCB was implemented in a two-layer design in most cases and still fully met the EMC requirements immediately.<\/p>\n The vendor-provided toolchains and libraries were used in combination with FreeRTOS to create the base software (lower layers). Wolf-SSL was used as the TLS stack where necessary.<\/p>\n In addition to the various HAL components, the systems included up to 2 web clients (access to the cloud via LAN and WLAN or Powerline-LAN) and a web server (access for local app) (thus also providing 3 instances of the TLS stack).<\/p>\n In addition, there was the actual customer-specific application layer (user data communication, data evaluation and processing, etc.), which was developed using a model-based approach and generated via a code generator. Constantly growing model libraries significantly facilitated the development of subsequent projects and even enabled the preliminary execution\/testing of the application on a PC platform with full IoT functionality.<\/p>\n Despite functional reference designs, using the manufacturer's code naturally meant a time-consuming learning curve and the discovery of bugs, which were, however, quickly resolved by the manufacturer. New manufacturer versions also required various adjustments to the application code we had developed up to that point. This proved worthwhile, however, in the implementation of subsequent projects on this platform.<\/p>\n The model-based development system also offered the possibility of PC visualization, which was linked to the target via an interface and displayed all variables and events online, recording them in logs. This significantly simplified the debugging of errors, which often only appeared after days of continuous operation.<\/p>\n In the projects of this type carried out so far, the following aspects were considered important and noteworthy:<\/p>\n Andreas Foltinek studied electrical engineering at the University of Stuttgart and can look back on over 30 years of experience in embedded hardware and software.<\/p>\n In 1994, he founded IMACS and has since been responsible for research and development as its managing director. As the initiator of a UML-based CASE tool system and a modular open-source hardware system, his passion lies in simplifying and avoiding redundancy in the development of embedded hardware and software through modularity, reuse, and especially model-based methods and generation.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topics of IoT\/Industry 4.0\/system and hardware development.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in IoT\/Industry 4.0\/system and hardware development is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\nIoT connectivity \u2013 environment classification<\/h3>\n
Use Case<\/h3>\n
\n
Types of use and device-specific functions\/features<\/h3>\n
\n
\n
Physical interfaces to the cloud<\/h3>\n
\n
Security<\/h3>\n
\n
\n
Hardware platforms<\/h2>\n
Software components and scope<\/h2>\n
integration<\/h2>\n
Experience and insights<\/h2>\n
\n
author<\/h2>\n
\nIoT \/ Industry 4.0 \u2013 our training courses & coaching<\/h2>\n
\nIoT \/ Industry 4.0 \u2013 Expertise<\/h2>\n