Select Page

Embedded Software Engineering Reloaded: mbeddr

Practical report from the development of a smart meter

Authors: Dr. Stephan Eberle, itemis France SAS; Bernd Kolb, itemis and Dr. Markus Völter

Contribution – Embedded Software Engineering Congress 2015

Over the past three years, itemis France has developed a smart meter whose embedded software demonstrably boasts the following characteristics: a maintainable, modular architecture, hardware-independent testability, low integration effort, and high reusability thanks to a platform-based development approach. The smart meter software was implemented entirely with mbeddr, an open-source IDE for developing embedded software based on an extensible version of C. Among other things, mbeddr supports C extensions for state machines, physical units, and components. mbeddr is also highly customizable, particularly through user-defined C language extensions. Furthermore, the mbeddr-based implementation generates very little overhead compared to traditionally implemented C code.

A smart meter is an intelligent electricity meter that continuously measures and records electricity consumption, performs various analyses, and enables energy consumption control (e.g., multi-tariff support, abuse detection, load profiling, historical data recording). It can also be remotely read and configured by the energy supplier. The hardware of the smart meter for three-phase alternating current (AC) considered here is equipped with two MSP430 microcontrollers from Texas Instruments [1]. These are 16-bit CPUs that can be clocked at up to 25 MHz and have 128 KB of flash memory and 8 KB of static RAM. One processor is responsible for the time-critical execution of the measurement and metering functions ("metrology"), while the other handles the downstream analysis and configuration functions as well as communication. The required accuracy class according to IEC 62053 standard [2] is 0.5 (i.e., max. 0.5 % deviation) for all active values to be measured and 2.0 (i.e., max. 2.0 % deviation) for all reactive and apparent values to be measured. The remote query and configuration functions were to be implemented based on the DLMS/COSEM standard [3].

More abstraction versus efficient software – the eternal contradiction

A typical characteristic of embedded software is very limited resources coupled with high real-time requirements. In the case of the smart meter, this is particularly noticeable in the measurement and metering functions: For this purpose, the instantaneous voltage and current values of all three phases are acquired on one of the two MPS430 microcontrollers using fast sigma-delta analog-to-digital converters at a sampling rate of 4096 samples/second. From this, the RMS voltage and current, active, reactive, and apparent power, power factor, active and reactive energy, as well as the mains voltage frequency, must be calculated in real time. Sufficient processing time must also remain to transmit the energy consumption data obtained in this way via a serial connection to the other MPS430 microcontroller, which incorporates this data into the downstream analysis functions and makes it available for remote reading.

Given such requirements, it is hardly surprising that the efficiency of the resulting code has always been of paramount importance in the development of embedded software. To date, approximately 801,000 of industrially developed embedded software is implemented using the C programming language [4]. C is very well suited for implementing algorithms close to the machine level and thus efficiently. Conversely, however, C offers only very limited possibilities for expressing the business logic to be implemented in a problem-oriented way, i.e., in a manner adapted to the user's perspective. This generally leads to the resulting code being very difficult to understand and posing an enormous challenge with regard to maintenance and extensibility with new functionalities.

mbeddr – the flexibly expandable C

The search for a way out of this apparent contradiction was the central motivation behind the development of mbeddr [5]. mbeddr is open source and primarily represents an extensible version of the C programming language. In addition, mbeddr includes predefined language extensions that provide users with highly useful concepts and notations of a higher level of abstraction. These include, for example, physical units, interfaces and components, state machines, and tests. Furthermore, users can define their own language extensions at any time and use them together with the existing extensions. Both the predefined and user-defined extensions are modular: they can be developed without modifying the C programming language itself and are only visible to applications that explicitly use the respective extension.

Crucially, all classic C language constructs remain available. This allows for the writing of low-level, highly efficient code whenever needed, alongside the use of the diverse predefined and potentially custom language extensions. Ultimately, all code written with mbeddr is regenerated back into classic C99 code. This code can then be further processed using standard compilers for the respective microcontroller type.

The technical basis for mbeddr and the modular extensibility of the C programming language is the MPS platform from JetBrains [6]. MPS is open source and provides the necessary infrastructure to define new languages or extensions to existing languages, to specify suitable textual or graphical notations, and to implement code generators that reduce the new languages or language extensions to a base language. In addition, MPS offers users the familiar convenience of a modern development environment, which is available for both base languages and language extensions. This includes syntax highlighting, code completion, prompt error marking, code refactoring, quickfixes, and tooltips (see Figure 1)., PDF).

Component-oriented architecture

The use of mbeddr enabled the implementation of the software for the smart meter described above in a highly advanced manner. This was based on a highly modular, component-oriented architecture, which is shown in Figure 2 (see PDFThe structure is represented as shown in the diagram. Each of the inner blocks represents an atomic component, and each of the surrounding blocks represents a subsystem that groups components with similar responsibilities into layers. At the lowest level is the Hardware Abstraction Layer (HAL). The components within it encapsulate the microcontroller's peripherals or other resources and make their functionalities accessible via easy-to-use interfaces. The components of this layer are the only ones that interact directly with the microcontroller's registers, interrupts, etc., and are therefore hardware-specific. In contrast, the components in all layers above it exclusively use the interfaces of the Hardware Abstraction Layer and thus remain hardware-independent.

These include the communication layer components required for calibrating the electricity meter (DLT645), for remote reading and configuration (DLMS/COSEM), and for transferring the calculated energy consumption data between the two microcontrollers on the smart meter hardware (MQTT-SN). The utilities layer contains auxiliary components that are neither hardware-dependent nor application-specific. Above this is the metrology layer. It contains a dedicated component for each energy consumption value to be determined, responsible for its calculation. The results are passed to the application layer via appropriate interfaces. This layer comprises all the components responsible for the various downstream analysis and configuration functions, and which process and respond to the remote reading, configuration, and calibration requests received via the communication layer.

Thanks to the C language extension for components and interfaces offered by mbeddr, it was possible to implement the architecture described above directly in the code. The "component" concept was used to implement the components, and the "composite component" concept to arrange them in layers. By dividing the software into components, the implementation of the smart meter software and its inherent complexity could be broken down into relatively manageable and largely decoupled units. Using the "composite components," these units could be assembled into a hierarchically structured overall system whose internal structure remains easily comprehensible.

All interactions between the components take place via explicitly defined interfaces that the components can provide or use (see Figures 3 and 4)., PDFFor defining interfaces, mbeddr offers two alternative concepts: the "client/server interface" for interfaces with operation-call semantics and the "sender/receiver interface" for data-driven interfaces. This allows direct dependencies between component implementations to be completely avoided. Each component can easily be replaced by an alternative implementation. The only requirement is that both provide or use the same interfaces.

Hardware-independent testing

This consistently component-oriented architectural approach paved the way for further innovations in the implementation of smart meter software. It made it easy to implement hardware-independent module and integration tests that could be executed on the development machine or a build server and were not dependent on the presence of the target hardware. This simply required replacing the components of the hardware abstraction layer with suitable pseudo-implementations or emulators. In mbeddr, this is supported by the concepts of "stub component" and "mock component." Dedicated concepts such as "testcase" and "assert" are also available for writing the test code that calls the components under test and verifies the results (see Figure 5)., PDF).

In addition to implementing numerous module tests for individual components, this principle proved highly advantageous for testing the components used to calculate energy consumption values in the metrology layer. The key challenge here was that the components under test could not be tested with single calls, but rather required discrete input signals for a representative duration. For this purpose, the components used to drive the sigma-delta A/D converters were replaced by a simulator capable of generating predefined series of sampled instantaneous voltage and current values. The tests themselves were designed to traverse the entire value range of the relevant input signals in small increments (e.g., 0V to 250V in 1V steps for the RMS voltage calculation component).

For each step, a series of sampled instantaneous voltage and/or current values corresponding to the currently considered input signal value is simulated. The actually calculated energy consumption value is then compared to the expected energy consumption value. It should be noted that, for efficiency reasons, the calculation of the energy consumption values had to be implemented using fixed-point arithmetic and therefore cannot provide 100% exact results. In the associated tests, the deviation between the actually calculated and the theoretically expected energy consumption value is determined, and it is checked whether this deviation remains below a certain limit for all considered combinations of input signals. Ultimately, using such hardware-independent tests, it was possible not only to ensure the correctness of the components for calculating the energy consumption values but also to make a statement about their accuracy (see Table 1)., PDF).

Step-by-step commissioning

Although the majority of the smart meter software could be validated through hardware-independent testing, it was naturally impossible to verify all aspects in this way. These latter aspects include, on the one hand, most of the hardware-related components from the hardware abstraction layer, and on the other hand, the real-time behavior of the overall application. Testing these aspects, as well as commissioning the smart meter software as a whole, therefore had to be carried out in the conventional manner on the target hardware.

Nevertheless, the modular architecture of the smart meter software proved to be a decisive advantage here as well. Instead of having to get the entire code running at once, it was very easy to initially integrate and test only selected subsets of components on the target hardware. This allowed commissioning to begin with a very small and manageable selection of components. Subsequently, more and more components were added gradually until the full scope of the smart meter software was reached. This approach greatly simplified the integration and testing of components from the hardware abstraction layer. It was also very helpful in isolating a difficult-to-find bug that only surfaced when two of the supported communication protocols (DLT645 and MQTT-SN) were used in parallel.

Thanks to the hardware-independent tests conducted beforehand, the commissioning of the smart meter software on the target hardware was completed in a very short time. After identifying and correcting the few remaining errors, the full functionality was immediately available. The otherwise typical lengthy debugging process on the target hardware and the tedious workaround from bug to bug were almost entirely avoided.

Efficiency of the resulting C code

To ensure that the advantages resulting from the innovative development approach described here do not come at the expense of the efficiency of the resulting C code, the smart meter software was evaluated with regard to its code size and runtime performance.

The code sizes were determined separately for each of the sub-applications intended for the two microcontrollers on the smart meter hardware and are shown in Table 2 (see PDF). Given that each microcontroller is equipped with 128 KB of flash memory and 8 KB of static RAM, these figures demonstrate that the smart meter software has undoubtedly remained compact enough to run on the intended target hardware.

To evaluate runtime performance, the execution times required for the various calculations to determine energy consumption values on all three phases were measured. These were then analyzed in relation to the sampling rate of 4096 samples/s used to determine the instantaneous voltage and current values. It was found that a utilization reserve of approximately 20 % remained between the end of the calculations and the end of the sampling period, which is more than sufficient for the reliable operation of the smart meter software on the available target hardware.

In summary, it can be concluded that the use of mbeddr and its C language extensions had no significant negative impact on the efficiency of the smart meter software. The resulting C code generated by mbeddr was both compact and fast enough to be usable within the resource limits imposed by the target hardware.

Summary

The smart meter software described here is not the only, but one of the largest industrial projects implemented using mbeddr. The experience gained demonstrates that the long-standing contradiction in the world of embedded software development can be overcome. Instead of limiting oneself to the low-level language constructs and very limited structuring options of the C programming language due to concerns about code size and runtime performance, mbeddr allows for the skillful combination of C's efficiency advantages with the benefits of problem-oriented language concepts and representations. Considering the currently widespread practices in embedded software development, this holds largely untapped potential for improvements in quality and productivity.

By introducing hierarchical, component-oriented architectures, the resulting code can be structured clearly and concisely, with easily identifiable responsibilities and dependencies, and remains manageable despite its inherent complexity. Simultaneously, it becomes possible to isolate individual or multiple components from the overall application and test them directly on the development machine. This allows for the detection of errors and the prevention of regressions in a large part of the application from the very beginning of development, regardless of the availability date of the target hardware. Commissioning on the target hardware is also significantly simplified and accelerated. Firstly, due to the hardware-independent tests performed beforehand, only a few undetected errors typically remain. Secondly, thanks to the component-oriented structure of the application, commissioning can be carried out in stages, making it comparatively easy to isolate, identify, and resolve any errors.

Beyond this, the component-oriented architectures easily implemented with mbeddr offer enormous advantages regarding code reuse and the use of platform-based approaches for developing embedded software. Just as components can be integrated for hardware-independent tests or partial applications for phased deployment, they can also be used to create entirely new applications using a modular approach. To facilitate this, it is advisable to extract the reusable portion of the components from the project-specific codebase and provide them in libraries that can be used across projects, or to develop these components in such libraries from the outset.

It should be noted that the aspects described here, while essential, do not represent all the possibilities for modernizing embedded software development using mbeddr. In addition to utilizing the numerous other C language extensions available in mbeddr, which could not be discussed in detail within this article, many further simplifications and productivity gains can be achieved by incorporating user-defined C language extensions. Interested readers are referred to relevant further literature [5].

Bibliography and list of sources

[1] MSP430F5x/6x Low Power and Performance Microcontroller

[2] IEC 62053-24:2014: Electricity metering equipment (ac) – Particular requirements –
Part 24: Static meters for reactive energy at fundamental frequency (classes 0.5 S, 1S and 1)

[3] What is DLMS/COSEM?

[4] C. Ebert and C. Jones. Embedded software: facts, figures, and future. Computers, 42(4), April 2009.

[5] M. Voelter, D. Ratiu, B. Kolb, and B. Schaetz. mbeddr: instantiating a language workbench in the embedded software domain. Automated Software Engineering, 20(3), 2013.

[6] DSL Development Environment

Download the article as a PDF


Open Source – 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 Open Source / Embedded Software Engineering.

Training & coaching on the other topics in our portfolio can be found here. here.


Open Source – Expertise

Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.

To the specialist information

You can find expertise on other topics in our portfolio here. here.

MicroConsult Newsletter

With the MicroConsult newsletter, you'll stay on the pulse of the embedded world. Look forward to proven practical knowledge, real professional tips, and current events – directly from our experts for your project success.

Subscribe now!

Published by

weissblau media

weissblau media