en
de

Ein Blick in die Zühlke Embedded Platform – Teil 2

15 April 2016
| |
Lesezeit: 4 Minutes

Im ersten Teil dieses Blog-Posts haben wir die Eckpfeiler einer tragfähigen Embedded-Plattform abgeleitet.
Die Plattform muss auf eine Menge von ausreichend ähnlichen Projekten ausgerichtet sein. Sie muss konkrete Lösungen für die ähnlichen Aspekte beinhalten. In allen anderen Punkten muss sie flexibel und erweiterbar sein. Variantenspezifische Ausprägungen zentraler Plattform-Features sollten sich modellbasiert konfigurieren lassen.

Was das konkret bedeutet und welche Festlegungen sich daraus für die Zühlke Embedded Platform ergeben haben, soll im Folgenden dargelegt werden.

Firmware-Architektur

Wir beginnen mit einigen konkreten Beobachtungen aus zahlreichen Firmware-Projekten:

  • Die High-Level-Applikationsschicht ist projektspezifischer als die darunterliegenden Software-Schichten. Technische Dienste (zum Beispiel Persistenz), Hardware-Treiber und Betriebssystem-Abstraktion lassen sich leichter verallgemeinern.
  • Viele Geräte realisieren Mess-, Steuer- oder Regel-Funktionalität, die dem klassischen Zyklus aus Eingabe, Verarbeitung und Ausgabe unterliegt. Dies erinnert nicht ohne Grund an SPSen, bei denen die Software zyklisch auf ein Prozessbild zugreift, das die Eingabewerte der Sensorik und die Ausgabewerte der Aktorik reflektiert.
  • Neben einer horizontalen Trennung von Modulen der Applikationsschicht empfiehlt sich auch eine vertikale Trennung von Abstraktiongsgraden und Hardware-Nähe. Insbesondere sollte der mittlere Bereich der Architektur zwischen Prozessbild und konkreten Sensoren/Aktoren trennen — und das Mapping zwischen beiden Welten in einer Zwischenschicht kapseln.

Aus diesen Gründen trifft die Zühlke Embedded Platform keinerlei Aussagen über die Applikationsschicht. Sie liefert vielmehr die Middleware, in der sich die hier aufgeführten Gemeinsamkeiten wiederfinden. Die ihrer Natur nach projektspezifischen Applikations-Module werden dann projektspezifisch entwickelt und über einen zyklischen scheduler aufgerufen — zum Beispiel mit 1, 10 oder 500 Hertz.

Geräte-Umgebung

Eine weitere Beobachtung besteht darin, dass eine Geräte-Firmware keine Insel darstellt. Sie muss vielmehr in einem größeren Zusammenhang gesehen werden:

  • Neben der Implementierung der Firmware spielt auch das Testing eine immens wichtige Rolle. Es muss eine Test-Infrastruktur geben, und diese muss Zugriff auf das Prozessbild im Gerät haben. Andernfalls verbaut man sich den Weg zu continuous integration und Testautomatisierung — und wird es später bitter bereuen.
  • Analog dazu steht dem eigentlichen Gerät in vielen Projekten immer auch eine daran anzuschließende, PC-basierte Anzeigevorrichtung gegenüber — im Folgenden Cockpit genannt. Auch dieses Cockpit benötigt Zugriff auf das Prozessbild.
  • Ferner wäre es wünschenswert, die Sensoren/Aktoren, das Prozessbild und das entsprechende Mapping nicht implizit im Quelltext der Firmware verstecken zu müssen. Vielmehr sollten diese zentralen Aspekte des Systems explizit modelliert werden — zum Beispiel in einer geeigneten DSL (also einer domain-specific language). Aus dieser DSL könnten dann nicht nur die entsprechenden Teile der Firmware, sondern auch die zugehörigen Test- und Cockpit-Bibliotheken generiert werden. Außerdem wird dadurch die Unterstützung von Gerätevarianten mit verschiedenen Konfigurationen bezüglich Sensorik/Aktorik ermöglicht.

Eine Besonderheit des Cockpits besteht darin, dass ein zyklischer Zugriff auf das Prozessbild bei einem entsprechenden Umfang der relevanten Daten zu einem Engpass in der Bandbreite führen kann. Deshalb kann dieser Zugriff von einem zyklischen pull auf ein observierendes push umgestellt werden, bei dem Änderungen an betroffenen Datenpunkten unmittelbar ans Cockpit gemeldet werden.

Sprachen- und Werkzeugauswahl

Darüber hinaus etablieren wir in der Zühlke Embedded Platform einige best practices und bewährte Werkzeuge:

  • Die Firmware sollte in einer Programmiersprache implementiert werden, die einerseits möglichst ausdrucksstark und andererseits möglichst weit verbreitet ist. Dies liefert den besten Kompromiss zwischen Effizienz in der Entwicklung und Unabhängigkeit von konkreten Mikrocontrollern sowie Toolchains (Compiler, Linker, Laufzeitbibliotheken), Betriebssystemen und so weiter. Damit fällt die Wahl relativ konkurrenzlos auf C++.
  • Sowohl für das Cockpit als auch für die Test-Umgebung sollte eine möglichst ausdrucksstarke und zukunftssichere Programmiersprache aus der Desktop-Welt zum Einsatz kommen. Hier bietet sich unserer Erfahrung nach besonders C# an.
  • Für uns gehören Testautomatisierung und continuous integration (CI) zu den Selbstverständlichkeiten einer Firmware-Entwicklung. Das CI-System basiert auf dem bewährten Werkzeug Jenkins.

Diese Technologie-Entscheidungen stellen im Allgemeinen keine zu starken Einschränkungen dar, sondern erlauben vielmehr ein effizientes Aufziehen des jeweiligen Entwicklungsprojekts.

Die Gesamtarchitektur der Firmware und ihrer Umsysteme ist im folgenden Bild schematisch dargestellt:

Schema Zühlke Embedded Platform

Die Realisierung der DSL

Die modellbasierte Beschreibung der Sensoren, Aktoren und Datenpunkte durch eine textuelle (statt grafische) DSL bildet eine zentrale Säule der Zühlke Embedded Platform. Für die konkrete Umsetzung dieser DSL und der dazugehörigen Code-Generatoren stehen verschiedene Werkzeuge zur Verfügung, die entsprechend der gegebenen Projektbedingungen gewählt werden können:

  • Die DSL kann über XText realisiert werden. Dieses Werkzeug ist weit verbreitet und gestattet viele Erweiterungen (etwa hinsichtlich Editor-Unterstützung), ist aber sehr schwergewichtig, bläht die Entwicklungsumgebung auf und erzwingt einen vendor lock-in.
  • Alternativ kann die DSL über eine interne C#-DSL umgesetzt werden, die zu genau diesem Zweck bei Zühlke entwickelt wurde: Xerus. Diese ist sehr leichtgewichtig, zumal C# wegen Cockpit und Test-Umgebung sowieso schon zur Entwicklungsumgebung gehört.
  • Ebenso kann eine externe DSL mit Ruby-Generatoren verwendet werden, und zwar basierend auf dem in diesem Blog vorgestellten Diesel-Ansatz. Dieser Ansatz ist besonders schlank und fügt sich leicht in das rubybasierte Buildsystem rake ein, das wir erfolgreich in immer mehr Firmware-Projekten nutzen.

Anwendungsszenarien

Wie oben und im ersten Teil dieses Blog-Posts ausgeführt gilt, dass eine seriöse Plattform immer nur eine bestimmte Art von Projekten abdecken kann. Als Dienstleister ist es uns deshalb wichtig, genau abzugrenzen, für welche Aufgaben die Zühlke Embedded Platform produktiv anwendbar ist — und in welchen Fällen nicht.

Aus der Firmware-Architektur der Plattform folgt, dass sie ihre Stärken genau dort entfaltet, wo die eigentliche Applikation — mit fachlichen Abläufen, die für den Benutzer in der gegebenen Domäne bedeutsam sind — wie oben beschrieben aufgebaut werden kann: als eine Menge von Modulen, die zyklisch auf das Prozessbild zugreifen. Das ist insbesondere dann der Fall, wenn Mess-, Steuer- und Regel-Aufgaben zu bewältigen sind. Aus diesem Grund setzen wir die Zühlke Embedded Platform auch primär bei Entwicklungsprojekten im Umfeld der Automatisierung von Gebäuden, Maschinen und Anlagen ein. Das Konzept wurde bereits erfolgreich auf Heizungsanlagen, in der Profikochtechnik und für Klimatisierungslösungen angewandt.

Im Gegensatz dazu ist die Architektur der Plattform weniger geeignet, wenn nicht so sehr das Messen, Steuern oder Regeln im Vordergrund steht, sondern zum Beispiel komplexe, interaktive Workflows. Ähnliches gilt, wenn ein gemeinsames Prozessbild die falsche Metapher ist und die verschiedenen Applikations-Module vielmehr nachrichtenbasiert und ohne shared state kollaborieren sollten. Für derartige Fälle empfehlen und nutzen wir andere Ansätze.

Fazit

Die Zühlke Embedded Platform stellt keinen Versuch dar, alle erdenklichen Embedded-Projekte abzudecken — denn an diesem Anspruch würde eine jede Plattform scheitern, nämlich durch übermäßige Verallgemeinerung und wenig konkreten Mehrwert. Vielmehr liefert sie konkrete Konzepte und Bausteine, die auf die spezifischen Bedürfnisse von Entwicklungsprojekten rund um das Messen, Steuern und Regeln zugeschnitten sind. Sie ist konkret, wo das in diesem Umfeld sinnvoll möglich ist, und lässt dennoch ausreichend Spielraum für Gerätevarianten und projektspezifische Funktionalität. Außerdem beschränkt sie sich nicht auf die eigentliche Firmware, sondern berücksichtigt von Anfang an auch übergeordnete Themen wie etwa eine solide Testautomatisierung. Somit liefert sie die idealen Voraussetzungen für eine beschleunigte Realisierung — und bringt Projekte im Bereich der Automatisierung von Maschinen und Anlagen schneller auf die Straße.

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »