Autoren: Dr. Stephan Eberle, itemis France SAS; Bernd Kolb, itemis und Dr. Markus V\u00f6lter<\/p>\n
\u00dcber 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\u00e4ngige Testbarkeit, einen geringen Integrationaufwand sowie eine hohe Wiederverwendbarkeit durch einen plattformbasierten Entwicklungsansatz. Die Smart Meter Software wurde vollst\u00e4ndig mit mbeddr umgesetzt, einer Open Source IDE zur Entwicklung von eingebetteter Software, die auf einer erweiterbaren Version von C basiert. Unter anderem unterst\u00fctzt mbeddr C Erweiterungen f\u00fcr Zustandsmaschinen, physikalische Einheiten und Komponenten. mbeddr ist au\u00dferdem 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.<\/strong><\/p>\n Ein Smart Meter ist ein intelligenter Stromz\u00e4hler, der kontinuierlich den elektrischen Energieverbrauch misst und aufzeichnet, verschiedene Analysen durchf\u00fchrt sowie die Steuerung des Energieverbrauchs erm\u00f6glicht (z.B. Mehrtarifunterst\u00fctzung, Missbrauchserkennung, Lastprofilerstellung, historische Datenaufzeichnung) und vom Energieversorger aus der Ferne ausgelesen und konfiguriert werden kann. Die Hardware des hier betrachteten Smart Meters f\u00fcr 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\u00f6nnen und \u00fcber 128 KB Flash- und 8 KB statischen RAM-Speicher verf\u00fcgen. Der eine Prozessor ist f\u00fcr die zeitkritische Durchf\u00fchrung der Mess- und Metering-Funktionen („Metrology“) zust\u00e4ndig, der andere f\u00fcr die nachgelagerten Analyse- und Konfigurationsfunktionen sowie f\u00fcr die Kommunikation. Die geforderte Genauigkeitsklasse entsprechend der IEC 62053 Norm [2] ist 0,5 (d.h. max 0,5 % Abweichung) f\u00fcr alle zu messenden Wirkwerte und 2,0 (d.h. max 2,0 % Abweichung) f\u00fcr s\u00e4mtliche zu messenden Blind- und Scheinwerte. Die Fernabfrage- und -konfigurationsfunktionen waren auf Basis des DLMS\/COSEM-Standards [3] umzusetzen.<\/p>\n Ein typisches Merkmal eingebetteter Software sind sehr beschr\u00e4nkte 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\u00fcr 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\u00fcssen in Echtzeit Effektivspannung und -strom, Wirk-, Blind- und Scheinleistung, Leistungsfaktor, Wirk- und Blindenergie sowie die Frequenz der Netzspannung berechnet werden. Daneben muss gen\u00fcgend Rechenzeit \u00fcbrig bleiben, um die so gewonnenen Energieverbrauchsdaten \u00fcber eine serielle Verbindung an den anderen MSP430-Mikrocontroller zu \u00fcbertragen, der diese in die nachgelagerten Analysefunktionen einflie\u00dfen l\u00e4sst und f\u00fcr die Fernauslese bereith\u00e4lt.<\/p>\n Angesichts solcher Anforderungen ist es wenig verwunderlich, dass bei der Entwicklung von eingebetteter Software der Effizienz des dabei entstehenden Codes von jeher der h\u00f6chste Stellenwert einger\u00e4umt 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\u00e4nkte M\u00f6glichkeiten, um die zu realisierende Fachlichkeit problemnah, d.h. auf eine der Anwendersicht angepassten Art und Weise, auszudr\u00fccken. Dies f\u00fchrt i.d.R. dazu, dass der resultierende Code sehr schwer verst\u00e4ndlich ist und bzgl. Wartung und Erweiterbarkeit um neue Funktionalit\u00e4ten eine enorme Herausforderung darstellt.<\/p>\n 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\u00f6rpert in erster Linie eine erweiterbare Version der Programmiersprache C. Daneben bringt mbeddr vordefinierte Spracherweiterungen mit sich, die dem Anwender sehr n\u00fctzliche und\u00a0 bzgl. des Abstraktionsgrades h\u00f6her stehende Konzepte und Notationen an die Hand zu geben. Dies sind z.B. physikalische Einheiten, Schnittstellen und Komponenten, Zustandsautomaten oder Tests. Dar\u00fcber 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\u00f6nnen, ohne die Programmiersprache C selbst \u00e4ndern zu m\u00fcssen, entwickelt werden und sind nur f\u00fcr diejenigen Anwendungen sichtbar, die die jeweilige Erweiterung explizit nutzen.<\/p>\n Wesentlich ist auch, dass s\u00e4mtliche klassischen C-Sprachkonstrukte weiterhin verf\u00fcgbar sind. So ist es parallel zur Nutzung der vielseitigen vordefinierten und ggf. vorhandenen benutzerdefinierten Spracherweiterungen jederzeit m\u00f6glich, 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\u00fcckgef\u00fchrt. Dieser kann anschlie\u00dfend mit handels\u00fcblichen Compilern f\u00fcr den jeweiligen Mikrocontrollertyp weiterverarbeitet werden.<\/p>\n Technische Grundlage f\u00fcr 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\u00fcr 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\u00fcckf\u00fchren. Zus\u00e4tzlich bietet MPS dem Anwender den gewohnten Komfort einer modernen Entwicklungsumgebung, der f\u00fcr Basissprachen und Spracherweiterungen gleicherma\u00dfen zur Verf\u00fcgung steht. Dazu geh\u00f6ren Syntaxhervorhebung, Code-Vervollst\u00e4ndigung, prompte Fehlermarkierungen, Code-Refactorings, Quickfixes und Tooltipps (s. Abbildung 1,\u00a0PDF<\/a>).<\/p>\n Durch die Verwendung von mbeddr konnte die Umsetzung der Software f\u00fcr das eingangs beschriebene Smart Meter auf sehr fortschrittliche Art und Weise erfolgen. Grundlage bildete dabei eine hochmodulare komponentenorientierte Architektur, die in Abbildung 2 (siehe\u00a0PDF<\/a>) dargestellt ist. Jeder der inneren Bl\u00f6cke stellt eine atomare Komponente dar und jeder der umgebenden Bl\u00f6cke ein Subsystem, das Komponenten mit \u00e4hnlich 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\u00e4ten \u00fcber einfach zu nutzende Schnittstellen zug\u00e4nglich. 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\u00fcber befindlichen Schichten bedienen sich dagegen ausschlie\u00dflich der Schnittstellen der Hardwareabstraktionsschicht und bleiben somit hardwareunabh\u00e4ngig.<\/p>\n Dies sind zum einen die Komponenten der Kommunikationsschicht, die f\u00fcr das Kalibrieren des Stromz\u00e4hlers ben\u00f6tigt werden (DLT645), f\u00fcr das Auslesen und Konfigurieren aus der Ferne (DLMS\/COSEM) bzw. f\u00fcr den Transfer der berechneten Energieverbrauchsdaten zwischen den beiden Mikrocontrollern auf der Smart Meter Hardware (MQTT-SN). Die Utilities-Schicht enth\u00e4lt Hilfskomponenten, die weder hardwareabh\u00e4ngig noch anwendungsspezifisch sind. Dar\u00fcber befindet sich die Metrology-Schicht (Metrology). Sie enth\u00e4lt f\u00fcr jeden zu bestimmenden Energieverbrauchswert eine dedizierte Komponente, die f\u00fcr dessen Berechnung zust\u00e4ndig ist. Die Ergebnisse werden \u00fcber entsprechende Schnittstellen an die Applikationsschicht durchgereicht. Diese umfasst alle diejenigen Komponenten, die f\u00fcr die verschiedenen nachgelagerten Analyse- und Konfigurationsfunktionen zust\u00e4ndig sind und die \u00fcber die Kommunikationsschicht eingehenden Fernauslese-, Fernkonfigurations- und Kalibrieranforderungen bearbeiten und beantworten.<\/p>\n Dank der von mbeddr angebotenen C-Spracherweiterung f\u00fcr Komponenten und Schnittstellen war es m\u00f6glich, 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\u00e4nte Komplexit\u00e4t auf verh\u00e4ltnism\u00e4\u00dfig leicht \u00fcberschaubare 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.<\/p>\n S\u00e4mtliche Interaktionen zwischen den Komponenten erfolgen \u00fcber explizit festgelegte Schnittstellen, die die Komponenten bereitstellen („provides“) bzw. nutzen („requires“) k\u00f6nnen (s. Abbildung 3 u. 4,\u00a0PDF<\/a>). F\u00fcr die Definition von Schnittstellen bietet mbeddr zwei alternative Konzepte: zum einen das „client\/server interface“ f\u00fcr Schnittstellen mit Operations-Aufruf-Semantik und zum anderen das „sender\/receiver interface“ f\u00fcr datengetriebene Schnittstellen. Dadurch k\u00f6nnen direkte Abh\u00e4ngigkeiten zwischen den Implementierungen der Komponenten vollst\u00e4ndig vermieden werden. Jede Komponente kann leicht durch eine alternative Implementierung ersetzt werden. Einzige Voraussetzung ist, dass beide dieselben Schnittstellen bereitstellen bzw. nutzen.<\/p>\n Dieser konsequent komponentenorientierte Architekturansatz war gleichzeitig der Wegbereiter f\u00fcr weitere Innovationen bei der Umsetzung der Smart Meter Software. So wurde es einfach m\u00f6glich, hardwareunabh\u00e4ngige Modul- und Integrationstests zu realisieren, die auf dem Entwicklungsrechner oder einem Buildserver ausf\u00fchrbar 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 \u00fcber die Konzepte „stub component“ und „mock component“ unterst\u00fctzt. Auch f\u00fcr das Schreiben des Testcodes, der die zu testenden Komponenten aufruft und die resultierenden Ergebnisse pr\u00fcft, stehen dedizierte Konzepte wie z.B. „testcase“ und „assert“ bereit (s. Abbildung 5,\u00a0PDF<\/a>).<\/p>\n Neben der Realisierung zahlreicher Modultests f\u00fcr einzelne Komponenten konnte dieses Prinzip sehr vorteilhaft f\u00fcr 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\u00fcr eine repr\u00e4sentative 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\u00e4ndig durchlaufen werden (z.B. 0V bis 250V in 1V-Schritten im Falle der Tests f\u00fcr die Komponente zur Berechnung der Effektivspannung).<\/p>\n F\u00fcr jeden Schritt wird eine Reihe von abgetasteten Momentanspannungs- und\/oder -Stromwerten simuliert, die dem aktuell betrachteten Eingangssignalwert entspricht. Anschlie\u00dfend wird der tats\u00e4chlich berechnete gegen den erwarteten Energieverbrauchswert gepr\u00fcft. Dabei ist zu ber\u00fccksichtigen, dass die Berechnung der Energieverbrauchswerte aus Effizienzgr\u00fcnden unter Verwendung von Festpunktarithmetik implementiert werden musste und somit keine 100% exakten Ergebnisse liefern kann. In den zugeh\u00f6rigen Tests wird deshalb die Abweichung zwischen dem tats\u00e4chlich berechneten und theoretisch zu erwartenden Energieverbrauchswert bestimmt und gepr\u00fcft, ob diese Abweichung f\u00fcr alle betrachteten Kombinationen von Eingangssignalen unterhalb eines bestimmten Grenzwertes bleibt. Letztendlich konnte mithilfe von solcherma\u00dfen umgesetzten hardwareunabh\u00e4ngigen Tests nicht nur die Richtigkeit der Komponenten zur Berechnung der Energieverbrauchswerte sichergestellt sondern auch eine Aussage \u00fcber ihre Genauigkeit getroffen werden (s. Tabelle 1,\u00a0PDF<\/a>).<\/p>\n Obwohl der Gro\u00dfteil der Smart Meter Software durch hardwareunabh\u00e4ngiges Testen validiert werden konnte, war es nat\u00fcrlich nicht m\u00f6glich, alle Aspekte auf diesem Wege zu \u00fcberpr\u00fcfen: Zu letzteren z\u00e4hlen 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\u00f6mmlicher Weise auf der Zielhardware zu erfolgen.<\/p>\n 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\u00fcssen, war es sehr einfach m\u00f6glich, zun\u00e4chst lediglich ausgew\u00e4hlte Untermengen von Komponenten auf der Zielhardware zu integrieren und zu testen. Somit konnte die Inbetriebnahme mit einer sehr kleinen und \u00fcberschaubaren Auswahl von Komponenten begonnen werden. Anschlie\u00dfend wurden schrittweise immer mehr Komponenten hinzugef\u00fcgt, bis schlie\u00dflich der Gesamtumfang der Smart Meter Software erreicht war. Diese Vorgehensweise war eine enorme Erleichterung f\u00fcr 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\u00fctzenden Kommunikationsprotokolle (DLT645 und MQTT-SN) parallel zu nutzen.<\/p>\n Dank der im Vorfeld durchgef\u00fchrten hardwareunabh\u00e4ngigen Tests konnte die Inbetriebnahme der Smart Meter Software auf der Zielhardware in k\u00fcrzester Zeit abgeschlossen werden. Nach Aufdeckung und Korrektur der wenigen noch verbleibenden Fehler war die gesamte Funktionalit\u00e4t umgehend voll verf\u00fcgbar. Das ansonsten \u00fcbliche langwierige Debuggen auf der Zielhardware und m\u00fchsame sich Vorw\u00e4rtsarbeiten von Bug zu Bug konnte dagegen fast vollst\u00e4ndig vermieden werden.<\/p>\n 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\u00f6\u00dfe und Laufzeitperformanz evaluiert.<\/p>\n Die Codegr\u00f6\u00dfen wurden f\u00fcr die Teilanwendungen, die f\u00fcr die beiden Mikrocontroller auf der Smart Meter Hardware bestimmt sind, jeweils separat ermittelt und sind in Tabelle 2 (siehe\u00a0PDF<\/a>) 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\u00f6nnen.<\/p>\n Zur Evaluierung der Laufzeitperformanz wurden die Ausf\u00fchrungszeiten gemessen, die f\u00fcr die verschiedenen Berechnungen zur Bestimmung der Energieverbrauchswerte auf allen 3 Phasen notwendig waren. Diese wurden anschlie\u00dfend 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\u00fcr den zuverl\u00e4ssigen Betrieb der Smart Meter Software auf der zur Verf\u00fcgung stehenden Zielhardware weithin ausreichend ist.<\/p>\n In der Summe l\u00e4sst 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.<\/p>\n Die hier beschriebene Smart Meter Software ist nicht das einzige, aber eines der gr\u00f6\u00dften Industrieprojekte, das mittels mbeddr umgesetzt wurden. Die dabei gewonnenen Erfahrungen zeigen, dass der alte Widerspruch aus der Welt der eingebetteten Softwareentwicklung \u00fcberwunden werden kann. Anstatt sich aus Sorge um Codegr\u00f6\u00dfe und Laufzeitperformanz auf die maschinennahen Sprachkonstrukte und sehr begrenzten Strukturierungsmittel der Programmiersprache C zu beschr\u00e4nken, k\u00f6nnen mit mbeddr die Effizienzvorteile von C und die Vorz\u00fcge 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\u00fcr Qualit\u00e4ts- und Produktivit\u00e4tsverbesserungen.<\/p>\n So kann durch die Einf\u00fchrung von hierarchischen komponentenorientierten Architekturen daf\u00fcr gesorgt werden, dass der entstehende Code \u00fcber eine klare und \u00fcbersichtliche Struktur verf\u00fcgt, einfach wiederzuerkennende Verantwortlichkeiten und Abh\u00e4ngigkeiten aufweist und trotz der ihm innewohnenden Komplexit\u00e4t beherrschbar bleibt. Gleichzeitig wird es m\u00f6glich, einzelne oder mehrere Komponenten aus der Gesamtanwendung herauszul\u00f6sen und direkt auf dem Entwicklungsrechner zu testen. Somit lassen sich in einem Gro\u00dfteil der Anwendung von Beginn der Entwicklung an und unabh\u00e4ngig vom Verf\u00fcgbarkeitstermin 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\u00fchrten hardwareunabh\u00e4ngigen Tests in der Regel nur noch wenige unerkannte Fehler \u00fcbrig. 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.<\/p>\n Abgesehen hiervon bieten die mithilfe von mbeddr leicht umzusetzenden komponentenorientierten Architekturen enorme Vorteile bzgl. der Wiederverwendung von Code und die Nutzung plattformbasierter Ans\u00e4tze zur Entwicklung eingebetteter Software. In gleicher Weise wie sich Komponenten zu hardwareunabh\u00e4ngigen Tests oder Teilanwendungen f\u00fcr die schrittweise Inbetriebnahme integrieren lassen, k\u00f6nnen sie auch genutzt werden, um gem\u00e4\u00df dem Baukastenprinzip v\u00f6llig neue Anwendungen zu erstellen. Um dies zu erleichtern, bietet es sich an, den wiederverwendbaren Anteil der Komponenten aus der projektspezifischen Codebasis herauszul\u00f6sen und in Bibliotheken bereitzustellen, die projekt\u00fcbergreifend genutzt werden k\u00f6nnen, bzw. diese Komponenten von vornherein in solchen Bibliotheken zu entwickeln.<\/p>\n Es bleibt zu erw\u00e4hnen, dass die hier beschriebenen Aspekte zwar wesentliche aber l\u00e4ngst nicht alle M\u00f6glichkeiten widerspiegeln, wie sich die Entwicklung eingebetteter Software mit Hilfe von mbeddr modernisieren l\u00e4sst. Neben der Nutzung der zahlreichen anderen C-Spracherweiterungen, die in mbeddr zur Verf\u00fcgung stehen,\u00a0 im Rahmen dieses Beitrags aber nicht n\u00e4her vorgestellt werden konnten, lassen sich auch \u00fcber das Einbringen von benutzerdefinierten C-Spracherweiterungen viele weitere Vereinfachungen und Produktivit\u00e4tsgewinne erzielen. Der interessierte Leser sei hierzu an entsprechende weiterf\u00fchrende Literatur verwiesen [5].<\/p>\n [1]\u00a0MSP430F5x\/6x Low-Power and Performance Microcontroller<\/a><\/p>\n [2] IEC 62053-24:2014: Electricity metering equipment (a.c.) – Particular requirements – [3]\u00a0What is DLMS\/COSEM?<\/a><\/p>\n [4] C. Ebert and C. Jones. Embedded software: facts, figures, and future. Computer, 42(4), April 2009.<\/p>\n [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.<\/p>\n [6]\u00a0DSL Development Environment<\/a><\/strong><\/p>\n Beitrag als PDF downloaden Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Open Source \/ Embedded Software Engineering.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nMehr Abstraktion contra effiziente Software – der ewige Widerspruch<\/h2>\n
mbeddr – das flexibel erweiterbare C<\/h2>\n
Komponentenorientierte Architektur<\/h2>\n
Hardwareunabh\u00e4ngiges Testen<\/h2>\n
Schrittweise Inbetriebnahme<\/h2>\n
Effizienz des resultierenden C-Codes<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\nPart 24: Static meters for reactive energy at fundamental frequency (classes 0,5 S, 1S and 1)<\/a><\/p>\n
\n<\/strong><\/a><\/p>\n
\nOpen Source – unsere Trainings & Coachings<\/h2>\n
\nOpen Source – Fachwissen<\/h2>\n