computerwoche.de

Archiv

Notfall 2000/Bleiben die Black boxes unzugänglich?

Die wichtigsten Regeln für das Arbeiten mit Embedded Systems

19.02.1999
Von Bernd Dötsch Embedded Systems haben eine Reihe von Besonderheiten gegenüber klassischen DV-Systemen, so erfordern sie detailliertes technisches Wissen. Die Methoden von Jahr-2000-Projekten aus der kommerziellen DV sind übertragbar, müssen aber an diese Bedingungen angepaßt werden.

Embedded Systems stellen im Rahmen des Jahr-2000-Problems eine besondere Herausforderung dar. Die Schwierigkeiten sind nicht unlösbar, weder zu Panik noch zu Defätismus besteht Anlaß. Aber es muß zügig gehandelt werden.

Bei vielen Anwendern stehen Tests der Embedded Systems, die sich häufig als Black boxes darstellen, auf der Prioritätenliste ihrer Jahr-2000-Projekte ganz oben. Doch anders als bei bisherigen Umstellungsarbeiten mit Programmen besteht hier eine zusätzliche Schwierigkeit darin, daß sich während der Arbeiten Embedded Systems nicht ohne weiteres isolieren lassen. Sie sind im laufenden Betrieb unverzichtbar.

Immerhin läßt sich durchaus die bewährte Methodik der Jahr-2000- Projekte aus der klassischen DV anwenden. Es geht also um die Erfassung aller Anlagen, die Bestimmung der Fehler, Umstellung durch Aufrüstung, Austausch oder Anpassung sowie um Tests.

Schon der erste Schritt wirft ein Problem auf: Durch die Einkapselung der Chips in Systeme ist es in der Praxis oft schwer zu entscheiden, ob ein bestimmtes Anlagenteil auf Jahreszahlenprobleme untersucht werden muß. Grundsätzlich gilt: im Zweifelsfall ja.

Es besteht die Möglichkeit, das Problem über eine Risikoanalyse einzukreisen, wobei Vorsicht angebracht ist: Man darf ein Fehlerrisiko nicht lokal auf das jeweilige Embedded System beschränkt betrachten, sondern muß die Umgebung, in die es wirkt, berücksichtigen.

Die Analyse steht vor dem gleichen Dilemma wie die Inventarisierung. Man kann häufig nicht so in die Systeme hineinschauen, wie das mit Programmen möglich ist. Hier ist man auf verläßliche Herstellerangaben und wiederum auf Tests angewiesen.

Anders als in der klassischen DV, bei der eine Streichung selten genutzter Anwendungen den Umstellungsaufwand beträchtlich reduziert, gibt es diese Option bei Embedded Systems eher selten. Ein solches System zu streichen heißt in der Regel, auch die damit zusammenhängende Produktion oder Prozesse zu beenden.

Bei den verbleibenden Alternativen ergeben sich zusätzliche Aspekte. Um Embedded Systems zu ändern, wird häufig Spezialistenwissen benötigt, das im Unternehmen nicht vorhanden ist. Die Alternative, nämlich solche Systeme auszutauschen, setzt voraus, daß die neuen Geräte in die bestehenden Kommunikationsstrukturen passen und den jeweils verwendeten Standards entsprechen. So müssen sie hinsichtlich der Meßwerte passen, es ist zum Beispiel durchaus wichtig, ob der Druck in Bar oder Pascal gemessen wird.

Trotz der damit verbundenen Behinderung laufender Prozesse sollten Tests in einer isolierten Umgebung stattfinden, darin stimmen alle Empfehlungen überein. Dieser Rat ist schon deswegen zu beherzigen, weil Testprozeduren Informationen tragen können, die auf noch unerkannt fehlerhaften Systemen gefährliche Reaktionen auslösen könnten.

Wenn man beispielsweise zum Test eines Teils das Datum vorstellt, kann das an anderer Stelle im Gesamtsystem die Interpretation auslösen, daß der voreingestellte Wartungstermin überschritten ist. Würde man am 17. März 1999 die Uhr auf den 31.12. vorstellen, um den Übergang auf den 1.1.2000 zu testen, wäre ein eingestelltes Datum für die Wartung für den 20. Dezember überschritten. Das System würde eben so reagieren, wie es programmiert ist, zum Beispiel mit einem Nothalt. Ähnliche Fehler wurden bei Jahr-2000- Tests in der klassischen DV häufig gemacht: Man stellte die Uhr vor und übersah, daß man damit den Termin für den Ablauf des Systempaßworts "überfahren" hatte.

Das Isolieren einzelner Embedded Systems oder der Test an isolierten Exemplaren bringt aber auch eigene Probleme mit sich. Es müssen ja Ein- und Ausgabe dieser Geräte für die Tests simuliert werden, außerdem muß es erst einmal eine Möglichkeit geben, die Uhr zu verstellen. Beides ist möglicherweise mit sehr hohem Aufwand verbunden.

Nachdem das Risiko eines möglichen Fehlers durch Einzeltests minimiert wurde, ist eine Kontrolle des Gesamtsystems im Prinzip unerläßlich, in der Praxis aber nicht immer durchführbar. Es genügt nicht, die Übergangstermine 31.12.1999 auf 1.1.2000 und 28.2.2000 auf 29.2.2000 zu untersuchen. Unter anderem kommt es auch auf die Korrektheit der Wochentage an.

Eine Risikoanalyse gewichtet die Gefahren, die Embedded Systems im Fehlerfall mit sich bringen. Dazu erstellt man nach verschiedenen Kategorien, etwa nach Produktionsstörungen, Auswirkungen auf andere Anlagen(teile) etc., eine Matrix. In diese läßt sich die Bedrohung in die Kategorien niedrig, mittel und hoch unterscheiden; diese Stufen werden mit Punkten bewertet. Anschließend sortiert man die Systeme nach der Gesamtpunktzahl, so daß man die Geräte mit höchstem Risikopotential identifiziert hat und vorrangig angehen kann.

Ein besonderer Aspekt ist dabei die mögliche Unfallgefahr durch Embedded Systems. Sie sollte unbedingt in einer geeigneten Risikomatrix bewertet werden. Sonst könnte es geschehen, daß ein System mit hohem wirtschaftlichem Risiko ohne Unfallrisiko wichtiger erscheint als ein System, bei dem die Verhältnisse umgekehrt liegen.

Ebenso wie bei Umstellungen von Programmen spielt saubere Projektführung (Clean Management) eine herausragende Rolle. Darunter versteht man eine Methodik, um das unkontrollierte Einschleppen von Jahr-2000-Fehlern zu vermeiden. Allerdings unterscheidet sich diese in zwei Punkten von "normalen" Jahr-2000- Projekten:

Erstens wird es zwar angestrebt, das Einschleppen von Fehlern generell zu vermeiden. Dieser Punkt steht aber nicht im Zentrum. Vielmehr lautet die Maxime, daß Fehler nicht unkontrolliert passieren dürfen. Zweitens soll Clean Management nicht nur das Einschleppen von Fehlern in bereits umgestellte Anwendungen, sondern vom ersten Tag an in das gesamte Projekt verhindern. Eine Analyse würde sonst sinnlos.

Jahr-2000-Umstellungen an normalen Programmen bedeuten, daß man nach und nach immer mehr Systemprogramme und Anwendungen "einfriert", bis alle, und zwar einzeln, modifiziert und getestet sind. Funktionale Modifikationen werden nur in dringenden Fällen, etwa bei Änderung gesetzlicher Bestimmungen oder bei schwerwiegenden Fehlern vorgenommen. Dabei sollten sie nur nach genauer Absprache auf den alten und den modifizierten Systemen parallel und dokumentiert vorgenommen werden.

Bei Embedded Systems sieht die Praxis hingegen so aus, daß im Fall eines Fehlers, wenn beispielsweise ein Drehzahlregler für den Antriebsmotor eines Fließbands ausfällt, das mangelhafte Teil rasch ersetzt werden muß, um die Produktionsstörung zu minimieren. Das kann zur Folge haben, daß man ein bereits Jahr-2000-fähiges, aus anderen Gründen ausgefallenes Embedded System mangels rasch verfügbarer Alternative durch ein ungetestetes oder ein definitiv nicht Jahr-2000-fähiges ersetzen muß.

An solch einem Punkt zeigt sich die Bedeutung von Clean Management. Nur eine saubere Projektführung kann dafür Sorge tragen, daß solche Maßnahmen in Maschinen- oder Schichtprotokollen dokumentiert werden, um hier später wieder ein Jahr-2000-fähiges Embedded System einbauen zu können.

Notfallpläne

Aufgrund der Komplexität vernetzter Embedded Systems und der knappen verbleibenden Zeit sind Ausfälle durch unentdeckte oder unbehandelte Jahr-2000-Fehler sehr wahrscheinlich. Zur Vorsorge sind entsprechende Notfallpläne notwendig, die unter Rückgriff auf sicher verfügbare Ressourcen einen - eventuell auch eingeschränkten - Betrieb erlauben. Dabei muß eine Reihe von Fragen beantwortet werden:

-Welche Anlagen müssen unbedingt laufen? Unter Umständen kann auf bestimmte Teile ohne größere Einschränkungen für eine gewisse Zeit verzichtet werden.

-Sind die entsprechenden Betriebsstoffe und -mittel verfügbar? Dazu zählen Gas, Wasser, vor allem aber Elektrizität, wozu es eventuell einer Notstromversorgung bedarf.

-Ist gegebenenfalls Handbetrieb möglich? Dies setzt sowohl die Existenz der dazu notwendigen Vorrichtungen als auch entsprechend ausgebildetes und erfahrenes Personal für ihre Bedienung voraus.

-Kann man die Schichtpläne entsprechend anpassen? Ein manueller Betrieb erfordert in der Regel mehr Personal als ein automatischer. Eventuelle Urlaubssperren zur Verstärkung der Schichten sind zu überlegen.

Hinweise

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)

Angeklickt

Jahr-2000-Projektleiter stehen vor einem Problem, das sich nicht annähernd so "einfach" eingrenzen und bekämpfen läßt wie Datumsfehler in Programmen. Abgesehen von ihrer kaum überschaubaren Zahl und ungeachtet möglicher rechtlicher Schwierigkeiten, verlangen Arbeiten daran Spezialwissen und oft Spezialwerkzeuge. Allerdings läßt sich auch hier das Problem durch Methodik und sauberes Projekt-Management zumindest eingrenzen, seine Bekämpfung in Schritte und Zeitpläne gliedern.

Bernd Dötsch ist IBM Executive Year 2000, Region Zentraleuropa, München.