EN 
DE How to proceed with IoT development?
Author: Klaus-Dieter Walter, SSV Software Systems GmbH
Contribution – Embedded Software Engineering Congress 2015
What exactly characterizes an IoT development project, and where do its functional priorities lie? What resources does embedded systems hardware require in an IoT application? How is this hardware connected to the cloud, and which protocols or APIs are used? Here are some fundamental considerations regarding the necessary building blocks that can be combined to form an IoT developer toolkit, reducing risks and development time.
The Internet of Things (IoT) and the ever-increasing demands on functionality and security are making many newly developed embedded systems applications significantly more complex than ever before. Despite these considerably increased requirements, development teams do not have more resources or longer product and solution development phases at their disposal. In practice, the opposite is true – due to demanding competitive situations and global markets, products are expected to be completed ever faster. This article provides an overview of the architectures, concepts, and building blocks.
The Internet of Things (IoT) is still in its infancy. While the individual building blocks and components already exist, the architecture and blueprints are still the subject of intense debate. Particularly disruptive and unhelpful is the fact that many discussions are driven by the marketing departments of large US IT companies and some Silicon Valley startups, some of which are backed by very deep-pocketed venture capitalists. This pushes the actual problems that need solving into the background. Instead, the focus is on the IoT pioneering solutions of these companies, in order to make it clear to the rest of the world what to look for in the future. This approach is also reflected in the standardization and regulatory bodies. The number and relevance of the working groups claiming to be creating a truly important IoT standard is currently difficult to grasp.
For any IoT development project, a universally applicable guiding principle is essential for designing a suitable architecture that will later enable successful product or solution marketing and a long product lifecycle. A self-contained, siloed solution with a vertical orientation, high customer loyalty, and no horizontal service interfaces should definitely be avoided. It would be completely unsuitable for the Internet of Things and would no longer be competitive in the medium to long term.
Table 1 (see PDFFor resource planning of the embedded system, the method of connection between physical and virtual representation is crucial. A direct internet connection via mobile modem or external router requires significantly more powerful hardware and software than an indirect connection using a smartphone app.
Vendor-neutral guidance can be found, for example, through the European Union's Internet of Things Architecture (IoT) funding project. This EU flagship project, part of the FP7 research program, aimed to develop a universal reference model for future IoT applications. Embedded systems with their sensors and actuators – that is, the Things In this model, the physical representations of the Internet of Things (IoT) are represented by physical elements. Each physical representation, in turn, has a corresponding virtual representation, which can be implemented, for example, via a cloud or IoT service on the internet. Such an IoT service platform stores the current state of the embedded system's sensors and actuators and updates them as needed (for example, with every change in state). Other systems and users can access the current data representation via an application programming interface (such as a REST API). Such a cloud or IoT service API typically needs to support different protocols and platform-independent data formats, as well as offer appropriate security mechanisms.
A fitness tracker, which countless people now use for self-tracking, serves as a simple but representative example of the interplay between physical and virtual representation. Figure 2 shows the block diagram of a very simple version (see...). PDFThe only sensor used in this case is a 3-axis gyroscope. This MEMS sensor is connected to a Bluetooth SoC from the TI CC2540 family. The fitness tracker includes an app for Apple and Android smartphones.
Figure 1 (see PDFIn an IoT project, embedded systems, with their sensors and actuators as physical representations, should deliver a current data image to a virtual representation. This is typically implemented via a cloud or IoT service platform. Such a platform provides open service interfaces for access by users and other systems.
Figure 2 (see PDFBlock diagram of a typical fitness tracker. Such a wearable device is the typical physical representation in countless IoT self-tracking applications. A 3-axis gyroscope counts the wearer's steps and transmits them to a smartphone via Bluetooth. The smartphone then forwards the step counter data to the virtual representation in the cloud. This forms the link between the wearable as the physical representation and the virtual data image on the manufacturer's internet servers. Using the height and weight entered into the smartphone app during setup, the daily calorie consumption and various other activity data, such as sleep patterns, can be calculated from the step counter data.
Direct or indirect connection
An important question with far-reaching implications for the resources of the embedded system used concerns the details of the communication link to the virtual representation. Basically, three different solutions are conceivable in an IoT application (Figure 3, PDF):
- The embedded system is directly connected to an IoT or cloud service via the internet. This direct connection can be established by integrating the embedded system into an existing network with internet access via a router using a LAN/WLAN, or via an integrated cellular modem – i.e., via a GSM/UMTS/LTE radio connection.
- An embedded system is indirectly connected to its virtual representation in a cloud service platform via a special gateway. The connection between the gateway and the embedded system is typically established via a wired or ISM wireless connection.
- The embedded system is connected to a smartphone app, which is responsible for the connection to the virtual representation on an IoT or cloud service platform. In most cases, the embedded system will then communicate with the smartphone via Bluetooth. However, a USB cable connection would also be conceivable, since at least newer Android smartphones have an open USB interface that is supported by an Accessory Development Kit (ADK).
With a direct connection between the physical and virtual representations, the embedded system requires significant hardware and software resources to meet the extensive requirements regarding functionality and security. In the case of an indirect connection, the complex tasks can be offloaded to the gateway or the smartphone app, so that in the simplest case, the embedded system could be implemented using a single-chip microcontroller with just a few kilobytes of internal flash and SRAM (see the fitness tracker example in Figure 2 (PDFTable 1 provides an overview of the different requirements.
Figure 3 (see PDF): The communication link between physical representation (the Thing, The connection between the embedded system of an IoT application and its virtual representation in the cloud can be established directly or indirectly via a gateway or smartphone app. Depending on the connection type, the embedded system must support different protocols and security features.
REST and other interfaces
Access to the data and structures of the virtual representations in the cloud or on an IoT service platform is, as already mentioned, via predefined APIs. Most IoT platforms currently use REST-based solutions (REST = Representational State Transfer). REST is an architectural model for web services implemented using the HTTP methods GET, PUT, POST, and DELETE. REST is based on the CRUD model widely used in IT (CRUD = Create, Read, Update, Delete – the four CRUD operations are generally sufficient for all database accesses).
The "state transfer" in REST means that with each HTTP request or response, a complete state—that is, all the data describing a specific state—is transmitted. This results in another important REST characteristic: statelessness. A REST server or client doesn't need to remember anything between consecutive requests. The "HTTP cookies" familiar from the web are not required for REST solutions—meaning an embedded system doesn't need to permanently cache states. Furthermore, an HTTP request or response is not bound to any specific data type. XML, HTML, JSON, or simple ASCII data values can all be transmitted.
Conclusion
IoT applications consist of numerous components. The most important and also the most complex functional unit is a cloud or IoT service platform. This platform uses suitable data structures to create a virtual representation for the "things." Access is typically via a REST API. While such HTTP-based APIs are currently the preferred solution for almost all IoT applications, this is likely primarily due to the widespread adoption of HTTP through the Internet of Things. Technically, HTTP is only suitable for the Internet of Things to a very limited extent. MQTT should be used instead as the protocol for embedded systems and smartphone apps. Firstly, this allows sensor data to be transmitted to an IoT service platform much more efficiently. Secondly, an actuator or smartphone app doesn't need to constantly poll an IoT service using REST GET to detect data changes in the virtual representation. Since almost all IoT applications share the same architecture, the necessary components should be assembled into a modular system.
System and hardware development – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Internet of Things/system and hardware development.
Training & coaching on the other topics in our portfolio can be found here. here.
Systems and Hardware Engineering – Expertise
Valuable expertise in the field of Internet of Things/system and hardware development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
