Zahllose Mikroprozessoren arbeiten "unter der Haube" von Geräten, denen wir im Betrieb und im Alltag begegnen, die aber kaum jemand als Computer wahrnimmt. Die Rede ist von Embedded Systems, worunter hier alle Datenverarbeitung außerhalb der "klassischen" DV zu verstehen ist. Typische Anwendungen sind Steuerungen, Regeleinrichtungen, Meß- und Überwachungseinrichtungen oder die speicherprogrammierbaren Steuerungen (SPS), die alte Schützensteuerungen weitgehend verdrängt haben.

Generell lassen sich die zeitbezogenen Aufgaben dieser Systeme in drei Kategorien einteilen: Sie sortieren, beispielsweise Einträge in Fehlerprotokolle, sie berechnen, zum Beispiel Volumina aus Fluß und Zeitdifferenz, und sie prüfen, etwa Verfallsdaten oder Wartungstermine. Sehr häufig sind solche Systeme in größere, hierarchische Strukturen eingebettet.

Embedded Systems sind ubiquitär, man findet sie in Fertigungsstraßen, Prozeßanlagen, in der Haustechnik, in Bürogeräten etc. Durch ihre Verbreitung ist jedes Unternehmen, ist jeder einzelne abhängig von den meist in Black Boxes verborgenen Chips. Und auch wer nichts dergleichen in seiner Umgebung finden sollte, ist betroffen, beispielsweise eine Firma über die Lieferkette, indem irgendeiner ihrer Lieferanten Geräte mit Embedded Systems einsetzt.

Ein wesentliches Charakteristikum von Embedded Systems ist die schiere Zahl der eingesetzten Mikroprozessoren. Allein 1997 wurden weltweit rund zwölf Milliarden dieser Chips verkauft. Hält man sich die Schätzung vor Augen, daß zwischen fünf und zehn Prozent aller eingesetzten Mikroprozessoren in Embedded Systems Schwierigkeiten mit dem Jahr 2000 bekommen dürften, so läßt sich die immense Größe des drohenden Problems erkennen.

Von den wirtschaftlichen Gefahren für Unternehmen durch fehlerhafte Programme ist viel die Rede. Eine falsche Buchhaltung verursacht aber keine Bedrohung von Leib und Leben der Mitarbeiter. Anders liegen die Verhältnisse bei Embedded Systems.

Ein fehlerhaftes System, nehmen wir als Beispiel eine Werkzeugmaschine, kann durchaus zu gefährlichen Unfällen führen. Ergo ist auch hier die vollständige Erfassung und Überprüfung aller Anlagen ein Muß. Dies ist einer der Gründe, warum sich Versicherer so intensiv mit diesem Thema auseinandersetzen.

Die durch die Menge der Chips ohnehin schon schwierige Aufgabe "Jahr-2000-Projekt bei Embedded Systems" wird noch dadurch verschärft, daß hier - anders als in der "klassischen" DV - eine Vielzahl unterschiedlicher Prozessorarchitekturen anzutreffen ist. Außerdem bilden sie die Basis für die sogenannten Application Specific Integrated Circuits (Asics).

Die Hersteller solcher Asics bauen nach Kundenwunsch auf einem Chip um einen Prozessorkern herum weitere Baugruppen wie Echtzeituhren, Analog-Digital-Wandler etc., wodurch individualisierte Mikroprozessoren entstehen. Da man so - ein Chip statt mehrerer - viel Raum sparen kann, die Fertigungskosten durch die Verringerung der benötigten Bauteile auf den Leiterplatten sinken und Asics schon in 1000er Stückzahlen zu akzeptablen Preisen erhältlich sind, werden sie auch entsprechend häufig in Embedded Systems eingesetzt.

Während Prozessoren und andere Komponenten in DV-Anlagen einfach zu lokalisieren sind, ihre Software sich ohne große Probleme anpassen läßt, erschweren zwei Aspekte den Zugang zu Embedded Systems.

Zum einen entscheidet schon die Bauform darüber, ob eine Aktualisierung der Hardware durch Austausch von Komponenten wie Prozessor oder Echtzeituhr möglich ist. Dabei kann man generell drei Ausführungen unterscheiden: Baugruppensysteme wie VME-Bus (IEEE 1014 und IFC 821), Einzelgeräte (zum Beispiel SPS) und in den Geräten gekapselte "Chips" für Sensoren, Stellglieder, Motoren etc.

Eingriffe in solche Hardware sind außerdem häufig dadurch schwierig, daß nur wenige Bauelemente gesockelt sind, sich also nicht einfach herausziehen und neu einstecken lassen. Die zumeist gelöteten Bauelemente in SMD-Technologie (SMD = Surface Mounted Device) sind sehr kompakt und vor Ort nur schwer austauschbar.

Zum anderen erfordert die Entwicklung zumeist spezielle Programmiergeräte oder Programme. Die Software für Embedded Systems ist in nahezu allen erdenklichen Sprachen außer vielleicht in Cobol geschrieben, ebenfalls ein deutlicher Unterschied zur Jahr-2000-Problematik in der kommerziellen DV. Das Sprachenspektrum reicht von Modula-2, C und C++, Basic über Assembler bis hin zu Maschineninstruktionen. Ergo sind hier besondere Programmierkenntnisse nötig. Ironischerweise ist gerade die Sprache, die einst zur Vereinheitlichung und Vereinfachung der Programmierung von Embedded Systems entwickelt wurde, Java, dort kaum anzutreffen.

Ein weiteres Charakteristikum ist die große Anzahl der Hersteller und Anbieter. Sind dies in der kommerziellen DV, abgesehen von PCs , nur wenige große, so findet man bei Embedded Systems sehr viele Anbieter, von Weltkonzernen bis hin zu kleinen, spezialisierten "Manufakturen".

Bei jedem der angesprochenen drei zeitbezogene Funktionen - Sortieren, Rechnen und Prüfen - kann es, sei es hardware-, sei es softwarebedingt, zu Störungen kommen. Hier seien nur kurz drei Beispiele für mögliche Fehler betrachtet. Dabei nehmen wir die einfachste Fehlerquelle an: zweistelliges Datum und die Interpretation der Jahreszahl 00 als 1900. Im Prinzip können aber bei Embedded Systems die gleichen Jahr-2000-Fehler auftreten wie bei jedem anderen eingesetzten Rechner auch.

Beispiel 1: Sortieren

Viele Systeme verfügen über einen internen Fehlerspeicher, in den Fehlercodes zusammen mit einer Zeitmarke abgelegt werden. Sehr häufig ist der interne Speicherplatz dafür begrenzt. Ist er einmal gefüllt, so wird beim Auftreten einer neuen Störung der jeweils älteste Eintrag überschrieben, das heißt eliminiert.

Nach dieser Methode werden die Fehlereinträge bei Strahltriebwerken moderner Flugzeuge erfaßt, die heute digital mit der Information, wieviel Schub sie liefern sollen, versorgt werden und diese Anweisung autonom umsetzen (Fully Autonomous Digital Engine Control = Fadec). Der Speicherplatz ist auf 65 Einträge ausgelegt, weil selbst auf Fernstrecken nicht mehr Fehler auftreten dürften. Diese Einträge werden in relativ großen Zeitintervallen überprüft. Sind nun alle 65 "Zeilen" dieses Fehlerspeichers gefüllt, so wird für den 66. Eintrag derjenige mit der ältesten Zeitmarke gelöscht.

Im Falle eines Jahr-2000-Fehlers würde irrtümlich angenommen, daß beispielsweise ein Eintrag vom 1.1.00 (1900) älter ist als einer vom 31.12.99, so daß es zum Löschen der wichtigsten Einträge käme, nämlich der neuen. Um keine Panik aufkommen zu lassen: Diesem Fehler sind Fluggesellschaften dadurch begegnet, daß sie den Speicher nach jedem Langstreckenflug auslesen und zurücksetzen, also leeren. Dies wäre ein durchaus auch bei Fertigungsstraßen etc. anwendbarer Weg, ein ähnliches Problem ohne großen Aufwand zu umgehen.

Beispiel 2: Rechnen

Fließt ein Stoff, beispielsweise Erdöl oder Gas, durch eine Leitung, so kann man das geflossene Volumen aus dem Integral des Flusses über die Zeit berechnen. In der Praxis wird man die Fließgeschwindigkeit über eine gewisse Zeit hinweg als konstant ansehen und einfach die Fließgeschwindigkeit mit der Länge dieses Zeitintervalls multiplizieren.

Dabei kann es zu fehlerhaften Berechnungen kommen, wenn man beispielsweise das Intervall vom 31.12.99, 12.00 Uhr, bis 1.1.00, 12.00 Uhr, betrachtet: Das System interpretiert 00 nicht wie gemeint als 2000, sondern als 1900; das Zeitintervall hätte demnach 100 Jahre gedauert, rückwärts gerichtet. Daraus resultiert ein negatives Volumen, der Verbraucher liefert also scheinbar den Stoff an den Lieferanten zurück.

Beispiel 3: Prüfen

Viele Anlagen besitzen eine automatische Überwachung der Wartungstermine und tolerieren Überziehungen nur in einem gewissen Maße. Danach kann es zu einer ungewollten Stillegung der Anlage kommen. Experten einer Arbeitsgruppe des Institute of Electrical and Electronics Engineers (IEEE, das amerikanische Pendant zum deutschen VDE und international eine maßgebende Standardisierungsinstanz) warnen in einer Empfehlung zum Test auf Jahr-2000-Fehler, daß es Embedded Systems gäbe, die durch gezieltes "Durchbrennen" bestimmter Chips einen solchen Stillstand sehr drastisch erzwängen.

Würde man beispielsweise am 30. November 1999 eine Wartung vornehmen und den nächste Wartungstermin dabei auf den 1.2.00 setzen, so ist augenblicklich das Wartungsinterval mit scheinbar verstrichenen rund 100 Jahren weit überschritten, es kann zum Stillstand kommen. Wichtig ist dabei, daß dieser Fehler vor der "Jahrtausendwende" auftritt!

Ein anderer Fehler beruht auf der Tatsache, daß Wochentage 1900 anders lagen, als es 2000 der Fall sein wird. Der 2. Januar 2000 ist ein Sonntag, dasselbe Datum war 1900 ein Dienstag. Nehmen wir ein Kaufhaus mit Steuerung der Türen, die automatisch in Abhängigkeit vom Wochentag entriegelt werden: Montag bis Freitag 8:00 bis 20.00 Uhr, Samstag 8:00 bis 16:00 Uhr, Sonntags geschlossen.

Interpretiert die Echtzeituhr 00 als 1900, so wird sie am 1. Januar 2000 fälschlicherweise einen Montag als Wert für den Wochentag berechnen. Dieser Fehler wird sich wegen des Feiertags - schließlich hat man ihn sorgfältig mit dem Feiertag Neujahr programmiert - nicht auswirken, und er hat damit gute Chancen, unbemerkt zu bleiben. Am 2. Januar 2000 - also in Wirklichkeit einem Sonntag - werden aber die Türen wie an einem Dienstag geöffnet!

Diese Beispiele müssen hier genügen, um darzulegen, daß schon so Anlaß genug besteht, sich mit dem Problem 2000 in Embedded Chips sehr eingehend zu beschäftigen. Dabei können die Auswirkungen, weil diese Systeme in der Regel in hierarchische Strukturen eingebettet sind, die erwähnte Fehlerquote von fünf bis zehn Prozent übersteigen: Ein fehlerhaftes Embedded System an einer sensitiven Stelle kann ganze Anlagen lahmlegen. Die dabei geschätzten Ausfallzeiten liegen nach den Ergebnissen einer Befragung in der deutschen Industrie zwischen einigen Stunden und einigen Tagen.

Die Auswirkungen dieser Fehler betreffen zum einen Sicherheit und Umwelt. Schäden an Leib und Leben von Mitarbeitern oder Anwohnern von Industrieanlagen sind nicht tolerabel. Genauso wird eine Vernachlässigung der Jahr-2000-Problematik bei Systemen, die der Sicherheit und der Unfallverhütung dienen, mit Gewißheit juristische Auseinandersetzung und/oder Sanktionen von seiten der Aufsichtsbehörden nach sich ziehen.

Dasselbe gilt für eventuelle Umweltschäden. Die kann es auch als indirekte Folge eines Jahr-2000-Fehlers geben: Man denke etwa an den Ausfall einer Steuerung für einen chemischen Reaktionskessel, bei dem Gifte ins Freie gelangen. Solche Szenerien haben einen Namen: Seveso. Übrigens war auch hier ein Fehler in der Zeitsteuerung des Kessels eine Teilursache der Katastrophe.

Einen weiteren Aspekt hat Sicherheit im Bereich der Zugangskontrolle. Dabei ist nicht nur der unkontrollierte Zugang ein mögliches Problem, sondern auch die ungewollte Aussperrung. Es wäre fatal, wenn Notfallteams, die gerade Jahr-2000-Fehler beheben sollen, nicht zu der entsprechenden Anlage gelangen könnten.

Zum anderen wären da die "normalen" Folgen von Produktionsausfällen oder -störungen. Diese können sich in einer Verschlechterung der Produkt- oder Lieferqualität niederschlagen. Darunter litten sowohl das Image eines Betriebes als auch seine (langjährigen) Kundenbeziehungen. In summa: Der Umsatz und insbesondere der Gewinn des Unternehmens sind betroffen. Und die Probleme eines Betriebes können sich, weil jedes Unternehmen Glied in einer Lieferkette ist, in der gesamten Branche und darüber hinaus auswirken.

Hinweise

In einem Beitrag für den Schwerpunkt "Notfall 2000" in der COMPUTERWOCHE 7/99, Seite 56, hat der Autor Grundregeln für die Sanierung von Systemen mit Embedded Chips sowie Empfehlungen für Notfallpläne dargelegt.

Wertvolle Hinweise zum Thema Tests mit besonderen Abschnitten zu Embedded Systems finden sich in: IEEE P2000.2

Draft Recommended Practice for Information Technology Year 2000 Test Methods, Draft 11

(IEEE, New York 1998)

*Bernd Dötschist IBM Executive Year 2000, Region Zentraleuropa, München.