Um für Embedded-Systems-Module, die über spezielle Steckverbinder in eine Kundenschaltung integriert werden, eine erfüllbare Verfügbarkeitsgarantie zu schaffen, müssen bei der Produktspezifikation und der anschließenden Entwicklung zahlreiche Details sehr genau beachtet werden. Im Idealfall sind dann Produktlebenszyklen von zehn Jahren und mehr möglich, obwohl einzelne integrierte Schaltkreise meist gerade einmal maximal drei bis fünf Jahre zu bekommen sind. Um es gleich vorweg zu sagen: ohne mehrfache Entwicklungszyklen (Redesigns) ist es nicht möglich, beispielsweise ein 32-Bit-Embedded-Systems-Modul mit einer derartigen Garantie auszustatten. Das Bevorraten der entsprechenden Bauelemente kommt hier nicht in Frage. Zum einen lässt sich der Bedarf über einen so langen Zeitraum nicht planen, zum anderen können SMD-Schaltkreise nach wenigen Jahren schon nicht mehr sicher verarbeitet werden.
Entwicklungskriterien
Bei der Entwicklung der Esom-200-Familie von SSV wurde von Anfang an auf eine Zehn-Jahres-Verfügbarkeitsgarantie geachtet. Innerhalb dieses Zeitraums ist – neben der Produktverfügbarkeit – für den Kunden sicher, dass sie ohne Änderungen an Trägerboard und der selbst entwickelten Software die Embedded-Systems-Module einsetzen können. Um die Verfügbarkeit über diesen Zeitraum zu garantieren, sind das Pinout, die Blockschaltung, die Softwareschnittstellen sowie die elektrischen und thermischen Eckdaten von besonderer Bedeutung.
Das Pinout eines Embedded-Systems-Moduls darf sich während seines Produktlebenszyklus‘ nicht im Geringsten ändern. Ebenso muss das Zeitverhalten der Signale, die jeweilige I/O-Spannung (siehe auch elektrische Eckdaten) und die elektrische Charakteristik (etwa 0/1-Schaltschwellen, Treiberleistung von Ausgangsstufen, Ein- und Ausgangsströme) konstant bleiben. Diese Details erscheinen auf den ersten Blick recht nebensächlich, können bei der Langzeitverfügbarkeit aber zu erheblichen Problemen führen: Schon die geänderte Schaltschwelle im Schmitt-Trigger-Eingang eines Schaltkreises zur Überwachung der Versorgungsspannung kann bei Einsatz eines vermeintlich kompatiblen Nachfolge-IC in der Praxis zu Problemen führen. Ein weiterer Punkt sind die Funktionen einzelner Pins oder Pingruppen, die an spezielle Chips gekoppelt sind. So kann zum Beispiel eine PCI-Busschnittstelle nach einigen Jahren zum Problem werden, wenn der Schaltkreis, mit dessen Hilfe diese Pingruppe realisiert wurde, vom Markt verschwindet. Fazit hier: Beim Pinout sind durch die Produktlebensdauer von zehn und mehr Jahren zumindest hinsichtlich Zeitverhalten und elektrischer Charakteristik in der Regel Kompromisse unvermeidlich. Die meisten dadurch verursachten Probleme lassen sich aber durch einen guten Herstellersupport lösen.
Blockschaltung
Die Blockschaltung mit CPU/MCU/SoC, Speicher, I/O und anderen Komponenten ist auf den ersten Blick unkritisch. Sie lässt sich ohne nennenswerten Aufwand über einen sehr langen Zeitraum ohne Änderungen aufrechterhalten. Schließlich beschreibt ein derartiges Diagramm keine Realisierungsdetails, sondern nur die Funktionseinheiten und Steckverbinder. Bild 2 zeigt als Beispiel im linken Teil das Blockdiagramm eines x86-basierten Esom-200-Moduls und rechts die Schaltung eines ARM Cortex-A8-basierten Moduls. Bis auf den Steckverbinder wurde bei der Schaltungsentwicklung mit Hilfe entsprechender Werkzeuge sichergestellt, dass jede einzelne Funktionseinheit (LAN, SoC, Flash, DRAM) ausgetauscht werden kann, ohne dass sich dadurch Auswirkungen auf die Hardware- und Software des Anwenders ergeben.
Bei den Softwareschnittstellen ist zu unterscheiden, ob der 32-Bit-SBC mit oder ohne Betriebssystem an die Anwender geliefert wird. Ohne ein vorinstalliertes Embedded-Betriebssystem werden die Softwareschnittstellen durch die Speicher- und I/O-Adressen des SBC (Memory Map, I/O-Map) spezifiziert. Da ein solcher Adressraum über die verwendeten Chips bestimmt wird, kann bei der Lieferung ohne vorinstalliertes Betriebssystem auch keine Garantie für einen Zeitraum abgegeben werden, der länger als die typische Verfügbarkeit der eingesetzten Chips ist (vor allem CPU, MCU, SoC, Flash, I/O-Bausteine).
Ändert sich nur ein einziger I/O-Chip, ergibt sich sonst bereits ein abweichender I/O-Map und der Anwender müsste die eigene Software entsprechend anpassen. Bei den Esom-200-Modulen wurde daher von Anfang an ein Open-Source-Betriebssystem als vorinstallierte Software gewählt. Es dient als Softwareschnittstelle zu den vom Anwender entwickelten Anwendungen. Das Betriebssystem ist wiederum über spezielle Treiberprogramme mit den einzelnen Hardwarekomponenten verbunden (Bild 3). Ein Betriebssystem selbst ist natürlich auch wieder eine Komponente, die hinsichtlich der Produktlebensdauer nicht unproblematisch ist. Es muss unbedingt im Quellcode vorliegen. Weiterhin müssen die Lizenzbedingungen beliebige Änderungen zulassen. Ansonsten ist es für eine Hardware mit Langzeitverfügbarkeitsgarantie ungeeignet.
Weitere wichtige Parameter sind Versorgungsspannung, Verlustleistung und die Umgebungstemperatur. Spannungen, Ströme und thermische Parameter lassen sich mit entsprechender Erfahrung recht sicher für einen Zehn-Jahres-Zeitraum prognostizieren. Das immer noch gültige Mooresche Gesetz kann dabei helfen. Bei der Auswahl der I/O-Signalspannung sollte möglichst die Kompatibilität zur nächst höheren I/O-Spannung gewährleistet sein.
Wichtig: Die Feinabstimmung
Verfügbarkeitsgarantien für Zeiträume von zehn Jahren sind in der Praxis nur möglich, wenn Hardware und Software aus einer Hand kommen und genau aufeinander abgestimmt werden. Bei voneinander unabhängigen Hard- und Softwarepartnern wird die jeweilige Roadmap bereits innerhalb weniger Jahre nicht mehr konvergieren.
Weiterhin muss das Embedded-Modul mit einem vorinstallierten Betriebssystem geliefert werden. Als Eckpunkte für die Garantien sind – neben der Architektur, dem Formfaktor und dem Pinout – die Softwareschnittstellen des Betriebssystems entscheidend. Hier kommt eigentlich nur ein Open-Source-Betriebssystem wie Linux in Frage. Da die Quellcodes vorliegen, kann auch ein zehn Jahre alter Linux-Kernel auf eine neu entwickelte Hardware portiert werden. Für den Anwender ergibt sich dann eine hundertprozentige Softwarekompatiblität. Er kann die gleichen binären Dateien (Linux Executables) auf Vorgänger und Nachfolger ausführen. Softwarewartungsaufgaben erfolgen mit den absolut gleichen Werkzeugen wie zu Beginn.
Klaus-Dieter Walter
(uns)
