Never change a running system

Einleitung

Während die Lebensdauer der Geräte im Office-Umfeld typischerweise drei bis vier Jahre ist, laufen Anlagen, Systeme und Geräte im Fabrikumfeld mindestens zehn Jahre, in den meisten Fällen sogar 15 bis 20 Jahre oder darüber hinaus.
Doch wie wird deren Funktionsfähigkeit gesichert, wenn die verwendeten Betriebssysteme vom Hersteller nicht mehr unterstützt werden, wenn es keine Updates und Patches mehr gibt?

Einen Vorgeschmack auf die Langlebigkeit von Softwareprogrammen bekamen die Anwender beim inzwischen bewältigten Y2K- oder Millennium-Problem. Welcher Programmierer hätte sich schon in den siebziger Jahren des vergangenen Jahrhunderts vorstellen können, dass seine Cobol-Programme noch nach der Jahrtausendwende produktiv genutzt würden und er aus dem verdienten Ruhestand re-aktiviert würde, um die einmal eingeführte Software zu patchen. Dies alles nur, weil man damals zur Darstellung von Jahreszahlen zwei statt vier Stellen verwendete, um keinen Speicherplatz zu verschwenden. Dies ging bis zum Jahreswechsel 1999/2000 gut. Aber danach hätte jeder Computer die zweistellige Jahreszahl 00 sowohl als 1900 und 2000 interpretiert. Die Folgen wären falsche Sortierungen oder Altersberechnungen sowie ungültige Datensätze, fehlerhafte Differenzberechnung und falsche Echtzeit. Die Kosten für vorsorgliche Maßnahmen gegen das Millennium-Problem bezifferte das Massachusetts Institute of Technology allein für das amerikanische Medicare-Programm auf 500 Millionen Dollar.

PC-systems conquer control rooms
Mit der Einführung PC-basierter Leitsysteme verkürzten sich die Innovationszyklen

Doch auch im Fabrikumfeld gab es das Y2K-Problem: In vielen Werken liefen damals Systeme, die plötzlich umgestellt werden mussten, weil die Hersteller für die eingesetzten Software- und Hardware-Komponenten keinen Support mehr lieferten. So auch bei einem großen Automobilhersteller in dessen fünf Presswerken die Produktionsleitstände auf einem PC-basierten Unix-System und Intel 486-Rechnern liefen - problemlos und gut.

Doch das zum Zeitpunkt seiner Inbetriebnahme vor zwanzig Jahren modernste Unix-Betriebssystem Interactive unix war schon lange abgekündigt, die Firma verkauft und das Nachfolgeunternehmen pflegte die Software nicht mehr weiter. Gleichzeitig wurde auch bei den eingesetzten Intel 486-PC ein Y2K-Problem vermutet. Das Umstellen auf ein anderes System hat entscheidende Konsequenzen für Ereignisverarbeitungen, Datenbankabfragen und Prozessbilder. Sie müssen alle neu erstellt, getestet und in Betrieb genommen werden – und dies möglichst ohne Beeinträchtigung der laufenden Produktion. Als Ausweg bot sich an, die Applikationen auf dem Prozessleitstand unverändert zu lassen und die Kommunikation zur Automatisierungs- und Feldebene mit einheitlicher Standardsoftware anzupassen. Nach dem Test beim Systemintegrator erfolgte die Umstellung für den produktiven Betrieb an einem Wochenende.


The Y2K problem showed how long Software systems are in productive use
Nicht nur der 01.01.2000 versetzte IT-Spezialisten in Aufregung

Wer jetzt denkt, das Y2K-Problem kommt nicht wieder, der sollte sich den Jahreswechsel 2009/2010 anschauen. Am 1.1. 2010 gab es Probleme mit dem Datumswechsel bei Kreditkarten, Buchungssystemen, Antivirenprogrammen und Spamfiltern. Glücklicherweise ist das nächste technische Problem dieser Art nicht vor dem 19. Januar 2038 zu erwarten. Denn dann überschreitet die 32-Bit-Ganzzahl für die Systemzeit in Unix-Systemen ihren Maximalwert und setzt die Systemzeit wieder auf den Anfangswert vom 1. Januar 1970. Hiervon werden nicht nur Banken und Versicherungen betroffen sein, sondern auch viele Kleinsysteme wie Router, elektronische Messgeräte, intelligente Sensoren und andere, die Unix-Derivate verwenden.

Entscheidung für Soft- und Hardware hat weitreichende Folgen

Man sieht an diesen Beispielen, dass die Entscheidung für die eine oder andere Software strategischen Charakter hat. Einmal eingeführt, muss man mit den Programmen und der Abhängigkeit von der Release-Planung des Herstellers jahrelang leben. Aufwand und damit verbundene Kosten für Bereitstellung und Betrieb der einmal instal-lierten Hard- und Software sowie der Kommunikationskomponenten steigen mit der Betriebsdauer. Hatten bisher Prozessleitsysteme auf Workstations eine Produktlaufzeit von bis zu 20 Jahren, so ist dies bei den PC-basierten Standardkomponenten nicht der Fall. Spätes-tens dann, wenn die laufenden Kosten für Reparatur und Instandhaltung überproportional ansteigen oder fehlende Erweiterungsmöglich-keiten die Wettbewerbschancen verringern, ist es Zeit für die Modernisierung. Wie am Beispiel des Automobilherstellers bereits erwähnt, steckt in der Anlagensoftware das gesamte Know-how eines Unternehmens mit allen technologischen Regelungen, mit bewährten Steuerungsalgorithmen und allen Anlagenbedienbildern. Eine Vorstellung der Komplexität einer solchen Portierung oder Migration zeigt als Beispiel das Mengengerüst eines Leitsystems im Klärwerk Ruhleben der Berliner Wasserwerke. Die Berliner Wasserbetriebe gehören zu den größten Unternehmen der Wasserversorgung und Abwasserbehandlung in Deutschland.

Abwasseraufbereitungsanlage Berlin Ruhleben

Sie betreiben ein 9.400 Kilometer langes Abwasserkanalnetz mit rund 225.000 Anschlussleitungen und 147 Pumpwerken und reinigen jährlich über 220 Millionen Kubikmeter Wasser. Die prozessleittechnische Anlage in Ruhleben bestand zum Zeitpunkt der Modernisierung im Jahre 2004 aus zehn Bedienstationen mit mehr als zwanzig Monitoren in vier Warten. 45 Automatisierungssysteme überwachten und regelten die Abwasseraufbereitungsanlage.

Das Leitsystem verwaltete mehr als 750 Anlagenbilder und 650 Kurvendarstellungen von 1.800 Antrieben und 2.700 Messstellen. Insgesamt konnte das System etwa 20.000 Einzelmeldungen und mehr als 210.000 Variable ausgeben. Die Umstellung erfolgte zeitlich gestaffelt in zwei Stufen: Zuerst wurde die Software toolgestützt an das neue System angepasst. Bei dieser schrittweisen Teilmodernisierung bleiben Anlagenperipherie mit Sensorik und Ein- und Ausgabebaugruppen erhalten. Nach der Wiederinbetriebnahme arbeiten die Anlagen technologisch exakt so wie vorher. Im zweiten Schritt erfolgte die Modernisierung der Hardware mit Verdrahtung, Baugruppentausch, Einstellen der Rangierverteiler und Anlagentest. Die Umstellung erfolgte im laufenden Betrieb ohne wesentliche Unterbrechung.

Wie die oben genannte Modernisierung verdeutlicht, muss der Anlagenbetreiber allein aus Kostengründen immer mehr nach einer informationstechnischen Infrastruktur suchen, die sich leicht und flexibel in bestehende Architekturen integrieren lässt. Von einigen Ausnahmen abgesehen, gibt es keinen einheitlichen Standard für die Verbindung der verschiedenen Produktionsbereiche und -ebenen. Jeder Maschinen- und Anlagenbauer versieht seine Systeme mit einem für die jeweilige Aufgabe am besten geeigneten Betriebssystem und einer eigenen Kommunikationsschnittstelle für den Datenaustausch, deren Fokus nicht unbedingt auf der Integrationsfähigkeit liegt. Dies muss auch nicht, wenn beispielsweise Werkzeugmaschinen, Drucker, Fördereinrichtungen oder Tanks und Hochbehälter weitab stehen oder für sich allein arbeiten. Wenn diese Systeme dann in einen Produktionsverbund eingebaut werden sollen, kann sich oft eine extrem komplexe und heterogene Verfahrenslandschaft ergeben, deren viele Schnittstellen den Informationsfluss undurchschaubar machen. Spätestens bei Modernisierungen verursacht dies erhebliche Zusatzkosten sowie einen hohen Entwicklungs- und Portierungsaufwand.

Dreiklang von Offenheit, Echtzeitfähigkeit und Sicherheit

Offenheit und Security

Kostensenkungen lassen sich nur erreichen, wenn man zum einen die Komplexität der Anlage und des Leit- oder Automatisierungssystems verringert und zum anderen auf offene Standards setzt. Genau diese Richtung geben seit Jahren die Internettechnologien mit TCP/IP und Ethernet auch in der Industrie vor. Sie bieten die Voraussetzung zum Standardisieren und vereinfachen die Verknüpfung bis-lang unabhängig operierende Netzwerke und Infrastrukturwelten.

Auf der Prozessebene haben sich die verschiedenen Feldbusse als Standard durchgesetzt. Um wirklich alle unterschiedlichen Automatisierungsgeräte wie speicherprogrammierbare Steuerungen oder Sensoren der verschiedenen Hersteller in ein gemeinsames, flexibles Netzwerk einzubinden, lieferte Microsoft mit OPC (OLE for Process Control) einen Quasi-Industriestandard.

Heute ist die OPC Foundation für die Pflege und Verbreitung des Standards zuständig, der mittlerweile über 450 Unternehmen angehören. Ohne OPC benötigten zwei Geräte zum Datenaustausch genaue Kenntnis über die Kommunikationsmöglichkeiten des Gegenübers. Erweiterungen und Austausch gestalten sich entsprechend schwierig.

Mit OPC genügt es, für jedes Gerät genau einmal einen OPC-konformen Treiber zu schreiben. OPC basiert hauptsächlich auf Microsofts DCOM-Spezifikation. Eine Kommunikation über die Grenzen von Firewalls oder Domänen ist über einen OPC-Tunnel möglich. Aber auch ohne OPC-Tunnel kann über Router und Firewalls hinweg kommuniziert werden. Die Authentifizierung erfolgt dann über eine lokale Benutzertabelle. Der Nachteil dabei ist, dass sowohl auf dem Server als auch auf dem Client ein identischer lokaler Benutzer vorhanden sein muss, der die OPC-, bzw. DCOM-Kommunikation abwickelt. Auch das Passwort muss identisch sein!

Bei einer großen Anlage oder Produktionsstätte bei der viele unterschiedliche Geräte, Systeme und Komponenten über OPC eingebunden werden müssen, erweist sich die einzelne Zuweisung eines Benutzers für jedes Gerät mit einem individuellen Passwort als äußerst unpraktikabel bis unmöglich. Denn Echtzeitfähigkeit schließt aufwändige Security-Maßnahmen genauso aus wie Datenverschlüsselung. Um eine ausreichende Performance zu erhalten, werden die Systeme so integriert, dass sie fremden Daten im Netzwerk blind vertrauen. Mit jedem Virenscan und Security-Check, mit jeder Autorisierung und Authentifizierung eines Telegramms sinkt die Performance der Anlage dramatisch. Datenverluste aufgrund von Laufzeitfehlern und erhebliche Produktionsbeeinträchtigungen könnten die Folge sein.

Performance versus Sicherheit

Mitte der 90er Jahre, als sich OPC mit Windows 95 etablierte, dachte kaum jemand an Viren und Trojaner in der Fabrikumgebung. Zum damaligen Zeitpunkt waren die Fabriknetze streng getrennt vom Büronetz. Zugang zu den Steuerungen hatte nur eine Handvoll von Mitarbeitern aus dem Service und Instandhaltungsbereich. Die Kommunikation in geschlossenen Netzen bot ausreichenden Schutz, da sie weder eine Verbindung ins Internet noch ins Unternehmensnetz hatte. Inzwischen hat sich auch das Bild der Industrieumgebung gewandelt: Flexibilität, Offenheit und Mobilität sind gefragt. Damit ist der Betrieb einer Netzwerkverbindung die Regel und nicht mehr die Ausnahme. Inzwischen wurde mit OPC UA (Unified Architecture) eine Spezifikation entwickelt, die alle bisherigen Spezifikationen platform- und DCOM-unabhängig umsetzen soll. Die Kernelemente dieser Spezifikation wurden Anfang 2009 zur endgültigen Abstimmung als IEC-Norm (IEC 62541) angenommen. Grundprinzip ist hier, Maschinendaten wie Prozesswerte, Messwerte und Parameter nicht nur zu transportieren, sondern auch maschinenlesbar zu beschreiben. Eine eigene Security-Implementierung, basierend auf den neuesten Standards, sorgt jetzt für entsprechende Sicherheit.

Sicherheit verteilt sich auf mehreren Schultern


Doch Sicherheit ist nicht nur Aufgabe des Herstellers und Systemintegrators, sondern auch des Betreibers und Bedieners. Alle haben dafür zu sorgen, dass die Gateways ausreichend gehärtet sind, die Ports geschlossen sind, eine mehrstufige Firewall das industrielle Netz schützt und der Zugang zu den Schaltschränken versperrt ist. Wie hoch allerdings das Risiko eines Angriffs über Schwachstellen ist, lässt sich nicht pauschal beantworten. Theoretisch können Angreifer über Sicherheitslücken auch Steuerungssysteme ausspionieren oder manipulieren. Allerdings müssen die Angreifer dazu erst einmal an die Steuerungsanlagen herankommen.

Siemens-Sprecher Simon dazu: "Um Schwachstellen für Angriffe in Industrie-Netzwerken ausnutzen zu können, muss man einen direkten Zugang haben. Solange die Systeme unter normalen Bedingungen in einem gesicherten Umfeld laufen, ist das für Angreifer von außen nicht möglich.“ Bis jetzt seien auch keine Angriffe via Profibus bekannt. Besondere Hürden dabei sind das spezifisch notwendige Know-how für die eher exotisch anmutenden Industrie-Feldbusse und deren fehlende IP- und Gateway-Möglichkeit. Zum Schutz des ethernetbasierten Kommunikationsnetzes Profinet gibt es vielfältige Verfahren und Komponenten, zum Beispiel die Ethernet-Security-Switches Scalance S von Siemens.