This is an archived page and is no longer updated.
Please visit our current pages at https://rvs-bi.de

Das Jahr-2000-Problem

Heiko Holtkamp, Peter B. Ladkin
Übersetzt von Michael Blume (Draft Version)

"Houston, we have a problem."

Wir behandeln das Jahr 2000-Problem (engl. millennium bug, Y2K), was es bedeutet und welche Systeme hiervon betroffen sind. Diese Seiten sind sowohl für Leser mit als auch ohne Vorkenntnisse auf diesem Gebiet geeignet. Wo es notwendig ist, werden relevante Hintergrundinformationen bereitgestellt.
Diese Seiten sind im Zusammenhang mit dem Seminar "Das Y2K-Problem" entstanden. In diesem Seminar werden eigene Strategien zum Jahr-2000-Problem entwickelt und analysiert. Daher wird diese Seite fortwährend aktualisiert.

Inhalt

Inhalt

Was ist das Jahr-2000-Problem?

Das Jahr-2000-Problem resultiert aus der Repräsentation der Jahreszahl mit nur zwei Stellen, z.B. 27.04.98 statt 27.04.1998. Daraus ergibt sich ein Datenambiguitätsproblem (data ambiguity problem DAP): ist der 01.01.00 der 1. Januar des Jahres 1900 oder des Jahres 2000? Jeder Mensch hat normalerweise bei der Benutzung des Datums genug Hintergrundinformationenen um zu wissen, was gemeint ist. Aber für Chips, Programme und andere digitale Hardware, die nicht speziell konstruiert wurden, um diese Ambiguität zu kompensieren, besteht hierin ein großes Problem. Diese Maschinen können nicht auf "Alltags"-Hintergrundinformationen zurükgreifen um die Ambiguitäten zu bemerken, da sie nur ihrer jeweiligen Spezifikation folgen.

Eine genauere Beschreibung des Problems stellt das Jahr-2000-Problem als eine Datenrepräsentationsunstetigkeit ( date representation discontinuity-DRD ) dar. Eine Datenrepräsentationsunstetigkeit (Informationen auf Engl.) ist gekennzeichnet durch:

Solche Probleme sind eine Konsequenz aus der Darstellung von Daten in Computern. Für Leser, die hiermit nicht vertraut sind, bieten wir eine kurze Einführung in die Darstellung von Daten in Computern (Information auf Engl.).

Inhalt

Verschiedene Probleme mit Datenrepräsentationsunstetigkeit

Das Jahr-2000-Problem ist naturlich nicht die einzige Datenrepräsentationsunstetigkeit, über die wir uns Sorgen machen sollten. Viele Computer-Systeme (sowohl Hardware als auch Software) werden auch zu anderen Zeitpunkten Probleme haben.

Mehrdeutige End-of-File Marken

Viele Programme, insbesondere Datenbanken, nutzen das Datum 9.9.99 (oder ähnliche Konstrukte wie 1.11.11, 0.00.00) als Löschmarke. Dieses ist ein gutes Beispiel für "vorsätzlich" herbeigeführte Datenambiguität, die vermeidbar gewesen wäre.Diese Systeme könnten z.B. am 9.September 1999 Probleme bekommen.

Inhalt

32-Bit-Unix-Systeme und C/C++

Viele Unix Systeme (insbesondere die 32-Bit-Unix-Systeme) haben am 19. Januar 2038 eine DRD. Zu diesem Zeitpunkt erreicht die Systemzeitberechnung ihre Grenzen und springt auf den Anfang zurück.Unix-Systeme berechnen die Systemzeit durch die Anzahl der verstrichenden Sekunden ab dem 1.1.1970 um 0.00.00 Uhr GMT. Das Ergebnis wird in einer 32-Bit Integervariablen (mit Vorzeichen) gespeichert. Hierbei ergibt sich das Problem, daß diese Variable ihren maximalen binären Wert (2^32) am 19.01.2038 erreicht und ein sog. Überlauf (overflow) stattfinden wird. Dieses betrifft ebenso viele C und C++ Programme, die dieselbe Zeitrepräsentation benutzen.

Inhalt

Das globale Satellitennavigationssystem GPS

Navigation ist heute meist satellitengestützt und daher im hohen Maße abhängig von dem bekannten GPS ( global positioning system), welches von dem U.S. Militär betrieben wird. GPS basiert auf der sehr genauen Ortsbestimmung mittels mehrerer Satelliten in der "Umgebung" der gewählten Koordinaten. In vielen Transportunternehmen werden diese Daten genutzt um z.B. die genauen Standorte von LKW's zu ermitteln. Mittlerweile hält GPS auch immer mehr Einzug in PKW-Navigationssysteme (z.B. zur Routenplanung). Kritischer ist allerdings die Tatsache, daß auch Flugzeuge das GPS zur Navigation und insbesondere zur Landung auf Flughäfen im Instrumentalflug (z.B. bei schlechter Sicht etc.) nutzen bzw. darauf angewiesen sind. Aufgrund dieser großen Bedeutung des GPS könnte eine DRD im GPS zu sicherheitskritischen Situationen führen..

GPS zählt die Wochen seit dem 5. Januar 1980 um das aktuelle Datum zu errechnen. Das Ergebnis wird in einer 10-Bit Integer (ohne Vorzeichen) abgelegt. Dieses beinhaltet eine DRD zwischen der 1024. und der 1025. Woche seit dem Beginn der Rechnung, welche exakt am 21. August 1999 auftreten wird (wahrscheinlich um ca. 23:59:59 Uhr). GPS-Systeme, die diese Datendiskontinuität nicht speziell behandeln,können zu dem Zeitpunkt des "roll-overs" Probleme haben und falsche Daten liefern.

Inhalt

Berechnung von Schaltjahren

Ein anderer Fall, welcher keine DRD beinhaltet, hängt mit der Berechnung des Schaltjahres zusammen. Viele Programme werden nicht erkennen, daß das Jahr 2000 ein Schaltjahr ist, also der 29. Februar (2000) existiert. Dies liegt an der falschen/unvollständigen Implementation der Regeln für ein Schaltjahr. Ein Jahr ist ein Schaltjahr, wenn es folgende Bedingungen erfüllt:
  • die Jahreszahl ist (echt) durch 4 teilbar,
  • es ist nicht durch 100 teilbar,
  • aber es ist ein Schaltjahr, wenn es durch 400 teilbar ist
(siehe dazu Claus Tondering: Frequently asked questions about Calendars.)

Programme, in denen "kurzsichtige Bugfixes" (z.b. "Windowing", d.h. das Arbeiten in einem Zeitfenster) für zweistellige Datenambiguitätsprobleme implementiert sind, werden folglich früher oder später, wenn die jeweilige Fenstergröße nicht mehr ausreicht, Schwierigkeiten bekommen. Kurz gefaßt sind die Probleme mit dem Jahr 2000 folgender Natur:

Inhalt

Standards für die Datenrepräsentation

Der letzte in der kurzen Auflistung genannte Punkt, das Fehlen eines einheitlichen Standards für die Repräsentation von Daten, ist nicht unbedingt ein Jahr-2000-Problem. Dennoch würde die Schaffung eines einheitlichen Standards viele Probleme im Zusammenhang mit dem Jahr-2000-Problem lösen. Genau genommen existiert solch ein Standard sogar. Die internationale Norm ISO 8601 aus dem Jahre 1988 legt die Schreibweise "YYYY-MM-DD" für ein Datum fest. Diese Norm ist in Europa durch die Norm EN 28601 und in Deutschland durch die Norm DIN 5008 übernommen worden. 
Dieser Standard beinhaltet genauer betrachtet zwei DRD's: Im Jahre 0 AD (Anno Domini) und im Jahre 10.000 AD. Der Standard schreibt nicht vor, welche interne Datenrepräsentation gewählt wird (z.B. Integer mit, oder ohne Vorzeichen etc, aber das Datenformat ist explizit positiv, AD-Zeitrechnung vorrausgesetzt). Das DRD im Jahre 0 könnte für Archäologen oder Ahnenforscher ein Problem sein, welche auch Daten BC (d.h. Integer mit Vorzeichen) darstellen müssen. Wir überlassen es dem Leser zu entscheiden, ob ein DRD im Jahre 10.000 AD ein "echtes" Problem ist.

Inhalt

Genaue Zeitrepräsentation

Es gibt Repräsentationen, die nicht die Tage benutzen, sondern die Sekunden (z.B. die UNIX-Systemzeitberechnung). Wenn Sekunden benutzt werden, kann es sehr schwierig sein, eine Datenrepräsentationsunstetigkeit vorrauszusagen. So werden für die Universal Coordinated Time (UTC) Schaltsekunden in die Zeitmessung eingefügt. Die Schaltsekunden dienen der Angleichung der Zeitmessung an die leicht unregelmäßige Rotation der Erde, der Erdbahn und den daraus resultierenden ungleichen Tageslängen. Da es physikalisch zur Zeit noch nicht möglich ist, die genauen Tageslängen für alle künftigen Tage (bezogen auf eine "absolute" Zeitmessung, z.B. eine Atomuhr) vorherzusagen, kann auch keine Aussage über alle zukünftigen Schaltsekunden gemacht werden.
Siehe hierzu unter Risks "a definitive clarification of time measurement"  (Band 19(14) 14. Mai 1997 John Laverty und Peter Ladkin)

Inhalt  

Was ist das Problem mit dem Jahr-2000-Problem?

Viele Unternehmen und Computerbenutzer haben das Problem zu spät bemerkt, um die richtigen Untersuchungen durchzuführen, oder sie haben es bis jetzt ignoriert. Jedes System, das ein Datum oder eine Uhr benutzt, kann von den genannten Problemen betroffen sein. Für viele Menschen ist es allerdings schwer sich dieses deutlich zu machen, da die Uhren in den meisten Fällen nicht sichtbar sind. Jetzt folgen einige kurze Beispiele dazu.

Inhalt

Hochsprachen Software

Bei Software, die in einer Hochsprache (z.B. C oder C++) geschrieben wurde, ist es evtl. leichter zu überprüfen, ob ein 2-stelliges Datum explizit genutzt wird (vorrausgesetzt der Quellcode ist vorhanden). Aber die meiste Software ist ohne eine Definition von ihren Datenstrukturen vorhanden, da diese z.B. schon sehr alt ist oder die Programmierer keine Informationen darüber weitergaben. Es kann dann nur eine Datenrepräsentation angenommen werden, ohne daß bewiesen werden kann, ob die Software diese auch erfüllt.
In diesem Fall bleibt nur zu hoffen, daß durch Testen der Software, z.B. mit eingestellter kritischer Systemzeit (23.59.59 Uhr am 31.12.1999), ein feststellbarer und analysierbarer Effekt aufritt. Nur kann man dabei nie sicher sein, ob ein Fehler nicht erst später in Erscheinung tritt. Nehmen wir als Beispiel ein Finanzbuchhaltungs-System. Dieses errechnet am Ende des Jahres 2000, daß Zinsen nicht für ein Jahr, sondern für 101 Jahre fällig sind und schickt die Rechnung Anfang 2001.

Inhalt

Echtzeit-Systeme

Echtzeit-Systeme (real time systems) sind sehr von ihrer Systemuhr abhängig. Auch diese Systeme kann man unter geeignet eingestellter Systemumgebung (z.B. Systemzeit 23:59:59 Uhr 31.12.1999) testen. Allerdings kann auch hier nicht ein mit Verzögerung auftretender Effekt ausgeschlossen werden. Zum Beispiel gibt es Software, welche nur alle 24 Stunden einen Rechner "erweckt" und bestimmte Daten verarbeitet. Geschieht dieses am Ende des ersten Tages vom neuen Jahrtausend, so könnten Fehlberechnungen auftreten die durch eine DRD verursacht worden sind. Das System kommt hierdurch in einen unspezifizierten Zustand und schaltet sich evtl. selbst in einem Notfallmodus ab. Ein solcher Effekt kann nur in einem Test über mehr als 24-Stunden diagnostiziert werden.

Inhalt

Versteckte Uhren

Schwerer zu entdecken sind die Effekte von DRD's oder DAP's, wenn in der Hardware eine Uhr vorhanden ist, welche die Software des Systems nie benutzt, keinen direkten Zugriff darauf hat, aber die von der eigentlichen Hardware zur reibungslosen Funktion benötigt wird. Manchmal ist es möglich, dieses durch eine Anfrage an den Hersteller hinsichtlich einer "versteckten Uhr" und der damit verbundenen Jahr-2000-Anfälligkeit der Hardware zu klären. Aber es ist nicht selten der Fall, daß die spezielle Hardware nicht mehr unterstützt wird; man spricht hier auch von sog. "legacy"-Systemen (Systeme die mit "Altlasten" behaftet sind). Dann ist eine Klärung der Jahr-2000-Anfälligkeit dieser Hardware nur noch durch Auswertung von alten Daten, durch elektronische Analyse der Hardware und Tests möglich.


Inhalt

Sicherheitskritische Systeme

Sicherheitskritische Systeme benötigen besondere Sorgfalt, insbesondere wenn sie zu Testzwecken vom Gesamtsystem getrennt sind. Eine gute Anleitung zum Testen und Anlysieren von solchen komplexen Systemen das Jahr 2000-Problem betreffend findet man in folgenden Büchern: Safety and the Year 2000 und Testing Safety-Related Control Systems for Year-2000 Compliance. Beide sind im Online-Versandhandel zu bestellen. (www.hsebooks.co.uk)


Inhalt

Legacy Systeme: Ein Beispiel

Ein Beispiel für "legacy"-Systeme mit (versteckten) Uhren sind die FAA En-Route Air Traffic Display Systeme. Diese basieren auf mehr als 30 Jahre alten IBM 9020E Maschinen oder auf den ebenfalls sehr alten Raytheon 760 Maschinen (älter als 25 Jahre!). Diese sind nach Herstellerangaben definitiv nicht Jahr 2000 fähig. Sie sollten so bald wie möglich (vor Ende 1999) durch das neue DSR System ersetzt werden.

Inhalt

PC-basierte Systeme

Am häufigsten treten "legacy"-Systeme wohl in Form von alten PCs auf. Meist benutzen diese noch Windows 3.1 oder noch frühere Versionen einer graphischen Benutzeroberfläche. Im Gegensatz zu neueren Versionen von Windows (Windows95/98), die kaum oder garnicht mehr auf MS-DOS angewiesen sind, basieren die alten Windows-Versionen noch auf MS-DOS. Je nach Betriebssystemversion können verschiedene Strategien zum Testen auf Jahr-2000-Fähigkeit des Systems angebracht sein. Ein einfacher Test ist z.B. die Veräderung der Systemzeit im BIOS auf den kritischen Zeitpunkt 23:59:95 Uhr 31.12.1999. Alte PC's haben zum Teil noch ein BIOS mit zweistelligem Jahreszahlfeld. Hier ist dann ein BIOS-Update vom Hersteller angebracht. Ein besonderes Problem wird durch alte Software verursacht. Oft ist der Hersteller nicht mehr vorhanden, oder sie wird nicht mehr unterstützt. Die Hersteller geben evtl. Auskunft über die Jahr-2000-Fähigkeit ihres Produktes, oder bieten Updates an. Es ist aber fast immer ratsam, falls sie nicht sicher sein können, daß eine Software Jahr-2000-fähig ist, eine sichere Software zu erwerben.

Inhalt

Abhängigkeit von Herstellerinformationen

Wenn die Informationen eines Herstellers hinsichtlich der Jahr-2000-Fähigkeit seines Produkts vertrauenswürdig sind, so wird die Analyse des gesammten Systems wesentlich erleichtert. Aber wer beurteilt die Vertrauenswürdigkeit eines Herstellers? Vieles hängt von dem Ruf des Herstellers, seiner Informationmsstrategie zum Jahr-2000-Problem und dem Risikofaktor des jeweiligen Produktes ab. So sollte ein im Krankenhaus genutztes Lebenserhaltungssystem entsprechend Jahr-2000-fähig und entsprechend analysiert sein, ganz unabhängig von den genannten Kriterien der Vertrauenswürdigkeit. Bei einem Videospiel hingegen ist es jedem selbst überlassen, es zu nutzen und dabei zu warten, ob es Jahr 2000 fähig ist.

Inhalt

"Eine interessante Antwort"

Eine der menschlichsten Antworten auf die Frage nach dem Jahr-2000-Problem stammt von einem thailändischen Geschäftsmann: "Wir haben kein Problem, da wir nicht den Julianischen Kalender benutzen (Thailand hat in den nächsten Jahren keine Jahrtausendwende: 1998 julianisch entspricht 2541)."
Weitere Informationen dazu: International Herald Tribune, "Distracted Asia Ignores The Millennium Bug" by Thomas Crampton, 17-18.10.1998, p1. Diese Anekdote ist Ian Anderson gewidmet. Iain Anderson ist Berater der Britischen Regierung in Jahr-2000-Angelegenheiten. Er schrieb den Artikel `No hiding place' auf Seite 16 im The Economist, der einen Überblick zum Jahr-2000-Problem gibt: Time Runs Out (erschienen am 19. September 1998). Wir überlassen es dem Leser zu entscheiden, wie korrekt die zitierte Begründung ist.

Inhalt 

Konsequenzen aus dem Jahr-2000-Problem und Vermeidung von DRD's

Niemand kann absehen, wie viele Resourcen benötigt werden, um mit dem sog. Jahrtausend-Problem fertig zu werden. Schätzungen gehen von mehreren Billionen Dollar weltweit aus. Letztlich kann aber niemand die Tragweite des Problems vollständig erfassen. Daher gehen die Vermutungen von Fachleuten weit auseinander. Dazu zwei extreme Beispiele:

Inhalt

Ökonomische Konsequenzen

Klar ist, das Jahr-2000-Problem wird in jedem Fall sehr teuer. Wenn das Problem grob überschätzt worden ist, so sind die Billionen von Dollars und menschliche Arbeitszeit "umsonst" gewesen. Ist es aber ein echtes Problem und viele Menschen haben sich nicht um dieses gekümmert, so wird es mit hoher Wahrscheinlichkeit fatale Folgen haben. Auch wenn es nur in Teilbereichen auftritt, kann es als Konsequenz durch die Summierung der kleinen Effekte auch die Allgemeinheit betreffen. Sicherlich ist dieses ein Problem von großer Bedeutung, sowohl in menschlicher als auch ökonomischer Sicht. Die Zeitschrift "The Economist" sagte dazu sinngemäß: es sei das teuerste technologische Versagen einer einzelnen Technologie, in Dollar gerechnet, in der Geschichte der Menschheit.

Betrachtet man die Veröffentlichungen derjenigen, die ihre Systeme auf die Jahr-2000-Fähigkeit hin überprüft haben, so ist ersichtlich, daß der Millennium Bug eher unterschätzt als überschätzt wurde und wird (siehe dazu das Zitat von Martyn Thomas (s.o.)).

Inhalt

Vermeidung solcher Probleme in der Zukunft

Obwohl wir mit verschiedenen Folgen des Jahr-2000-Problems in Berührung kommen können, ist die Vermeidung von Datenrepräsentationsunstetigkeitsproblemen relativ einfach. Alle Datentypen und ihre Wertebereiche müssen explizit spezifiziert werden. Entweder in den Systembedingungen oder beim Design des Computersystems. Außerdem sollte sichergestellt sein, daß Überläufe korrekt gemeldet und behandelt werden. (Die Mißachtung einiger dieser Anforderungen führte zu dem Ariane 501 Unfall. Siehe dazu: The Ariane 5 Accident: A Programming Problem? by Peter Ladkin, Research Report RVS-J-98-02, and An Analysis of the Ariane 5 Flight 501 Failure - A System Engineering Perspective by Gérard Le Lann, IEEE Symposium and Workshop in Engineering of Computer-Based systems, 1997.)

Die genannten Anforderungen sind Standardeigenschaften einer normalen, genauen Spezifikation. Eine Spezifikation ist nur dann vollständig, wenn durch sie bewiesen werden kann (formal oder informal), daß das Design des Systems die Anforderungen an das System erfüllt, sowie der Code wiederum die Design-Spezifikation und die Hardware den Code, hinsichtlich der Semantik der jeweiligen Programmiersprache, korrekt ausführt.

Mit formalen Methoden vertraute Software Entwickler sind schon lange Verfechter einer weitreichenden Anwendung solcher Prozeduren, besonders bei sicherheitskritischen und anderen essentiellen Systemen. Angewendet wurden und werden diese Techniken z.Z. aber vor allem bei sicherheitskritischen Systemen. Natürlich sind einige Bereiche weiter in der Anwendung dieser Techniken, z.B. Militärische Flugsysteme, als andere, z.B. Krankenhaustechnik. Die Aktualität und drohende Konsequenzen aus dem Jahr-2000-Problem verhelfen momentan diesen Techniken zu mehr Popularität. Es ist ökonomisch sinnvoll, in vielen Bereichen genaue Spezifikationen zu erstellen, zum einen da die Vermeidung der nachträglichen Analyse und Fehlersuche im System, z.B. auf die Jahr- 2000 -Fähigkeit hin, mehr Geld kostet; zum anderen ist die Vermeidung der Folgen auch sehr lohnend. Zum jetzigen Zeitpunkt erscheint es "klüger", für die Vergangenheit zu hoffen und für die Zukunft zu planen.

Inhalt

Information zum Jahr-2000-Problem

Martyn Thomas schrieb einige kurze aber sehr gute Artikel, in denen er versucht hat die Verbreitung des Jahr-2000-Problems in Kategorien zu fassen. Wir sind dankbar für seine Arbeit und fügen seine Artikel (s.u.) mit seiner Erlaubnis in unsere Publikationen ein.

Peter de Jaeger hat eine Menge an Informationen bezogen auf das Jahr-2000-Problem gesammelt. Er schrieb schon im September 1993, daß uns allen die Zeit für eine Lösung des Problems davon läuft (siehe z.B. ein Zitat aus einem seiner Artikel Doomsday 2000).

Zurück zum Inhaltsverzeichnis