Codegenerierung auf dem Prüfstand: Was sind die häufigsten Tücken?

Ein Codegenerator erzeugt den Quellcode einer Programmiersprache aus einer abstrakten Beschreibungssprache (z.B. einem Modell). Die IMT setzt die automatische Codegenerierung bereits seit vielen Jahren ein. Da die IMT zunehmend in der Entwicklung von Medizintechnik tätig ist, müssen viele der Projekte hohe sicherheitskritische Anforderungen erfüllen. Der Prozess zur Erstellung hochintegrierter Systeme mit automatischer Codegenerierung wurde im Laufe der Jahre optimiert und zum Abschluss gebracht. Dennoch sind auch bei der Codegenerierung und Modellierung Fehler nicht ausgeschlossen. Deshalb haben wir für Sie die 10 grössten Fallstricke zusammengefasst, die Sie unbedingt beachten sollten.

Wenn die Beschreibungssprache (oder Modellierungssprache) universell gehalten wird, kann sie dazu verleiten, jedes erdenkliche Problem damit lösen zu wollen. Beispielsweise ist es nicht empfehlenswert, eine zustandsorientierte Logik mit einem flowbasierten Ansatz zu implementieren oder umgekehrt. Daher ist es wichtig, dass die Möglichkeiten und Stärken der Beschreibungssprache für die Softwarearchitektur berücksichtigt werden und die Codegenerierung nur dort eingesetzt wird, wo es wirklich sinnvoll ist.

2. Architektur

Gerade bei grossen generierten Applikationen ist es zwingend notwendig, eine geeignete und gut strukturierte Modellarchitektur zu haben, die für zukünftige Änderungen ausgelegt ist. Dies ist keine leichte Aufgabe und wird oft unterschätzt, denn eine umfassende Modellarchitektur mit Tausenden von Elementen erfordert viele Jahre Erfahrung. Das ist die Herausforderung: Ausgebildete Softwarearchitekten müssen mit der Modellierungssprache vertraut sein, oder die Modellierungsexperten sollten die Kunst des Entwurfs einer Softwarearchitektur erlernen.

3. Missachtung der Grundsätze der Softwaretechnik

Es ist zweifelhaft, dass die Modellierung einschliesslich der Software-Code-Generierung keine Kenntnisse im Software-Engineering erfordert. Die Erstellung von Modellen erfordert die Kenntnis und Anwendung bestimmter Grundprinzipien. Prinzipien wie Strenge, Strukturierung, Abstraktion, Lokalität/Privatheit und die Annahme der Notwendigkeit von Änderungen. Die gute Nachricht ist jedoch, dass diese Fähigkeiten erlernt werden können. Aber Vorsicht, eine zu grosse Verliebtheit in das Software-Engineering kann zu einem weiteren Fallstrick führen: exzessives Scripting.

4. Exzessives Skripting

Einige Modellierungssprachen erlauben die Verwendung von Skripten. Simulink ermöglicht beispielsweise die Integration von m-script oder, im Rahmen von Stateflow®, die Verwendung von C-Syntax. Je nach persönlichen Vorlieben kann dies zu einem exzessiven Gebrauch der Skriptsprache führen, auch wenn eine Beschreibung in der Modellierungssprache sinnvoll wäre. Das Problem dabei ist, dass Sie einige Vorteile der Codegenerierung verlieren: Lesbarkeit, Wartbarkeit und inhärente Sicherheit, die durch die Syntax der Modellierungssprache gegeben ist.

5. Too big will fail

Aufgrund der grafischen Darstellung einiger Modellierungssprachen sind hierarchisch tiefe Strukturen und Abhängigkeiten leicht zu handhaben. Daher ist die Belastung durch zyklomatische Komplexität im Vergleich zu handgeschriebenem Code, der zu grossen und komplexen Modellen führen kann, viel geringer. Zu komplexe Modelle haben jedoch Nachteile in Bezug auf Testbarkeit, Wiederverwendbarkeit und Rückverfolgbarkeit. Darüber hinaus führen solche Modelle auch zu einer längeren Simulations-, Codegenerierungs- und Kompilierungszeit des generierten Codes. Unter diesem Gesichtspunkt ist das Denken in „funktionalen Einheiten“ für die Modellierung von entscheidender Bedeutung (so wie es auch für handgeschriebenen Code wichtig ist).

6. Schnittstelle zum handgeschriebenen Code

Im besten Fall werden Änderungen innerhalb des Modells und nicht im generierten Code vorgenommen. Wenn der Codegenerator die Rückführung von Änderungen nicht unterstützt, ist das nicht der beste Fall, sondern ein Muss. Sie müssen sicherstellen, dass die Schnittstellen zwischen dem generierten und dem handgeschriebenen Code klar definiert sind, um den generierten Code als separate Einheit oder Abschnitt zu behandeln. Einige der Codegeneratoren enthalten Kommentare wie /*Dieser Abschnitt darf nicht geändert werden*/ im generierten Code. Bitte beachten Sie diese.

7. Fehlende Richtlinien

Es scheint naheliegend, Richtlinien für handschriftlichen Code zu haben. Jedoch, für einige Personen, die zu einem Code-Generator wechseln, scheint dies wie eine gute Gelegenheit, auf diesen Unsinn zu verzichten. Aber fast jeder weiss, dass Richtlinien nicht da sind, um Ihnen das Leben schwerer zu machen. Meistens machen sie Sinn und helfen, Ihre Modelle lesbarer, wartbarer und in einigen Fällen auch zuverlässiger zu machen. Wenn Ihre Teamkollegen sich gegen Leitlinien sträuben: nennen Sie sie einfach beste Praktiken. Auf jeden Fall ist es am besten, Richtlinien in einem Team als gemeinsame Arbeit zu entwickeln. Und bitte übertreiben Sie es nicht, denn Richtlinien (insbesondere Modellierungsrichtlinien) sollten keine Gesetze sein, die bei Nichtbeachtung zu Konsequenzen führen können. Seien Sie also geduldig und nicht zu verfänglich.

8. Mnemische Vernachlässigung regulatorischer Anforderungen

Wenn die Codegenerierung in einem regulierten Umfeld eingesetzt wird, sollten Sie sicherstellen, dass die entsprechenden Anforderungen bereits in einem frühen Stadium und nicht erst nach der Implementierung berücksichtigt werden. Im Bereich der Medizinprodukte fordert die ISO13485, dass ein Codegenerator, der in den Entwicklungsprozess eingebunden ist, validiert werden muss. Besonders bei grossen und komplexen Codegeneratoren klingt das nach viel Arbeit. Wenn jedoch die Qualität des generierten Codes sichergestellt ist (z. B. durch Testen des generierten Codes), ist eine umfangreiche Validierung des Codegenerators nicht unbedingt erforderlich, da die ISO13485-Norm eine risikobasierte Bewertung ermöglicht.

Wenn der generierte Code in einem Medizinprodukt verwendet wird, unterliegt er ausserdem der IEC 62304. Eine erfolgreiche Strategie, um IEC 62304-konform zu sein, besteht darin, den generierten Code fast genauso zu behandeln wie handgeschriebenen Code. Einige der folgenden Massnahmen können jedoch überflüssig sein:

• Überprüfung des generierten Codes, da die Modelle bereits überprüft wurden (hoffentlich).
• Überprüfung gegen Kodierrichtlinien.
• Detaillierter Entwurf des generierten Codes, da dies bereits im Modell erfolgt ist.
• Je nach Code-Generator und dessen Einstellungen ist eine statische Code-Analyse möglicherweise nicht erforderlich. Wenn jedoch keine statische Codeanalyse durchgeführt wird, sollte der Codegenerator entsprechend validiert werden.

9. Datentypen

Es gibt Codegeneratoren, die den Benutzer nicht mit der Wahl expliziter Datentypen belästigen wollen. Was gut gemeint ist, entpuppt sich in der Praxis als unangenehme Automatismen, die zum Verlust der Kontrolle über den Code führen können. Daher ist es sinnvoll, dass, wenn die Datentypen im Modell explizit angegeben sind und es sich um unerwünschte, bzw. automatisch gewählte Datentypen handelt, diese im Modell bzw. im generierten Code überprüft werden. Dies vermeidet:

• Ineffizienter Code
• Unerwartetes Verhalten der Anwendung
• Compiler-Fehler

Allerdings ist eine gewisse Kenntnis der Datentypen erforderlich (siehe 3. Missachtung der Grundsätze der Softwaretechnik).

10. Vorurteile gegenüber Codegeneratoren

Wenn Codegeneratoren richtig eingesetzt werden, ist das eine wunderbare Sache. Es wäre also der grösste Fehler, aufgrund von Vorurteilen auf den Einsatz von Codegeneratoren zu verzichten. Wenn Sie auf den Einsatz von Codegeneratoren verzichten, entgehen Ihnen möglicherweise viele Vorteile:

• Schnellere Markteinführung, insbesondere bei Steuerungs- und Signalverarbeitungsanwendungen. Die Kombination von Simulation und Codegenerierung ermöglicht einen hocheffizienten Entwicklungsprozess, der als Model Based Design bezeichnet wird. Die Controller werden hauptsächlich auf der Basis von „Digital Twins“ de-signiert und verhindern so mehrfache Iterationen mit Hardware-Prototypen im Entwicklungsprozess.
• Die Wartung des Produkts ist effizienter, da die Modelle aufgrund ihrer grafischen Darstellung und Übersichtlichkeit leichter zu pflegen sind. Die Einarbeitung neuer Mitarbeiter beschränkt sich in der Regel auf wenige Tage.
• Es ist einfacher, gesetzliche Anforderungen zu erfüllen, da die Modelle als detaillierte Softwarearchitektur zu sehen sind und leicht validiert werden können. Beides, der Entwurf einer Architektur und die Verifikation der Architektur, werden von der IEC 62304 ausdrücklich gefordert.
• Erhöhte Unabhängigkeit von der Laufzeitumgebung, da die Schnittstelle zu peripheren Systemen durch den Codegenerator abstrahiert wird. Dies ermöglicht eine schnelle und problemlose Portierung auf verschiedene Rechnersysteme. So sind Sie für die Zukunft gerüstet und müssen keine Angst vor technologischen Veränderungen haben.

Codegeneratoren können Geräte schneller auf den Markt bringen, die Wartung vereinfachen, die Erfüllung gesetzlicher Anforderungen unterstützen und gelten als zukunftssicher. Dennoch gibt es beim Einsatz von Codegeneratoren einige Fallstricke. Eine Einführung muss sorgfältig geplant werden, und die Entwicklungsprozesse sollten möglicherweise verfeinert oder geändert werden.