Elektronische MVPs: nah an der Serie

Es nicht aus, nur die Funktionsfähigkeit von MVPs in den Vorderung zu stellen.  Diese ist zwar nicht selten essentieller Teil der Gleichung. Im Bereich von hochregulierten Systemen wie der Bahn-, Automobil- oder Verteidigungsindustrie müssen Embedded Systems insbesondere den hintergründig wirkenden Anforderungen nach Safety, Security und Longevity standhalten.

Ja, einer der ersten Schritte auf der Innovation Journey ist die Validierung der Idee. Die Frage nach dem Kontext ist in regulierten Domänen aber immer die, die gleich folgt. Das mag zunächst unbedeutend erscheinen, aber genau dieses "kopfüber in die Entwicklung stürzen" ist einer der Kardinalsfehler in der MVP-Gestaltung von bspw. sicheren Spannungsversorgungen, Signaltechnik für die Bahn, Industrie-4.0-Hardware oder Kfz-Steuergeräten.

Die gängigsten Ansätze zum Testen der Annahmen, die einer Idee zugrunde liegen, sind die Erstellung eines Proof of Concept, eines Prototyps und eines Minimal Viable Product (MVP). Proof of Concept und Prototyp sind im Embedded-Systems-Kontext stets höchst fragil, weil sie massiver Überarbeitung auf dem Weg zum serientauglichen Produkt benötigen. PoCs sollten daher in der Regel nur als digitale Zwillinge, Prototypen auf Entwicklungshardware entwickelt werden.

Ein echter Champion MVPs für den regulativen Kontext ist damit ein MVP, der gleichzeitig das Potenzial hat, normative Anforderungen zu erfüllen.

Es geht also immer mit darum, gleich mit der ersten industriell bestellten Hardware das Potenzial zu schaffen Anforderungen für den hoch regulativen Kontext zu erfüllen. Entscheider wissen: im Functional Safety- und Security-Kontext gilt eine unausgesprochene Dreierregel. Ein Drittel Software, ein Drittel V&V und ein Drittel Dokumentation. Haben wir hier die Hardware vergessen? Nein, denn der Aufwand für Altium und Co. verblasst im Angesicht des schieren Workloads der anderen Pakete. Somit ist ein Champion MVP immer eine serienfähige Hardware mit (noch) nicht serienfähiger Software.

Um solch ein Champion MVP zu entwickeln, sind eine Reihe von Aktivitäten vonnöten.

• Festlegen von Requirements des Top-Level Systems
• Festlegen von Requirements aus dem (externen) Kontext
• Umsetzen von Best Practices

Alle drei Tätigkeiten münden in einer Anforderungsspezifikation rund um das Champion MVP, die als Hardware und Software-Prototyp umzusetzen ist.

Anforderungen für einen Champion MVP

Festlegen von Requirements des Top-Level-Systems

Requirements von Systemen aus übergeordneten oder peripheren Systemen sind häufig relativ einfach zu ermitteln, da es sich hier um Anforderungen handelt, die für gewöhnlich bekannte Systeme beschreiben. So werden bei der Entwicklung von Embedded Systems zumeist Gesamtsysteme um Teilsysteme erweitert. Ein Beispiel ist das Hinzufügen eines Datenloggers für ein industrielle Steuerungssystem. Dabei wird sehr wahrscheinlich die Art der industriellen Schnittstellen bekannt sein. Somit kann für das zu entwickeln System abgeleitet werden, dass - um weiter im Beispiel zu bleiben - ein 24V-Eingang und eine ProfiNet Schnittstelle zur Kommunikation verwendet werden. Requirements von Top-Level-Systemen sind meist recht technischer Natur und oft sehr konkret.

Festlegen von Requirements aus dem externen Kontext

Requirements aus dem externen Kontext sind im Wesentlichen Anforderungen aus dem Umfeld, die sich auf die Produktzulassung auswirken. Typische Anforderungen sind Safety- und Security-Anforderungen. Ein Champion MVP zu entwickeln bedeutet, ein Element als "safe" oder "secure" zu entwickeln, ohne den Kontext der tatsächlichen Sicherheitsziele oder des Systems zu kennen, d.h. ohne zu wissen, was die Sicherheitsziele sind oder wie das System sein wird. Das Annehmen und Schätzen von Sicherheitsanforderungen ist ein komplexer Vorgang, daher sind hier keine klare Vorgaben zu erwarten. Es lässt sich aber ein grundlegendes Sicherheitslevel zumeist schätzen oder von ähnlichen Systemen ableiten. An dieser Stelle sind Interviews und Assessments mit Experten aus dem Bereich RAMS (Reliability, Availability, Maintainability, Safety) und dem Bereich Security (Common Criteria, BSI-Standards, IEC 61433).

Best-Practices

Best Practices sind für die normativen Domänen wie Automobilindustrie, Bahntechnik, Militär oder Industrie 4.0 allgemein bekannte Verfahren, um sichere und langlebige Hardware zu konzipieren. Hier lassen sich abhängig von dem Anwendungsfall und dem zu erwartenden Level für Safety oder Security architektonische Konzepte für Hardwarebausteine ableiten. Hier besteht potentielle Gefahr von Over-Engineering, deshalb sind grundsätzlich Kosten-Nutzen-Abwägungen zu treffen. Ein paar potentielle Praktiken wie folgt:

• Verwenden von Safety-SBCs und PMICs
• Einsetzen externer Watchdogs 
• Clock-Monitoring
• Verwenden von Clock-Generatoren im Safety-Kontext
• Overvoltage- und Undervoltage-Detection
• FIT-Kalkulation über Component Failure Rate Data  (MILHDBK 217F, SN29500, IEC/TR 62380, Herstellerdaten)
• Verwenden von Prozessoren mit Lockstep-Funktionalität
• Verwenden von Speicherbausteinen mit ECC-Verfahren
• Verwenden von industriellen protokollen mit Parity oder CRC
• Umsetzen IO-Loopback-Verfahren
• VerUNDung oder VerODERung von Schalt-Ausgängen
• Verwendung von Hardware mit entsprechender Qualifikation
• Verwendung von Trusted Module Hardware

Entwicklungspfad

Auch heute beherrscht der Irrglaube, dass man in Vorentwicklungsphasen keine Anforderungen braucht, die Entwicklungsabteilungen. Gerade im hoch normativen Kontext ist dies mitunter besonders fahrlässig, da wesentliche Anforderungen bezüglich der Sicherheitsarchitektur nur mit sehr viel Aufwand in späteren Phasen verändert werden können. Ein Champion MVP kommt daher ohne Anforderungen nicht aus. Aus den drei Bereichen Top-Level Requirements, external assumed Requirements und Best Practices sind Anforderungen für Hardware, Software und den Bereich Prozess/Zertifizierung zu entwickeln. Mit Abschluss der Anforderungen aus dem Bereich Hardware kann in jenem Kontext mit der Vernetzung und Entflechtung begonnen werden. Bei der Software-Entwicklung sollte der Hauptfokus auf den Features liegen, die zu einem definierten Abschluss gezeigt und demonstriert werden sollen. Mit Abschluss der Feature-Entwicklung können die Sicherheitsziele mit Blick auf die Endkunden-Anwendung mitunter gefestigt oder finalisiert werden. Dann können architektonische oder Runtime-bezogene Sicherheitsfunktionen implementiert und validiert werden. Der dritte Entwicklungspfad, der für den Bereich Prozess und Zertifizierung, definiert im Rahmen des Entwicklungsprojekts die Notwendigkeiten hinsichtlich Dokumentation und Prozess, also allgemein die Zertifizierbarkeit des Entwicklungsprojekts

Entwicklungspfad für Champion MVPs

Zusammenfassung und Ausblick

Der Unterschied zwischen einem einfachen Muster und einem Champion MVP besteht einerseits in der Integration geschätzter Sicherheits- und Schnittstellenanforderungen in die Prototypenphase, andererseits hinsichtlich der besonderen Nähe der Hardware zum Endprodukt. Mit Champion MVPs im normativen Kontext lassen sich früh Produkte im Kontext von Demonstratoren und Applikations-Beispielen einem breiten Publikum zeigen. Somit lassen sich mit einem Champion MVP sehr seriennahe Entwicklungen schon früh auf den Prüfstand hinsichtlich der Anwendbarkeit oder Integration beim Endkunden stellen.