Low Code in Embedded-Systemen – geht das?

Low-Code-Plattformen liegen in der IT im Trend, versprechen sie doch schnelle und einfache Entwicklung von Anwendungen mit Hilfe grafischer statt rein textlicher Elemente. Kann ein solcher Ansatz für die Embedded-Entwicklung ebenfalls ein denkbarer Weg sein?

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Mixed Mode GmbH

Low Code-Plattformen werden seit einiger Zeit stark nachgefragt, berücksichtigt man entsprechende Messeauftritte und -beiträge. Überwiegend im Bereich mobiler Apps und Webservices versprechen sie schnelle und einfache Entwicklungen über IDEs, bei denen der Programmcode nicht textuell formuliert, sondern über graphische Elemente zusammengestellt wird. Kann dies für die Entwicklung von Embedded-Systemen (ES) ein ebenfalls denkbarer Weg sein? Der folgende Beitrag stellt einige Aspekte von ES-Entwicklung über graphische Tools bzw. IDEs zusammen. Es ist ein Kompilat von Erfahrungen in diversen ES-Projekten über längere Zeit, um den Teams Orientierung zu bieten, die erwägen, ihre ES-Entwicklung auf Low Code umzustellen.

Definition: Was versteht man unter „Low Code“?

Der Begriff „Low Code“ (LC) bedeutet zunächst schlicht „wenig Code“. Dahinter steckt das stetige Bestreben in der Codeentwicklung, ein Softwareprodukt schnell, also möglichst gering in Aufwand und Komplexität zu schaffen und weiterzuentwickeln. Ein aktuell recht verbreiteter Ansatz nutzt die Tatsache, dass wir uns nach wie vor gerne bildhaft orientieren: Entitäten, Prozessschritte und dergleichen werden als graphische Elemente und ihre Relationen und Interaktionen über Linien und Pfeile dargestellt. Das auf diese Weise geschaffene Diagramm bildet Prozessabläufe so ab, dass sie auf ein bis drei Blicke überschaubar sind, während die Übersetzung in maschinenlesbaren Code im Hintergrund erfolgt.

Die Vorteile eines solchen Ansatzes liegen auf der Hand: Der Entwickler konzentriert sich auf die Erstellung einer sachgerechten Geschäftslogik und benötigt offenbar kaum/keine Kenntnisse in Programmiersprachen mehr, Änderungen können mit wenigen Cursorzügen vollzogen werden. In den zahlreichen Fachbeiträgen zu LC ist der Begriff daher aktuell häufig mit „graphisch“ konnotiert, obwohl er strenggenommen nicht darauf beschränkt ist.

In einem der am häufigsten zitierten Beiträge zu „Low Code“, der den Begriff 2014 zumindest wohl in der Breite bekannt gemacht hat, wird der Ansatz diskutiert und ihm bis 2020 über 15 Mrd $ Ertrag prognostiziert. Im hier verlinkten Whitepaper werden aktuelle Low Code-Plattformen vorgestellt, wobei hier nicht nur die Eignung für mobile Anwendungen oder Citizen Developers betrachtet wird, sondern z.B. auch Real Time-Anwendungen im IoT, z.B. Sensordatenverarbeitung.

Spätestens hier stellt sich die Frage, ob Low Code in diesem Sinn auch für andere IT-Geschäftsfelder interessant sein könnte, in erster Linie für Embedded-Systeme (ES). Tatsächlich ist, wie die Recherche des Autors erbrachte, die Konnotation „Graphische IDE - Low Code“ im ES-Umfeld so gut wie unbekannt, nicht aber zahlreiche frühere Ansätze, die häufig aufwendige ES-Entwicklung auch über graphische Tools zu vereinfachen. LC ist so gesehen also nichts Neues, wenngleich der aktuell wesentlich neue Aspekt in der Bereitstellung von ganzen LC-Plattformen liegt, die über frühere graphische und nichtgraphische LC-Tools weit hinausgehen.

Zur Annäherung an eine Antwort hat der Autor ein gutes Dutzend ES-Entwickler aus den unterschiedlichsten Bereichen nach ihren Erfahrungen mit graphischen und nichtgraphischen LC-Ansätzen befragt, die teilweise bis in die 90er Jahre (Stichwort damals: Easy Programming) zurückreichen. Natürlich hat sich seit damals Vieles grundstürzend verändert. Dennoch: Anders als bei anderen Themen, wo man nach der Befragung von n Entwicklern schon mal mit n + 2 Ansichten dasteht, konvergierten die Antworten ausnahmslos auf vier fachlich-harte Thesen und eine gewissermaßen atmosphärische. Von diesem relativ gesicherten Fundament ausgehend können einige Überlegungen formuliert werden, wenn ES-Teams ihre Entwicklung auf LC-Plattformen umstellen wollen (oder sollen). Direkte Empfehlungen sollen aber nicht ausgesprochen werden, ebensowenig wie Tool-Empfehlungen. Dazu ist die ES-Entwicklungslandschaft zu vielfältig; die Entscheidung Für oder Wider kann jedes Team nur für sich selbst treffen. Aus verständlichen Gründen werden nachfolgend auch keine Tools explizit genannt, mit denen eher ungünstige Erfahrungen gemacht wurden; das Erfahrungskondensat kann daher nur einen Übersichtscharakter haben.

These 1: Ja – wenn es um Standardaufgaben geht

Für die Entwicklung von Standardfunktionalität elektronischer Standard-Hardware (HW) gibt es bereits LC-Tools: Die Bausteine werden durchgemessen und Code mit korrekter Konfiguration schnell bereitgestellt, z.B. bei FPGAs die funktionale Parametrisierung von Modulen. Das entlastet von Routineaufgaben und es bleibt mehr Zeit für Spezialfälle.

Aber auch dort, wo eine bestimmte Implementierung gefordert ist, kann dieser Ansatz nützlich sein. Im AUTOSAR-Umfeld beispielsweise werden z.T. zertifizierte Tools eingesetzt, um bestimmte Treiber schnell und quasi incl. Zertifikat zu erstellen.

Unabhängig davon, ob ein graphisch orientiertes Werkzeug vorliegt („Werkzeug“ = einfache Tools und umfassende Plattformen), kann man sich demnach über LC eine Grundkonfiguration erstellen lassen für Hardware-Abstraktionen, Standardinterfaces bzw. REST-Schnittstellen, um z.B. Protokolle zu implementieren. Das spart definitiv Zeit und Kosten.

These 2: Nicht am ES-KnowHow sparen

Kehrseite der Standardisierung: Sobald der Standardfall verlassen wird, was in der Praxis schnell mal der Fall ist, verliert man den Vorteil der Vereinfachung. Mehrere hart ineinander hängende Interrupts z.B. für Echtzeitanforderungen kommen ebenso vor wie spezielle Hardwarekonfigurationen, die nicht oder nicht vollständig in den HW-Abstrahierungen abgebildet sind, auf denen Low Code letztlich basieren muss. Die HW-Landschaft ist schlicht zu breit, als dass sie - zumindest aktuell - vollständig von einem einzigen Werkzeug abgebildet werden könnte. Daraus folgt, dass ein Entwickler mit nur wenig ES-Wissen schnell stranden kann. Dies betrifft die bisher erwähnte Kategorie von LC-Werkzeugen für HW-Abstraktion bzw. Treiberentwicklung ebenfalls wie für die zweite, potentiell interessante: die Modellierungswerkzeuge, mit denen graphisch Systemarchitekturen entworfen, implementiert und bearbeitet werden können. Hier gibt es teilweise die Möglichkeit, an bestimmten Stellen eigenen Code einzufügen, der aber u.U. beim nächsten Codegenerieren überschrieben wird. Wenn aber auch nur wenige Prozent des Codes nicht mit LC erstellt werden können, bedeutet dies bei nicht vorhandener Rückführbarkeit von händisch erstelltem Code in die graphische Darstellung schnell das Aus für den LC-Ansatz. Das Paretoprinzip lässt hier grüßen, auch wenn manche Werkzeuge die Möglichkeit bieten, Code als „unantastbar“ zu markieren.

These 3: Übersichtlichkeit und Debugging können leiden

Auch bei der optischen Überschaubarkeit komplizierter Zusammenhänge sind uns Grenzen gesetzt, und zwar offenbar ziemlich schnell. Die Erfahrung zeigt, dass anfänglich noch gut bearbeitbare graphische Abbildungen von Programmlogik und Prozessen im Laufe der Zeit durch Weiterentwicklung unübersichtlich werden können, vor allem über Schnittstellen und Modulgrenzen hinweg. Beim Ausführen solchen Codes kann das Debuggen des eigentlichen Codes (besonders bei den unangenehmen Fehlern, die erst zur Laufzeit und dann auch noch sporadisch auftreten) ziemliche Schwierigkeiten bereiten, da sich der Entwickler in den Code erst einarbeiten muss - vorausgesetzt, er verfügt überhaupt über das entsprechende Wissen. Dem versuchen Werkzeuge aber entgegenzuwirken, indem sie z.B. Debugging in graphischer Repräsentation bieten, was belegt, dass LC-Werkzeuge natürlich ständig weiterentwickelt werden. Nur die individuelle, projektbezogene Evaluation kann entscheiden, ob das jeweilige Werzeug mit seinen Funktionen auf Dauer für ein Vorhaben geeignet ist.

Ein Beispiel: Im Umfeld der FPGA-ASIC-Entwicklung gab es den Designschritt Schematic Entry, bei dem die Schaltungen graphisch in einem Plan zusammengefügt wurden. Dieses Vorgehen war aber wegen der schnell entstehenden unübersichtlichen Darstellungen fast verpönt; auch weil die funktionale Ebene verlassen wurde. In neuerer Zeit scheint aber eine Renaissance dieses Ansatzes zu beobachten zu sein, allerdings nicht mehr auf Gatterebene, sondern auf der Ebene komplexer funktionaler Blöcke.

These 4: Zusammenarbeit kann schwierig werden

Agile Entwicklung über Teamgrenzen hinweg ist heute ebenso Standard wie Arbeiten im Home Office. Beides setzt die Möglichkeit moderner Versionskontrolle und Mergen voraus. Bei proprietären Container- bzw. Binärformaten kann der Austauschbarkeit – und damit dem Reviewprozess – von gemeinsam erstellten Files schnell ein Ende gesetzt sein. Darauf beruht in modernen Entwicklungsteams die Hauptschwierigkeit für den Arbeitsprozess durch LC.

These 5: Angemessenheit und Akzeptanz berücksichtigen

Ohne pauschalisieren zu wollen: Die Abneigung hartgesottener Embedded-Entwickler gegen „Klickibunti“ ist legendär (eine Definition des Begriffs findet sich auf Wikipedia); bei den Befragungen zum LC-Graphikthema spielte sie eine erstaunlich hartnäckige Rolle. Entscheidungsträger, die mit der Einführung von toolgestütztem LC gedanklich spielen, sollten daran zumindest einmal gedacht haben. Auch die Frage, ob manche Tools für einen bestimmten Einsatzbereich nicht zu „mächtig“ oder in anderer Weise unangemessen sind, sprich: ob das erzielte Ergebnis nicht letztlich doch mit handprogrammiertem Code schneller zu erzielen ist, sollte in Erwägung gezogen werden.

Für die letzten beiden Aspekte lassen sich die Erfahrungen mit der Model Driven Architecture (MDA) anführen. Der Anfang der 2000er Jahre populäre Ansatz suchte durch strikte Trennung von Funktionalität und der sie umsetzenden Technologie eine Reihe von Vorteilen zu erreichen, u.a. automatische Codegenerierung sowie eine Beschleunigung der Produktentwicklung. Damit ging ein sehr hoher Grad an Abstraktion und Formalisierung einher, damit die Codegenerierung überhaupt möglich war. Dies konnte dazu führen, dass der Erstellungsaufwand für solche MDA-Modelle den einer händischen Codeerstellung so weit überstieg, dass die Akzeptanz dafür schlicht wegbrach.

Bei den Tools, bei denen nicht alles modelliert werden musste, konnten an speziellen Feldern Codeschnipsel eingegeben werden, die in den übrigen generierten Code eingefügt wurden. So etwas kann aber schnell unübersichtlich werden, noch dazu ohne Garantie, dass bei der nächsten Codegenerierung noch alles an Ort und Stelle ist. Beim Debuggen kommt hinzu, dass maschinengenerierter Code für humanoide Gehirne nicht immer einfach nachvollziehbar ist; er ist ja eigentlich dafür auch nicht gedacht - für erfahrene Entwickler nicht, und erst recht nicht für einen "preiswerten" LC-Entwickler (wenn es so jemanden überhaupt gibt), der die Kenntnisse dafür gar nicht mitbringt.

Schließlich kann die Codegenerierung auch langwierig sein, was das Problem der Verfügbarkeit von Features bei großen Projekten zur rechten Zeit mit sich bringt. Dadurch erhöhen sich Abhängigkeiten zwischen Teams, was die Kollaboration gerade in Zeiten von Zwei-Wochen-Sprints erfahrungsgemäß erschwert.

Insgesamt war zu beobachten, dass der MDA-Ansatz nach anfänglicher Begeisterung bei so mancher Firma wegen der genannten Nachteile letztlich doch nicht mehr angewendet wurde; ganz aus der Mode gekommen ist er allerdings bis heute nicht: Werkzeuge und Methoden zur Modellgetriebenen Softwareentwicklung machen aktuell große Fortschritte. Der Wind könnte sich also in einigen Jahren durchaus drehen.

Low-Code-Plattformen ersetzen kein Embedded-Wissen

Obigen Thesen, auf die alle Aussagen der Befragten einhellig zuliefen, lässt sich entnehmen, dass insbesondere domänenspezifische Standardaufgaben mit graphischen LC-Werkzeugen gut umsetzbar sein können. Die Werkzeuge können grob in zwei Kategorien unterschieden werden:

• Werkzeuge für HW-Abstraktionen und Treibererstellung für Implementierungen von z.B. Protokollen, Interfaces oder HW-konfigurationen: und

• vollständige Modellierwerkzeuge, mit denen eine umfassende Systemarchitektur initial erstellt wird zur Weiterbearbeitung von Hand.

Was aber im Einzelfall eine Standardaufgabe ist, hängt vom Funktionsumfang des anvisierten LC-Werkzeugs (also entweder einfaches LC-Tool oder umfassende LC-Plattform) ab; das können nur die betreffenden Teams entscheiden.

Sehr klar ist aber auch, dass die Grenzen solcher Werkzeuge überraschend eng sein und Umstände wie fehlende Funktionalität oder Abstrahierbarkeit von HW den ganzen LC-Ansatz schnell zum Scheitern bringen können - oder zumindest den Aufwand, ihn dennoch durchzuziehen, sehr hochtreibt. Deswegen darf keinesfalls am Wissen der Entwickler gespart werden. Schließlich sind weiche Faktoren wie der zu erwartende Umfang eines Projekts, Zusammenarbeit über Versionsverwaltungstools und letztlich auch die Akzeptanz des graphischen Ansatzes an sich unbedingt zu berücksichtigen. Die Zukunft wird zeigen, ob LC-Plattformen sich der ES-spezifischen Bedürfnisse mehr und mehr annehmen werden; auch dieser Markt ist in ständiger Entwicklung.

* Dr. Richard Kölbl ist Senior Software-Entwickler bei Mixed Mode in Gräfelfing.

(ID:46294131)