ESE Fachwissen
Embedded Software Engineering Reloaded: mbeddr
Autoren: Dr. Stephan Eberle, itemis France SAS; Bernd Kolb, itemis und Dr. Markus Völter
Beitrag - Embedded Software Engineering Kongress 2015
Über die letzten drei Jahre wurde von itemis Frankreich ein Smart Meter entwickelt, dessen eingebettete Software sich belegbar durch die folgenden Eigenschaften auszeichnet: eine wartbare, modulare Architektur, hardwareunabhängige Testbarkeit, einen geringen Integrationaufwand sowie eine hohe Wiederverwendbarkeit durch einen plattformbasierten Entwicklungsansatz. Die Smart Meter Software wurde vollständig mit mbeddr umgesetzt, einer Open Source IDE zur Entwicklung von eingebetteter Software, die auf einer erweiterbaren Version von C basiert. Unter anderem unterstützt mbeddr C Erweiterungen für Zustandsmaschinen, physikalische Einheiten und Komponenten. mbeddr ist außerdem sehr weitgehend anpassbar, insbesondere durch benutzerdefinierte C-Spracherweiterungen. Dabei erzeugt die mbeddr-basierte Implementierung nur einen sehr geringen Overhead im Vergleich zu klassisch implementiertem C Code.
Ein Smart Meter ist ein intelligenter Stromzähler, der kontinuierlich den elektrischen Energieverbrauch misst und aufzeichnet, verschiedene Analysen durchführt sowie die Steuerung des Energieverbrauchs ermöglicht (z.B. Mehrtarifunterstützung, Missbrauchserkennung, Lastprofilerstellung, historische Datenaufzeichnung) und vom Energieversorger aus der Ferne ausgelesen und konfiguriert werden kann. Die Hardware des hier betrachteten Smart Meters für 3-phasigen Wechselstrom (Drehstrom) wurde mit 2 MSP430-Mikrocontrollern von Texas Instruments [1] ausgestattet. Dabei handelt es sich um 16-Bit CPUs, die mit bis zu 25 MHz getaktet werden können und über 128 KB Flash- und 8 KB statischen RAM-Speicher verfügen. Der eine Prozessor ist für die zeitkritische Durchführung der Mess- und Metering-Funktionen ("Metrology") zuständig, der andere für die nachgelagerten Analyse- und Konfigurationsfunktionen sowie für die Kommunikation. Die geforderte Genauigkeitsklasse entsprechend der IEC 62053 Norm [2] ist 0,5 (d.h. max 0,5 % Abweichung) für alle zu messenden Wirkwerte und 2,0 (d.h. max 2,0 % Abweichung) für sämtliche zu messenden Blind- und Scheinwerte. Die Fernabfrage- und -konfigurationsfunktionen waren auf Basis des DLMS/COSEM-Standards [3] umzusetzen.
Mehr Abstraktion contra effiziente Software - der ewige Widerspruch
Ein typisches Merkmal eingebetteter Software sind sehr beschränkte Resourcen bei gleichzeitig hohen Echtzeitanforderungen. Im vorliegenden Fall des Smart Meters macht sich dieser Umstand vor allem bei den Mess- und Metering-Funktionen bemerkbar: Hierfür werden auf einem der beiden MPS430-Mikrocontroller die Momentanspannungs- und -stromwerte aller 3 Phasen mithilfe von schnellen Sigma-Delta-A/D-Wandlern bei einer Abtastrate von 4096 sample/s erfasst. Daraus müssen in Echtzeit Effektivspannung und -strom, Wirk-, Blind- und Scheinleistung, Leistungsfaktor, Wirk- und Blindenergie sowie die Frequenz der Netzspannung berechnet werden. Daneben muss genügend Rechenzeit übrig bleiben, um die so gewonnenen Energieverbrauchsdaten über eine serielle Verbindung an den anderen MSP430-Mikrocontroller zu übertragen, der diese in die nachgelagerten Analysefunktionen einfließen lässt und für die Fernauslese bereithält.
Angesichts solcher Anforderungen ist es wenig verwunderlich, dass bei der Entwicklung von eingebetteter Software der Effizienz des dabei entstehenden Codes von jeher der höchste Stellenwert eingeräumt wurde. Bis heute wird ca. 80% der industriell erstellten eingebetteten Software mit der Programmiersprache C realisiert [4]. C ist sehr gut geeignet, um Algorithmen maschinennah und damit effizient umzusetzen. Im Gegenzug bietet C aber nur sehr eingeschränkte Möglichkeiten, um die zu realisierende Fachlichkeit problemnah, d.h. auf eine der Anwendersicht angepassten Art und Weise, auszudrücken. Dies führt i.d.R. dazu, dass der resultierende Code sehr schwer verständlich ist und bzgl. Wartung und Erweiterbarkeit um neue Funktionalitäten eine enorme Herausforderung darstellt.
mbeddr - das flexibel erweiterbare C
Die Suche nach einem Ausweg aus diesem offensichtlichen Widerspruch war die zentrale Motivation bei der Entwicklung von mbeddr [5]. mbeddr ist Open Source und verkörpert in erster Linie eine erweiterbare Version der Programmiersprache C. Daneben bringt mbeddr vordefinierte Spracherweiterungen mit sich, die dem Anwender sehr nützliche und bzgl. des Abstraktionsgrades höher stehende Konzepte und Notationen an die Hand zu geben. Dies sind z.B. physikalische Einheiten, Schnittstellen und Komponenten, Zustandsautomaten oder Tests. Darüber hinaus kann der Anwender jederzeit eigene Spracherweiterungen definieren und diese zusammen mit den existierenden Erweiterungen nutzen. Sowohl die vordefinierten als auch die benutzerdefinierten Erweiterungen sind modular: Sie können, ohne die Programmiersprache C selbst ändern zu müssen, entwickelt werden und sind nur für diejenigen Anwendungen sichtbar, die die jeweilige Erweiterung explizit nutzen.
Wesentlich ist auch, dass sämtliche klassischen C-Sprachkonstrukte weiterhin verfügbar sind. So ist es parallel zur Nutzung der vielseitigen vordefinierten und ggf. vorhandenen benutzerdefinierten Spracherweiterungen jederzeit möglich, maschinennahen und hocheffizienten Code zu schreiben, wann immer dies notwendig wird. Am Ende wird die Gesamtheit des mit mbeddr geschriebenen Codes im Rahmen eines Generierungsprozesses wieder auf klassischen C99-Code zurückgeführt. Dieser kann anschließend mit handelsüblichen Compilern für den jeweiligen Mikrocontrollertyp weiterverarbeitet werden.
Technische Grundlage für mbeddr und die modulare Erweiterbarkeit der Programmiersprache C ist die MPS-Plattform von JetBrains [6]. MPS ist Open Source und liefert die notwendige Infrastruktur, um neue Sprachen oder Erweiterungen für vorhandene Sprachen zu definieren, dazu passende textuelle oder grafische Notationen festzulegen sowie Codegeneratoren zu implementieren, die die neuen Sprachen bzw. Spracherweiterungen auf eine Basissprache zurückführen. Zusätzlich bietet MPS dem Anwender den gewohnten Komfort einer modernen Entwicklungsumgebung, der für Basissprachen und Spracherweiterungen gleichermaßen zur Verfügung steht. Dazu gehören Syntaxhervorhebung, Code-Vervollständigung, prompte Fehlermarkierungen, Code-Refactorings, Quickfixes und Tooltipps (s. Abbildung 1, PDF).
Komponentenorientierte Architektur
Durch die Verwendung von mbeddr konnte die Umsetzung der Software für das eingangs beschriebene Smart Meter auf sehr fortschrittliche Art und Weise erfolgen. Grundlage bildete dabei eine hochmodulare komponentenorientierte Architektur, die in Abbildung 2 (siehe PDF) dargestellt ist. Jeder der inneren Blöcke stellt eine atomare Komponente dar und jeder der umgebenden Blöcke ein Subsystem, das Komponenten mit ähnlich gelagerten Verantwortlichkeiten zu Schichten zusammenfasst. Auf der untersten Ebene befindet sich die Hardwareabstraktionsschicht (HAL). Die darin enthaltenen Komponenten kapseln die Peripherieeinheiten oder sonstige Ressourcen des Mikrocontrollers und machen deren Funktionalitäten über einfach zu nutzende Schnittstellen zugänglich. Die Komponenten dieser Schicht sind die einzigen, die direkt mit den Registern, Interrupts usw. des Mikrocontrollers interagieren und somit hardwarespezifisch sind. Die Komponenten in allen darüber befindlichen Schichten bedienen sich dagegen ausschließlich der Schnittstellen der Hardwareabstraktionsschicht und bleiben somit hardwareunabhängig.
Dies sind zum einen die Komponenten der Kommunikationsschicht, die für das Kalibrieren des Stromzählers benötigt werden (DLT645), für das Auslesen und Konfigurieren aus der Ferne (DLMS/COSEM) bzw. für den Transfer der berechneten Energieverbrauchsdaten zwischen den beiden Mikrocontrollern auf der Smart Meter Hardware (MQTT-SN). Die Utilities-Schicht enthält Hilfskomponenten, die weder hardwareabhängig noch anwendungsspezifisch sind. Darüber befindet sich die Metrology-Schicht (Metrology). Sie enthält für jeden zu bestimmenden Energieverbrauchswert eine dedizierte Komponente, die für dessen Berechnung zuständig ist. Die Ergebnisse werden über entsprechende Schnittstellen an die Applikationsschicht durchgereicht. Diese umfasst alle diejenigen Komponenten, die für die verschiedenen nachgelagerten Analyse- und Konfigurationsfunktionen zuständig sind und die über die Kommunikationsschicht eingehenden Fernauslese-, Fernkonfigurations- und Kalibrieranforderungen bearbeiten und beantworten.
Dank der von mbeddr angebotenen C-Spracherweiterung für Komponenten und Schnittstellen war es möglich, die vorstehend beschriebene Architektur 1:1 im Code umzusetzen. Dabei wurde das Konzept "component" zur Implementierung der Komponenten benutzt und das Konzept "composite component" zur Anordnung derselben in Schichten. Durch die Aufteilung in Komponenten konnte die Implementierung der Smart Meter Software und deren inheränte Komplexität auf verhältnismäßig leicht überschaubare und weitestgehend voneinander entkoppelte Einheiten heruntergebrochen werden. Mithilfe der "composite components" konnten diese zu einem hierarchisch aufgebauten Gesamtsystem zusammengesetzt werden, dessen innere Struktur einfach nachvollziehbar bleibt.
Sämtliche Interaktionen zwischen den Komponenten erfolgen über explizit festgelegte Schnittstellen, die die Komponenten bereitstellen ("provides") bzw. nutzen ("requires") können (s. Abbildung 3 u. 4, PDF). Für die Definition von Schnittstellen bietet mbeddr zwei alternative Konzepte: zum einen das "client/server interface" für Schnittstellen mit Operations-Aufruf-Semantik und zum anderen das "sender/receiver interface" für datengetriebene Schnittstellen. Dadurch können direkte Abhängigkeiten zwischen den Implementierungen der Komponenten vollständig vermieden werden. Jede Komponente kann leicht durch eine alternative Implementierung ersetzt werden. Einzige Voraussetzung ist, dass beide dieselben Schnittstellen bereitstellen bzw. nutzen.
Hardwareunabhängiges Testen
Dieser konsequent komponentenorientierte Architekturansatz war gleichzeitig der Wegbereiter für weitere Innovationen bei der Umsetzung der Smart Meter Software. So wurde es einfach möglich, hardwareunabhängige Modul- und Integrationstests zu realisieren, die auf dem Entwicklungsrechner oder einem Buildserver ausführbar und nicht an das Vorhandensein der Zielhardware gebunden sind. Dazu mussten lediglich die Komponenten der Hardwareabstraktionsschicht durch geeignete Pseudoimplementierungen oder Emulatoren ersetzt werden. Dies wird in mbeddr über die Konzepte "stub component" und "mock component" unterstützt. Auch für das Schreiben des Testcodes, der die zu testenden Komponenten aufruft und die resultierenden Ergebnisse prüft, stehen dedizierte Konzepte wie z.B. "testcase" und "assert" bereit (s. Abbildung 5, PDF).
Neben der Realisierung zahlreicher Modultests für einzelne Komponenten konnte dieses Prinzip sehr vorteilhaft für das Testen der Komponenten zur Berechnung der Energieverbrauchswerte in der Metrology-Schicht genutzt werden. Die Besonderheit bestand hier darin, dass die zu testenden Komponenten nicht durch einzelne Aufrufe getestet werden konnten, sondern für eine repräsentative Zeitdauer mit diskreten Eingangssignalen belegt werden mussten. Zu diesem Zweck wurden die Komponenten zur Ansteuerung der Sigma-Delta-A/D-Wandler durch einen Simulator ersetzt, mit dem sich vordefinierte Reihen von abgetasteten Momentanspannungs- und -stromwerten generieren lassen. Die Tests selbst wurden so gestaltet, dass die Wertebereiche der jeweils relevanten Eingangssignale in kleinen Schritten vollständig durchlaufen werden (z.B. 0V bis 250V in 1V-Schritten im Falle der Tests für die Komponente zur Berechnung der Effektivspannung).
Für jeden Schritt wird eine Reihe von abgetasteten Momentanspannungs- und/oder -Stromwerten simuliert, die dem aktuell betrachteten Eingangssignalwert entspricht. Anschließend wird der tatsächlich berechnete gegen den erwarteten Energieverbrauchswert geprüft. Dabei ist zu berücksichtigen, dass die Berechnung der Energieverbrauchswerte aus Effizienzgründen unter Verwendung von Festpunktarithmetik implementiert werden musste und somit keine 100% exakten Ergebnisse liefern kann. In den zugehörigen Tests wird deshalb die Abweichung zwischen dem tatsächlich berechneten und theoretisch zu erwartenden Energieverbrauchswert bestimmt und geprüft, ob diese Abweichung für alle betrachteten Kombinationen von Eingangssignalen unterhalb eines bestimmten Grenzwertes bleibt. Letztendlich konnte mithilfe von solchermaßen umgesetzten hardwareunabhängigen Tests nicht nur die Richtigkeit der Komponenten zur Berechnung der Energieverbrauchswerte sichergestellt sondern auch eine Aussage über ihre Genauigkeit getroffen werden (s. Tabelle 1, PDF).
Schrittweise Inbetriebnahme
Obwohl der Großteil der Smart Meter Software durch hardwareunabhängiges Testen validiert werden konnte, war es natürlich nicht möglich, alle Aspekte auf diesem Wege zu überprüfen: Zu letzteren zählen einerseits die meisten hardwarenahen Komponenten aus der Hardwareabstraktionsschicht und andererseits das Echtzeitverhalten der Gesamtanwendung. Das Testen dieser Aspekte sowie auch die Inbetriebnahme der Smart Meter Software als Ganzes musste daher in herkömmlicher Weise auf der Zielhardware zu erfolgen.
Nichtsdestotrotz hat sich auch hier die modulare Architektur der Smart Meter Software als entscheidender Vorteil erwiesen. Anstatt den gesamten Code auf einmal zum Laufen bringen zu müssen, war es sehr einfach möglich, zunächst lediglich ausgewählte Untermengen von Komponenten auf der Zielhardware zu integrieren und zu testen. Somit konnte die Inbetriebnahme mit einer sehr kleinen und überschaubaren Auswahl von Komponenten begonnen werden. Anschließend wurden schrittweise immer mehr Komponenten hinzugefügt, bis schließlich der Gesamtumfang der Smart Meter Software erreicht war. Diese Vorgehensweise war eine enorme Erleichterung für das Integrieren und Testen der Komponenten aus der Hardwareabstraktionsschicht. Sie war ebenfalls sehr hilfreich, um einen schwer auffindbaren Fehler zu isolieren, der erst dann in Erscheinung trat, als damit begonnen wurde, zwei der zu unterstützenden Kommunikationsprotokolle (DLT645 und MQTT-SN) parallel zu nutzen.
Dank der im Vorfeld durchgeführten hardwareunabhängigen Tests konnte die Inbetriebnahme der Smart Meter Software auf der Zielhardware in kürzester Zeit abgeschlossen werden. Nach Aufdeckung und Korrektur der wenigen noch verbleibenden Fehler war die gesamte Funktionalität umgehend voll verfügbar. Das ansonsten übliche langwierige Debuggen auf der Zielhardware und mühsame sich Vorwärtsarbeiten von Bug zu Bug konnte dagegen fast vollständig vermieden werden.
Effizienz des resultierenden C-Codes
Um sicherzugehen, dass die Vorteile, die sich durch den hier beschriebenen innovativen Entwicklungsansatz ergeben, nicht zu Lasten der Effizienz des dabei entstehenden C-Codes gehen, wurde die Smart Meter Software hinsichtlich ihrer Codegröße und Laufzeitperformanz evaluiert.
Die Codegrößen wurden für die Teilanwendungen, die für die beiden Mikrocontroller auf der Smart Meter Hardware bestimmt sind, jeweils separat ermittelt und sind in Tabelle 2 (siehe PDF) wiedergegeben. Angesichts der Tatsache, dass jeder Mikrocontroller mit 128 KB Flash- und 8 KB statischem RAM-Speicher ausgestattet ist, zeigen diese Zahlen, dass die Smart Meter Software ohne jeden Zweifel kompakt genug geblieben ist, um auf der vorgesehenen Zielhardware betrieben werden zu können.
Zur Evaluierung der Laufzeitperformanz wurden die Ausführungszeiten gemessen, die für die verschiedenen Berechnungen zur Bestimmung der Energieverbrauchswerte auf allen 3 Phasen notwendig waren. Diese wurden anschließend im Hinblick auf die zur Ermittlung der Momentanspannungs- und -stromwerte benutzten Abtastrate von 4096 sample/s untersucht. Es hat sich gezeigt, dass zwischen dem Ende der Berechnungen und dem Ende der Abtastperiode noch eine Auslastungsreserve von ca. 20 % verblieb, was für den zuverlässigen Betrieb der Smart Meter Software auf der zur Verfügung stehenden Zielhardware weithin ausreichend ist.
In der Summe lässt sich daraus schlussfolgern, dass die Verwendung von mbeddr und dessen C-Spracherweiterungen keine signifikant negativen Auswirkungen auf die Effizienz der Smart Meter Software hatte. Der am Ende resultierende, von mbeddr generierte C-Code war sowohl kompakt als auch schnell genug, um innerhalb der von der Zielhardware gesetzten Ressourcengrenzen nutzbar zu sein.
Zusammenfassung
Die hier beschriebene Smart Meter Software ist nicht das einzige, aber eines der größten Industrieprojekte, das mittels mbeddr umgesetzt wurden. Die dabei gewonnenen Erfahrungen zeigen, dass der alte Widerspruch aus der Welt der eingebetteten Softwareentwicklung überwunden werden kann. Anstatt sich aus Sorge um Codegröße und Laufzeitperformanz auf die maschinennahen Sprachkonstrukte und sehr begrenzten Strukturierungsmittel der Programmiersprache C zu beschränken, können mit mbeddr die Effizienzvorteile von C und die Vorzüge problemnaher Sprachkonzepte und Darstellungsweisen geschickt kombiniert werden. Mit Blick auf die bis heute weit verbreiteten Praktiken im Bereich der eingebetteten Softwareentwicklung birgt dies ein bisher weitgehend unerkanntes Potential für Qualitäts- und Produktivitätsverbesserungen.
So kann durch die Einführung von hierarchischen komponentenorientierten Architekturen dafür gesorgt werden, dass der entstehende Code über eine klare und übersichtliche Struktur verfügt, einfach wiederzuerkennende Verantwortlichkeiten und Abhängigkeiten aufweist und trotz der ihm innewohnenden Komplexität beherrschbar bleibt. Gleichzeitig wird es möglich, einzelne oder mehrere Komponenten aus der Gesamtanwendung herauszulösen und direkt auf dem Entwicklungsrechner zu testen. Somit lassen sich in einem Großteil der Anwendung von Beginn der Entwicklung an und unabhängig vom Verfügbarkeitstermin der Zielhardware Fehler aufdecken und Regressionen vermeiden. Auch die Inbetriebnahme auf der Zielhardware wird erheblich vereinfacht und beschleunigt. Zum einen verbleiben infolge der zuvor durchgeführten hardwareunabhängigen Tests in der Regel nur noch wenige unerkannte Fehler übrig. Zum anderen kann die Inbetriebnahme dank des komponentenorientierten Aufbaus der Anwendung in Teilschritten erfolgen, sodass sich etwaige Fehler vergleichsweise leicht eingrenzen, identifizieren und beheben lassen.
Abgesehen hiervon bieten die mithilfe von mbeddr leicht umzusetzenden komponentenorientierten Architekturen enorme Vorteile bzgl. der Wiederverwendung von Code und die Nutzung plattformbasierter Ansätze zur Entwicklung eingebetteter Software. In gleicher Weise wie sich Komponenten zu hardwareunabhängigen Tests oder Teilanwendungen für die schrittweise Inbetriebnahme integrieren lassen, können sie auch genutzt werden, um gemäß dem Baukastenprinzip völlig neue Anwendungen zu erstellen. Um dies zu erleichtern, bietet es sich an, den wiederverwendbaren Anteil der Komponenten aus der projektspezifischen Codebasis herauszulösen und in Bibliotheken bereitzustellen, die projektübergreifend genutzt werden können, bzw. diese Komponenten von vornherein in solchen Bibliotheken zu entwickeln.
Es bleibt zu erwähnen, dass die hier beschriebenen Aspekte zwar wesentliche aber längst nicht alle Möglichkeiten widerspiegeln, wie sich die Entwicklung eingebetteter Software mit Hilfe von mbeddr modernisieren lässt. Neben der Nutzung der zahlreichen anderen C-Spracherweiterungen, die in mbeddr zur Verfügung stehen, im Rahmen dieses Beitrags aber nicht näher vorgestellt werden konnten, lassen sich auch über das Einbringen von benutzerdefinierten C-Spracherweiterungen viele weitere Vereinfachungen und Produktivitätsgewinne erzielen. Der interessierte Leser sei hierzu an entsprechende weiterführende Literatur verwiesen [5].
Literatur- und Quellenverzeichnis
[1] MSP430F5x/6x Low-Power and Performance Microcontroller
[2] IEC 62053-24:2014: Electricity metering equipment (a.c.) - 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. Computer, 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
Open Source - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Open Source / Embedded Software Engineering.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Open Source - Fachwissen
Wertvolles Fachwissen zum Thema Open Source / Embedded Software Engineering steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.