EN 
DE A pragmatic DSL approach
Authors: Christoph Woskowski, Alexander Leupold, Zühlke Engineering GmbH
Contribution – Embedded Software Engineering Congress 2017
The sheer number of products and solutions in the field of connected devices, or the "Internet of Things," is overwhelming. A wide variety of new—and also familiar—transmission technologies, protocols, standards, and the consortia and interest groups behind them are readily available. Within this vast array of options, it is assumed that a suitable solution can be found for every problem and every use case. However, this often contrasts with the very specific requirements and circumstances of companies that may be seriously engaging with the topic of IoT for the first time—or are forced to do so because their competitors may have already taken this step. Especially when the business case and use cases are still unclear, a cumbersome solution or premature commitment to specific technologies and vendors should be avoided. The approach presented here for developing an enterprise-wide IoT data model fulfills this requirement by being designed for lightweight construction and maximum flexibility.
The example described below has a real-world basis, but it also relates to a strategic initiative of the company behind it. Therefore, the context has been somewhat altered. On the one hand, the application area has been shifted to the unrelated domain of "household appliances." On the other hand, both the methodology and the experiences gained, as well as the resulting conclusions, are independent of this and not limited to a single industry. Rather, the aim is also to demonstrate the flexibility of the approach. In this respect, "portability" to another domain is already an important initial indicator. It should also be emphasized that this is not a generalizable solution—that is, an abstract approach that, due to its distance from the problem space, can be applied directly to many or virtually all areas—but rather genuine flexibility in the sense of adaptability to the target problem. Adaptation must therefore be made in every case.
Problem statement
A large company with a broad technological and technical expertise, despite its platform and product line approaches, struggles with the vast variety of products on the market and under development. A similar situation can be assumed for a household appliance manufacturer. The drive for standardization for cost reasons is not only pronounced in development, but also noticeable in manufacturing, logistics, and especially in service and repair. The pressure for standardization is further intensified by the trend toward value-added services and cross-device functions (the coffee machine "knows" when the toaster is finished and adjusts the beverage dispensing accordingly) in the context of the Internet of Things (IoT). While data sovereignty—which data is collected, stored, and made available, and how—previously resided with the respective development projects in coordination with stakeholders who were more or less standards-oriented, the diversity of historically grown data formats and data models is now becoming a problem. In extreme cases, each new version of a product has its own data model, which must be known to anyone who wants to use or depends on the data.
Even though this multitude of data models in the present example follow a metamodel with a uniform basic syntax (e.g., valid data types are (u)int8_t, (u)int16_t, (u)int32_t, etc.), machine-readable semantics (value X is a temperature in °C with one decimal place) for interpreting the values are still lacking. Furthermore, there are no uniform naming conventions, which is why there are up to several hundred variants for common operational data such as runtime and usage counters across all products. These include many copies (different names with the same meaning), but also ambiguities (same names with different meanings). Despite a uniform and very flexible protocol for reading the binary data from the various products—whether wired or wireless—the specific data model is always required to interpret the read binary "blob." The use case here is clearly the repair case, where all available data can be downloaded from the device for analysis and analyzed using a large database of device-specific data descriptions.
This approach no longer works if the user wants to read data of interest from a household appliance using their smartphone. The corresponding app would essentially need to know all devices and have their data descriptions in their current version (even offline). At the latest when it comes to device-to-device communication (M2M), a chaotic mess of different approaches is inevitable.
The task of solving these problems therefore consists, on the one hand, of merging and standardizing existing data models and, on the other hand, of adapting them for new use cases and value-added services in the context of IoT. An important aspect here is, of course, the usability of the new, unified data model in low-power and bandwidth-constrained embedded systems. Coin-cell-powered Bluetooth LE tags or beacons serve as an example. Real-time communication between devices with a maximum latency of a few milliseconds is another use case that the new data model should enable. It quickly becomes clear that, in addition to the data model itself, data formats and transmission protocols also need to be developed or at least adapted.
Proceed
Initially, it is important for an external consultant to understand the current situation, gather information from the stakeholders involved and their requirements, and thus establish the framework for potential solutions. A first requirements workshop, which includes developing a shared vision, defining the context (in- and off-topics), identifying further stakeholders, documenting scenarios and use cases, and creating an initial, rough timeline, is one possible method.
The second step in solving any problem should always be to examine whether there are already existing, suitable approaches that can be applied to the current task with minimal effort. External expertise from unrelated industries/domains can be quite helpful here.
The research revealed no directly applicable standards in the target domain, but a multitude of generic and cross-domain approaches. OMA LWM2M and Eclipse Vorto are just two examples. Further analysis based on the initial set of identified use cases and the available technologies primarily reinforced concerns regarding the scalability of existing generic solutions. None of the examined standards or data modeling approaches offered the necessary horizontal (use case-related) or vertical (technology-related) extensibility. Many of the existing solutions are either highly technology-specific (e.g., LWM2M) or support only a portion of the required use cases – from log data/firmware download/upload and device personalization to real-time M2M communication.
On the other hand, the research yields an interesting selection of recurring solution patterns and best practices such as unique identifiers, object-oriented approaches, hierarchical structures, and domain-specific languages (DSLs). All of these patterns are ideally suited as building blocks for a specific solution.
Outlook on the solution approach
We chose a DSL approach to enable each customer's development project to describe the data associated with a particular device in a language tailored to the target domain. Instead of worrying about integers, booleans, and floats, or big-endian and little-endian, the developer defines, for example, motor runtimes, operating temperatures, or event log entries. By grouping related data based on physical components and overarching functions, a library of building blocks is created that can be reused for other similar devices. Reusability and extensibility are ensured through language features such as optional data fields within the building blocks, composites, and inheritance. Simple generators and adaptable transformers translate the respective model into the technologies and environments involved—from low-power embedded systems to cloud backends and mobile clients—while simultaneously enabling connectivity to and support for existing and future standards and protocols.
The technological basis of the final implemented solution is an extremely lightweight DSL approach, including a parser generator and templating mechanism. Specifically, ANTLR is used to generate a parser in the target language Python from an EBNF grammar. The resulting Python code is very concise – under 1000 lines of code – and primarily serves to provide the information for the subsequent generation. The implementation of the necessary generators and transformers is done either in Python code or using templates in the target format in conjunction with a templating engine.
authors
Christoph Woskowski Mr. Woskowski is a consultant and architect for embedded systems at Zühlke and has been with the company for over eight years. He has extensive experience in the design and implementation of device software. For many years, he has supported projects as a software and systems architect in various roles, successfully managing the entire process from requirements gathering and test case derivation to verification of requirements in code and integration and acceptance testing. Mr. Woskowski has also participated in numerous embedded architecture reviews and technology selection processes for critical systems.
Alexander Leupold He has been an embedded software developer at Zühlke since 2015. He designs and implements software systems in the IoT and medical sectors. In addition to wireless technologies such as ZigBee and Bluetooth LE, he has extensive experience with continuous integration and test automation. He also focuses on IT security and conducts threat modeling for IoT and embedded systems.
IoT / Industry 4.0 – our training courses & 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 topics of IoT/Industry 4.0/system and hardware development.
Training & coaching on the other topics in our portfolio can be found here. here.
IoT / Industry 4.0 – Expertise
Valuable expertise in IoT/Industry 4.0/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.
