Über die nächsten zehn Jahre wollte ein Kunde ein neues, komplettes Produktportfolio an Sensoren, Aktoren, Transmittern und All-in-One-Geräten für die Prozessautomatisierung anbieten. In der bisherigen Generation hatte er bereits einige solche Geräte am Markt, deren Software jeweils separat entwickelt wurde. Für die neue Generation wollte der Kunde auf ein Produktplattformkonzept setzen. Es sollten die Feldbusse HART, IO-Link, Ethernet-IP und Profinet unterstützt werden und zusätzlich eine Bedienung über eine Web-UI, eine Mobile-App und ein HMI möglich sein.
Neben der Unterstützung vieler Gegenstellen, barg die Hardware aus Softwaresicht die größte Herausforderung. So befanden sich im Portfolio sowohl kleine Geräte mit nur dutzenden/hunderten Kilobyte RAM/ROM als auch große Geräte deren Ressourcenangebot jeweils um Faktor 1000 höher lag. Skalierbarkeit war daher bei den über 200 Hardwarevarianten der Schlüssel. Es galt die Plattform derart aufzubauen, dass zur Compile-Zeit dediziert nur solche Softwarekomponenten ausgewählt werden konnten, deren Funktionalität auch wirklich benötigt wurde.
Die Firmware wurde in C++20 entwickelt, wobei auf Exceptions und dynamische Speicherallokation verzichtet wurde. Einige Basisfunktionalitäten wurden über die Bibliothekensammlung Pigweed hergestellt, die sich hervorragend für kleine, speicherarme Mikrocontrollern eignet. Entwicklungsbegleitende Unittests wurden mit GoogleTest durchgeführt.
Zur Abstraktion der unterschiedlichen Hardwarevarianten wurde ein Hardware-Abstraction-Layer (HAL) eingeführt, der eine einheitliche Schnittstelle zum BSP und zur kundenspezifischen Hardware anbietet. Als Kernel kommt FreeRTOS auf allen Controllern zu Einsatz. Dessen API wird hinter einem Operating-System-Abstraction-Layer (OSAL) versteckt, so dass eine Reimplementierung mit C++-Threads möglich ist. Diese wird dazu verwendet die Firmware in einer PC-Simulation – unter Windows oder Linux – auszuführen, was die Entwicklung deutlich beschleunigt.
Es wurden Feldbusstacks von mehreren Drittanbietern integriert und ihre Schnittstellen über die geschaffenen HAL- und OSAL-Abstraktionen realisiert.
Die Firmwarekomponenten spiegeln Großteils Funktionsblöcke der Domänenprozesse wieder. Die Applikation setzt sich aus der Kombination mehrerer Funktionsblöcke zusammen, die zur Compile-Zeit ausgewählt werden. Abhängigkeiten zwischen Funktionsblöcken werden über einen Compile-Time-Dependency-Injection-Mechanismus aufgelöst, der mittels C++-Templates realisiert wurde. Damit wird eine fehlerhafte Konfiguration zur Compile-Zeit abgefangen. Die Funktionsblöcke können über einen Publish-Subscribe-Mechanismus, Message-Queues oder Parameter kommunizieren.
Um die in Automatisierungssystemen übliche Herausforderung, dass die Parameterstruktur eines Geräts an vielen Stellen in unterschiedlicher Form vorliegen muss, zu lösen, wurde modellgetriebene Softwareentwicklung eingesetzt. Dazu wird das Datenmodell der Geräte in Python spezifiziert und dann mittels Jinja-Templates übersetzt in:
- eine Beschreibungsdatei für ein proprietäres Format der internen Parameterdatenbank (alternativ ein SQL-Skript für eine SQLite-Datenbank);
- eine C++-API zum Zugriff der Parameter aus der Firmware;
- eine Beschreibungsdatei für das proprietäre Kommunikationsprotokoll auf der Serviceschnittstelle;
- eine technische Dokumentation der Parameterschnittstelle;
- eine Device-Description für jeden unterstützten Feldbus;
- eine Beschreibungsdatei zur Client-seitigen Erzeugung des webbasiertes Userinterface;
- Sprachdateien für die Lokalisierung des UI und
- Datenstrukturen für die Integrationstests.
Der Aufbau eines elaborierten Buildsystems in Cmake – in Anlehnung an das Meta-Tool „West“ des Zephyr-Projekts – war der Schlüssel, um die notwendige Flexibilität beim Compile-Prozess herzustellen und möglichst kleine Firmwarebinaries zu erhalten. Dabei wurde der Buildcode mit den gleichen Qualitätsansprüchen entwickelt, wie die Firmwarekomponenten. Dadurch blieb er auch bei hoher essentieller Komplexität wartbar und der Build für die Gerätevariantenentwickler zugänglich.
Mit der beschriebenen Produktplattform ist es heute möglich ein neues Gerät innerhalb weniger Tage hochzuziehen, per Web-UI zu konfigurieren und an mehreren Feldbussen zu betreiben. Dies ist ein erster Erfolg, zumal er in relativ kurzer Zeit mit überschaubaren Entwicklerteam erreicht wurde. Die parallele Entwicklung einer Produkttestplattform wird sicherlich weitere Produktivitätssteigerungen bringen.