Die IT/OT-Grenze in einem Energieversorgungsunternehmen ist keine klare Trennlinie im Netzwerkdiagramm. Sie ist eine durchlässige Membran, durch die Daten in beide Richtungen fließen: COBOL-Batchprogramme generieren Sollwertkonfigurationsdateien für SPSen, RPG-Programme lesen SCADA-Historiendaten für Abrechnung und Meldewesen, Legacy-C-Bridges übersetzen Mainframe-Ausgaben in Formate für verteilte Steuerungssysteme, und JCL-Jobstreams planen und sequenzieren den Datenaustausch über die Grenze hinweg – zeitlich genau so, wie es für die Betriebsprozesse entscheidend ist. Die Software, die diesen Datenfluss steuert, ist weder rein IT noch rein OT. Sie ist das Bindeglied, das die Funktionsfähigkeit der Energieversorgungsunternehmen gewährleistet, und genau diese Codekategorie ist für Modernisierungsteams am wenigsten geeignet, wenn ein Transformationsprogramm beginnt.
Der Energiesektor durchläuft einen der bedeutendsten digitalen Transformationsprozesse seiner Geschichte. Mit der Modernisierung der Infrastruktur durch intelligente Stromnetze, vernetzte Umspannwerke, industrielle Steuerungssysteme (ICS) und fortschrittliche Automatisierung sind die OT-Netzwerke stärker denn je vernetzt. Diese Vernetzung beseitigt die bestehende Codeebene nicht, sondern macht sie umso wichtiger, da jeder neue Endpunkt im intelligenten Stromnetz und jede Cloud-Analyseplattform auf Datenfeeds angewiesen ist, die aus jahrzehntealten Anwendungen stammen. Die Modernisierung dieser Anwendungen ohne Berücksichtigung ihrer Rolle in der operativen Datenkette ist keine Modernisierung, sondern eine Störung mit Folgen, die weit über das Rechenzentrum hinaus bis in die physische Infrastruktur reichen.
Ermitteln Sie jeden fest codierten Betriebsparameter
SMART TS XL Findet alle EU-Konstanten, Alarmgrenzen und Protokolladressen, die in Ihrem bestehenden Codeportfolio eingebettet sind.
MEHR ERFAHREN…Was „SCADA-nah“ tatsächlich bedeutet
Der Begriff SCADA-nahe Software beschreibt IT-seitige Software, die mit betriebstechnischen Systemen interagiert. Dabei handelt es sich nicht um die SCADA-Software selbst, die SPS-Firmware oder den eingebetteten RTU-Code, sondern um die Geschäftsanwendungsschicht, die Daten in diese Systeme einspeist und von ihnen empfängt. Diese Kategorie ist umfangreich, wenig erforscht und unterscheidet sich grundlegend vom übrigen Portfolio an Unternehmensanwendungen.
In einer typischen Versorgungsumgebung umfasst SCADA-naher Code Folgendes:
Programme zur Berechnung von Soll- und Lastwerten. COBOL- und PL/I-Programme berechnen Lastsollwerte, Spannungsziele, Druckschwellenwerte und Betriebsgrenzen und liefern diese als Konfigurationsdateien oder direkte Datenfeeds an SCADA-Systeme. Diese Programme kodieren Anforderungen der gesetzlichen Konformität, technische Spezifikationen und physikalische Sicherheitsgrenzen. Eine fehlerhafte Berechnung führt nicht zu einem falschen Wert im Bericht, sondern zu einem falschen Betriebssollwert, auf den das Steuerungssystem reagiert.
Historian-Datenkonsumenten. RPG- und COBOL-Programme lesen Betriebsdaten aus SCADA-Historian-Datenbanken für Abrechnung, behördliche Berichterstattung und Leistungsanalyse. Diese Programme sind auf spezifische Datenformate, Zeitstempelkonventionen und Definitionen von technischen Einheiten angewiesen, die vom Historian erzeugt werden. Eine Formatänderung in der Historian-Ausgabe oder eine Änderung im IT-seitigen Konsumentenprogramm kann unbemerkt Abrechnungsberechnungen oder behördliche Meldungen verfälschen.
Protokollbrückenprogramme. Kundenspezifische C-Programme übersetzen zwischen Mainframe-Ausgabeformaten und den datei- oder netzwerkbasierten Schnittstellen von DCS- (Distributed Control System) und SCADA-Systemen. Diese Brücken implementieren spezifische Protokolle wie Modbus, DNP3, IEC 61850 und herstellerspezifische Formate und basieren auf fest codierten Annahmen bezüglich Nachrichtenstruktur, Byte-Reihenfolge und Timing, die in der Dokumentation nicht beschrieben sind.
Datenpfade zwischen Batch- und Echtzeitverarbeitung. JCL-Jobstreams planen und sequenzieren den Datenaustausch über die IT/OT-Grenze hinweg in festgelegten Zeitfenstern. Ein Batch-Lauf eines Versorgungsunternehmens über Nacht kann Konfigurationsdaten erzeugen, die dem SCADA-System vor Betriebsbeginn am Morgen zur Verfügung stehen müssen. Die zeitliche Abhängigkeit ergibt sich implizit aus der Scheduler-Konfiguration und den betrieblichen Erwartungen der Leitwarte, ist aber im Anwendungscode nicht dokumentiert.
Alarm- und Ereignisverarbeitungsprogramme. Diese Programme empfangen Alarmmeldungen von SCADA-Systemen, wenden Klassifizierungs- und Routing-Logik an, generieren Arbeitsaufträge und erstellen Berichte zur Einhaltung gesetzlicher Vorschriften. Die Alarmklassifizierungslogik, die festlegt, welche Ereignisse welche Berichte innerhalb welcher Fristen erfordern, ist häufig in Programmcode eingebettet, der im Laufe der Jahrzehnte regulatorische Änderungen durchlaufen hat.
Dieser Code steuert sowohl Ingenieure als auch IT-Entwickler, die ihn teilweise besitzen und von denen keiner ihn vollständig versteht. Wenn ein Modernisierungsprogramm fragt: „Was können wir ändern?“, lautet die Antwort für SCADA-nahen Code fast immer: „Weniger als Sie denken, und erst nach einer umfassenderen Analyse als geplant.“
Warum die Standard-Modernisierungsanalyse hier scheitert
Die meisten Analyseframeworks für die Modernisierung von Unternehmen gehen davon aus, dass der analysierte Code ausschließlich Daten und Geschäftslogik steuert und dass eine Programmänderung zu veränderten Daten ohne physische Auswirkungen führt. SCADA-naher Code verletzt diese Annahme in vier spezifischen Punkten.
Physikalische Folgen von Datenfehlern
In einer Standard-Abrechnungsanwendung führt eine fehlerhafte Berechnung zu einer falschen Rechnung. Der Fehler ist erkennbar, behebbar und in seinem Umfang begrenzt. In SCADA-nahen Systemen kann eine fehlerhafte Berechnung hingegen einen falschen Sollwert erzeugen – einen Zielwert, auf den ein Steuerungssystem durch Anpassung physikalischer Parameter wie Druck, Spannung, Durchflussrate und Temperatur reagiert. Die Folge ist nicht nur ein falscher Wert in einer Datenbank, sondern ein physikalischer Prozess, der außerhalb seiner vorgesehenen Parameter abläuft. Die Konsequenzen reichen von Ineffizienz über Anlagenschäden bis hin zu Sicherheitsvorfällen.
Diese Asymmetrie zwischen Datenfehler und physikalischer Konsequenz ist der Hauptgrund, warum SCADA-naher Code nicht mit derselben Risikotoleranz analysiert werden kann wie Standard-Business-Code. Eine Änderung, die aus Sicht der Erzeugung gültiger Ergebnisse „korrekt“ funktioniert, kann dennoch betrieblich fehlerhafte Ergebnisse liefern, die zwar innerhalb der zulässigen Grenzen des Datentyps liegen, syntaktisch korrekt sind, aber im jeweiligen Betriebskontext physikalisch falsch sind.
Zeitabhängigkeiten, die die statische Analyse nicht modellieren kann
IT-seitige Programme, die an SCADA-Systeme angrenzen, unterliegen häufig zeitlichen Beschränkungen, die zwar betrieblich relevant, aber für statische Analysetools nicht sichtbar sind. Ein Programm zur Generierung von Konfigurationsdaten muss abgeschlossen sein, bevor der Abfragezyklus des SCADA-Systems diese Daten erfasst. Ein Batch-Job zur Aggregation von Historian-Daten muss vor dem für die behördliche Berichterstattung erforderlichen Zeitstempel am Ende des Intervalls beendet sein. Ein Brückenprogramm zur Alarmweiterleitung muss Ereignisse innerhalb der in den Betriebsabläufen der Leitwarte festgelegten Reaktionszeit verarbeiten.
Diese zeitlichen Beschränkungen sind in den Betriebsabläufen des Versorgungsunternehmens, in der Scheduler-Konfiguration und im impliziten Verständnis der Entwickler, die die Programme geschrieben haben, verankert – nicht im Quellcode selbst. Statische Analysetools, die sich auf Codestruktur und Datenfluss konzentrieren, haben keinen Einblick in zeitliche Anforderungen, die außerhalb des Codes existieren.
Die praktische Konsequenz: Modernisierungsanalysen für SCADA-nahe Systeme müssen den zeitlichen Kontext jedes Programms im Geltungsbereich explizit dokumentieren. Dies erfordert neben der Codeanalyse auch betriebliches Wissen, Interviews mit Leitstandbedienern, die Prüfung von Fristen zur Einhaltung gesetzlicher Vorschriften und die Analyse von Abhängigkeiten zwischen Scheduler-Jobs.
Identifizierung von Sicherheitsfunktionen
Die Normen IEC 61511 (Funktionale Sicherheit für die Prozessindustrie) und IEC 61508 (Funktionale Sicherheit für elektrische/elektronische/programmierbare elektronische sicherheitsrelevante Systeme) definieren Zertifizierungsanforderungen für Software mit Sicherheitsfunktionen. Nach diesen Normen zertifizierter Code ist nicht einfach nur bestehender Code, der zur Verbesserung der Wartbarkeit refaktoriert werden kann. Die Zertifizierung bezieht sich auf spezifische Code-Artefakte, genauer gesagt auf die spezifische Version der Binärdatei, die von der Zertifizierungsstelle geprüft wurde. Änderungen am Code, selbst zur Behebung eines in einer Geschäftsanwendung unbedeutenden Qualitätsproblems, führen zum Verlust der Zertifizierung und erfordern eine erneute Zertifizierung, bevor der geänderte Code in einer Sicherheitsfunktion eingesetzt werden darf.
Viele Energieversorger nutzen SCADA-nahe Programme, die sicherheitsrelevante Berechnungen, Überdruckerkennung, Sollwertberechnungen für den Transformatorschutz und Notabschaltlogik durchführen. Diese Programme unterliegen möglicherweise Sicherheitszertifizierungsanforderungen, ohne dass das IT-Modernisierungsteam davon Kenntnis hat. Die erste analytische Frage für SCADA-nahen Code lautet: Erfüllt dieser Code eine Sicherheitsfunktion? Wenn ja, welche Funktionen, unter welcher Zertifizierung und welche Änderungen sind erforderlich?
Hardware- und Protokollkopplung
Protokollbrückenprogramme und eingebetteter Schnittstellencode sind direkt von der implementierten Hardware und den Protokollversionen abhängig. Ein Programm, das Modbus RTU mit spezifischen Funktionscodes, Registerzuordnungen und Timeout-Werten für ein bestimmtes RTU-Modell eines bestimmten Herstellers implementiert, implementiert nicht generisch Modbus, sondern nur diese spezifische Kombination – mit Annahmen, die für andere Konfigurationen möglicherweise nicht gelten.
Bei der Analyse dieses Codes im Hinblick auf eine Modernisierung zeigt sich, dass die Abhängigkeit nicht nur vom COBOL- oder C-Quellcode abhängt, sondern auch vom RTU-Gerätemodell, der Firmware-Version, der physischen Verkabelungstopologie und der Netzwerkkonfiguration. Änderungen an einer dieser Komponenten können die Schnittstelle beeinträchtigen, selbst wenn der Programmquellcode unverändert bleibt. Umgekehrt können Änderungen am Programmquellcode Schnittstellen beeinträchtigen, die scheinbar nicht zusammenhängen, da die Bridge entwickelt wurde, um herstellerspezifische Protokollbesonderheiten auszugleichen, die nirgends dokumentiert sind.
Die IT/OT-Grenze: Wo der Code seinen Platz hat.
Das Purdue-Modell (ISA-99 / IEC 62443) definiert die konzeptionelle Architektur von industriellen Steuerungssystemnetzwerken in fünf Ebenen, von physikalischen Prozessen auf Ebene 0 bis hin zu unternehmensweiten Geschäftssystemen auf Ebene 4. SCADA-naher Legacy-Code in Versorgungsunternehmen befindet sich typischerweise auf den Ebenen 3 und 4, den Fertigungsbetriebs- und Unternehmensnetzwerkzonen, aber seine Datenflüsse fließen in beide Richtungen in Ebene 2 (die SCADA-Überwachungsschicht).
Die Schnittstelle zwischen IT und OT (Level 3 und 2) birgt das höchste Sicherheits- und Betriebsrisiko. Staatliche Akteure positionieren sich Monate vor der Aktivierung in OT-Netzwerken, während Ransomware-Gruppen mittlerweile ICS-fähige Schadsoftware einsetzen, die HMIs blockiert und die Produktion lahmlegt. Der häufigste Angriffspunkt ist nicht die eingebettete SCADA-Software, sondern die IT/OT-Grenzschicht. Hier tauschen IT-seitiger Code und OT-seitige Systeme Daten über Schnittstellen aus, die für den zuverlässigen Betrieb und nicht für die Sicherheit vor Angriffen konzipiert wurden.
Das genaue Verständnis der Programme, die diese Schnittstelle überschreiten, und ihrer jeweiligen Funktionen ist Voraussetzung für die Modernisierungsplanung und die Verbesserung der Sicherheitslage. Ein Programm, das Daten aus einem SCADA-Historian liest und die Ergebnisse in eine Abrechnungsdatenbank schreibt, überschreitet die Grenze in der einen Richtung. Ein Programm, das Sollwerte berechnet und diese in ein Konfigurationsverzeichnis schreibt, das von einer SPS gelesen wird, überschreitet sie in der anderen Richtung. Beide Programme sind SCADA-nah. Sie erscheinen weder bei einem SCADA-Netzwerkscan noch bei einer IT-Anwendungsinventarisierung, weshalb sie systematisch unteranalysiert werden.
Codemuster speziell für SCADA-nahe Programme
Berechnungscode für technische Einheiten
Die Berechnung von technischen Einheiten (EU) wandelt Rohmesswerte von Sensoren, typischerweise ganzzahlige Zählwerte von Analog-Digital-Wandlern, in physikalische Messwerte mit spezifischen Einheiten, Bereichen und Genauigkeiten um. Ein 4-20-mA-Stromkreis eines Druckmessumformers liefert einen Rohmesswert; die EU-Berechnung wandelt diesen in PSI oder bar um und kalibriert ihn korrekt auf Null und Messbereich.
Dieser Berechnungscode weist Merkmale auf, die ihn von der Standard-Geschäftslogik unterscheiden:
Cobol
CALCULATE-PRESSURE-EU.
* RAW-COUNT ranges 0-4095 (12-bit ADC)
* SENSOR-ZERO-OFFSET = 819 (4mA = 20% of 4095)
* SENSOR-SPAN = 3276 (16mA span = 80% of 4095)
* RANGE-LOW-PSI = 0
* RANGE-HIGH-PSI = 500
COMPUTE EU-PRESSURE-PSI =
(RAW-COUNT - SENSOR-ZERO-OFFSET) /
SENSOR-SPAN *
(RANGE-HIGH-PSI - RANGE-LOW-PSI)
+ RANGE-LOW-PSI
IF EU-PRESSURE-PSI < RANGE-LOW-PSI OR
EU-PRESSURE-PSI > RANGE-HIGH-PSI
MOVE 'RANGE-VIOLATION' TO ALARM-STATUS
PERFORM GENERATE-ALARM
END-IF.Die Konstanten in dieser Berechnung, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSIDiese Werte entsprechen den Spezifikationen des physikalischen Messgeräts. Sind sie fest im Code verankert (wie es häufig in älterem Code der Fall ist), erfordert eine Änderung am physikalischen Messgerät eine Codeänderung. Sind sie fehlerhaft (beispielsweise aufgrund von Neukalibrierung, Austausch oder ursprünglicher Fehlkonfiguration des Messgeräts), ist der EU-Wert für jeden Datensatz, den das Programm jemals erzeugt hat, systematisch falsch. Eine statische Analyse kann die Definitionen dieser Konstanten ermitteln; nur eine operative Validierung kann bestätigen, ob sie für die aktuelle Messgerätekonfiguration korrekt sind.
Alarmgenerierungs- und Klassifizierungslogik
Der Code zur Alarmgenerierung zählt in Versorgungsunternehmen zu den regulatorisch anspruchsvollsten SCADA-nahen Codeabschnitten. Die NERC-CIP-Standards (Critical Infrastructure Protection) für Elektrizitätsversorgungsunternehmen, die NRC-Anforderungen für Kernkraftwerke und die EPA-Meldepflichten für Wasser- und Abwasserversorger legen genau fest, welche Ereignisse Alarme auslösen müssen, welche Informationen diese Alarme enthalten müssen und innerhalb welcher Fristen sie gemeldet werden müssen.
Cobol
CLASSIFY-ALARM.
EVALUATE TRUE
WHEN EU-PRESSURE-PSI > HIGH-HIGH-LIMIT
MOVE 'HH' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
WHEN EU-PRESSURE-PSI > HIGH-LIMIT
MOVE 'HI' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LIMIT
MOVE 'LO' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LOW-LIMIT
MOVE 'LL' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
END-EVALUATE.Die Alarmgrenzen in diesem Code, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMITEs handelt sich um Betriebsparameter mit regulatorischer Bedeutung. Änderungen dieser Grenzwerte wirken sich sowohl auf das Betriebsverhalten des Steuerungssystems als auch auf die Meldepflichten des Energieversorgungsunternehmens aus. Jedes Modernisierungsprogramm, das den Alarmklassifizierungscode betrifft, muss im Rahmen des Änderungsmanagementprozesses eine Prüfung durch die Regulierungsabteilung durchlaufen und darf nicht nur von der Technikabteilung freigegeben werden.
Protokollbrückenimplementierungen
Programme zur Anbindung älterer Protokolle gehören zu den am schwierigsten zu modernisierenden SCADA-nahen Codeabschnitten, da ihre Abhängigkeiten am schwersten zu ermitteln sind. Das Programm implementiert eine spezifische Protokollversion für ein bestimmtes Gerät, wobei undokumentierte, herstellerspezifische Verhaltensweisen im Code berücksichtigt werden.
c
/* Legacy Modbus RTU bridge -- written for Modicon 984 PLCs, circa 1998 */
/* NOTE: 984 series uses 1-based register addressing, not 0-based */
/* Function code 03 only -- 984 does not support FC 04 */
/* Max 60 registers per request -- 984 firmware limitation */
#define MODBUS_FC03_READ_HOLDING 0x03
#define MAX_REGS_PER_REQUEST 60 /* 984 firmware limit, not Modbus spec */
#define REGISTER_OFFSET 1 /* 984 uses 1-based addressing */
int read_holding_registers(int start_reg, int count, uint16_t *buffer) {
/* Compensate for 984 1-based addressing */
uint16_t adjusted_start = (uint16_t)(start_reg + REGISTER_OFFSET);
if (count > MAX_REGS_PER_REQUEST) {
/* 984 will return error if count exceeds 60 */
/* Split into multiple requests silently */
return read_registers_chunked(adjusted_start, count, buffer);
}
/* ... */
}Dieser Code basiert auf vier Annahmen bezüglich eines bestimmten SPS-Modells, die nicht Teil der Modbus-Spezifikation sind: 1-basierte Registeradressierung, ausschließlich Funktionscode 03, maximal 60 Register und das Chunking-Verhalten bei größeren Anfragen. Keine dieser Annahmen ist in der Modbus-Dokumentation aufgeführt. Es handelt sich um herstellerspezifische Verhaltensweisen der Modicon 984, die in einem Hardware-Handbuch von 1998 dokumentiert sind, das möglicherweise nicht mehr verfügbar ist. Wird diese Schnittstelle modernisiert, ohne diese Annahmen zu berücksichtigen, oder wird die SPS durch ein neueres Modell mit standardmäßiger 0-basierter Adressierung ersetzt, liefert jeder Registerlesevorgang einen um genau eine Registeradresse verschobenen, falschen Wert.
Die Analyse vor der Modernisierung: Was muss produziert werden?
Bevor SCADA-naher Code geändert, umstrukturiert oder ersetzt wird, muss die Analyse eine Reihe von Ergebnissen liefern, die über das hinausgehen, was eine Standardanalyse zur Modernisierung von Unternehmen bietet.
Funktionsinventar. Jedes SCADA-nahe Programm muss nach seiner Funktion klassifiziert werden: EU-Berechnung, Sollwertbereitstellung, Verarbeitung historischer Daten, Alarmgenerierung, Protokollbrücke, Batch-zu-Echtzeit-Verarbeitung. Diese Klassifizierung legt fest, wer in den Änderungsprozess einbezogen werden muss: nur IT-Ingenieure oder ein funktionsübergreifendes Team mit Steuerungstechnikern, Betriebspersonal und Experten für die Einhaltung gesetzlicher Vorschriften.
Datenflussdiagramm für die Schnittstelle zwischen IT und OT. Jeder Datenfluss, der die IT/OT-Grenze überschreitet, muss dokumentiert werden: Welches Programm erzeugt die Daten, in welchem Format und zu welchem Zeitpunkt? Welches OT-System verarbeitet sie? Und welche Konsequenzen ergeben sich, wenn die Daten fehlerhaft, verspätet oder nicht vorhanden sind? Dieses Diagramm stellt das operationelle Risikoprofil für die SCADA-angrenzende Schicht dar.
Identifizierung von Sicherheitsfunktionen. Jedes Programm muss daraufhin geprüft werden, ob es eine Sicherheitsfunktion gemäß IEC 61511, IEC 61508, NERC CIP oder anderen anwendbaren Normen erfüllt. Programme, die als Sicherheitsfunktionscode identifiziert wurden, erfordern ein separates Änderungsmanagement, eine behördliche Benachrichtigung und gegebenenfalls eine Rezertifizierung. Der Modernisierungsplan für diese Programme unterscheidet sich grundlegend von dem für Standard-Geschäftscode.
Register fest codierter Betriebsparameter. Jede fest codierte Konstante, die einen Betriebsparameter, Sensorkalibrierungswerte, Alarmgrenzen, Protokollbeschränkungen oder Zeitschwellenwerte repräsentiert, muss identifiziert, mit ihrer betrieblichen Bedeutung dokumentiert und anhand der aktuellen Gerätespezifikationen validiert werden. Dieses Register dient als Grundlage für den Konfigurationsmanagementprozess, der fest codierte Konstanten durch extern verwaltete Konfigurationen ersetzt.
Dokumentation der Zeitabhängigkeiten. Der Zeitkontext jedes Programms, die Zeitfenster, in denen es abgeschlossen sein muss, die Scheduler-Abhängigkeiten, die diese Zeitfenster erzwingen, und die von seinem Abschluss abhängigen Abläufe müssen explizit dokumentiert werden. Diese Dokumentation ist die Spezifikation, anhand derer die modernisierte Implementierung validiert werden muss.
Protokoll- und Schnittstellenspezifikation. Jedes Protokollbrückenprogramm muss hinsichtlich herstellerspezifischer Verhaltensweisen, Annahmen zur Protokollversion und gerätespezifischer Kompensationen analysiert werden. Das Ergebnis ist ein Spezifikationsdokument, mit dem eine Ersatzimplementierung validiert werden kann. Es bestätigt, dass alle kompensierenden Verhaltensweisen erhalten bleiben, auch jene, die nicht in der ursprünglichen Spezifikation enthalten waren.
Die Modernisierungsansätze, die funktionieren und die, die nicht funktionieren
Das Strangler-Fig-Muster , sorgfältig angewendet, besteht darin, neue Funktionalitäten parallel zu den bestehenden aufzubauen, schrittweise zu implementieren und schrittweise außer Betrieb zu nehmen. Es eignet sich für SCADA-nahen Code, der IT-seitige Datenverarbeitung durchführt (z. B. historische Datenabfragen, Abrechnungsberechnungen). Das alte Programm läuft während der Übergangsphase weiter; die neue Implementierung erzeugt parallele Ausgaben, die auf Äquivalenz geprüft werden, bevor das alte Programm außer Betrieb genommen wird.
Das Strangler-Fig-Prinzip gilt nicht für Echtzeitpfade. Bei Programmen, die in einem Echtzeit-Datenpfad laufen und bei denen eine sichere Parallelführung von alten und neuen Programmen aufgrund der zu widersprüchlichen Betriebseffekten nicht möglich ist, muss der Übergang unmittelbar erfolgen und vor der Produktionsumstellung offline validiert werden. Die Ausführung eines parallelen Sollwertberechnungsprogramms, das andere Werte als das aktuelle Programm liefert, würde zu widersprüchlichen Sollwerten an das Steuerungssystem führen.
Konfigurationsauslagerung vor Codeänderungen. Bei Programmen mit fest codierten Betriebsparametern ist der sicherste erste Modernisierungsschritt die Auslagerung dieser Parameter in eine Konfigurationsdatei oder Datenbank, ohne die Berechnungslogik zu ändern. Dadurch werden die Parameter sichtbar, verwaltbar und überprüfbar, ohne den für die operative Funktion relevanten Berechnungscode anzutasten. Das Risiko der Parameterauslagerung ist deutlich geringer als das Risiko einer Refaktorisierung der Berechnungslogik.
Sicherheitsfunktionscode: Analyse und Dokumentation, nicht Refactoring. Sicherheitszertifizierter Code sollte in der Modernisierungsplanungsphase analysiert und dokumentiert werden. Änderungen daran sollten jedoch einem separaten Rezertifizierungsprogramm mit Abstimmung mit den Aufsichtsbehörden vorbehalten bleiben und nicht Teil einer allgemeinen Modernisierungsinitiative sein. Das Risiko, eine Sicherheitszertifizierung im Zuge einer umfassenden Modernisierung zu verlieren, ist durch keinen der üblichen Modernisierungsvorteile gerechtfertigt.
Wie SMART TS XL Unterstützt die Analyse von SCADA-nahen Legacy-Codes
SMART TS XL statische Code-Analyse Dies gilt für die IT-Seite der SCADA-angrenzenden Schnittstelle, die COBOL-, JCL-, RPG-, PL/I- und C-Programme, die auf Großrechnern und Midrange-Systemen laufen und Daten generieren, transformieren oder verarbeiten, die in OT-Umgebungen gelangen. Für diesen Code erstellt die Strukturanalyse das für die Vormodernisierungsanalyse erforderliche Inventar der Betriebsfunktionen und das Register der fest codierten Parameter.
Die Abbildung der Anwendungsabhängigkeiten erstellt die Schnittstelle zwischen IT und OT: Sie erfasst jedes Programm, das auf eine von einem SCADA-System genutzte Dateischnittstelle schreibt, jeden JCL-Jobschritt, der zeitrelevante Daten erzeugt, und jedes Programm im Datenpfad des Historian vom OT-Quellsystem zum IT-Verbraucher. Wenn das COBOL-Abrechnungsprogramm eines Energieversorgers Historian-Daten über eine zwischengeschaltete C-Schnittstelle liest, stellt die Abhängigkeitsabbildung sowohl die COBOL-zu-C-Abhängigkeit als auch die C-zu-Historian-Abhängigkeit als zusammenhängende Kette dar. Dadurch wird die gesamte Schnittstelle zwischen IT und OT sichtbar und nicht erst durch operative Vorfälle erkennbar.
Die Auswirkungsanalyse ist besonders wichtig für SCADA-nahen Code, da sie den potenziellen Wirkungsradius jeder geplanten Änderung vor deren Umsetzung ermittelt. Eine Änderung an einem EU-Berechnungsprogramm, das (über ein Copybook) mit Code zur Alarmgenerierung, Sollwertbereitstellung und Historian-Schreiben gemeinsam genutzt wird, erfordert das Verständnis aller drei sekundären Auswirkungen, bevor die Berechnung angepasst wird. In herkömmlichem Geschäftscode führt eine fehlerhafte Änderung zu falschen Daten. In SCADA-nahem Code führt sie zu falschen Betriebsparametern.
Die JCL-Erweiterungsfunktion legt die zeitliche und sequenzielle Struktur der Batch-Schicht offen: welche Jobs in welcher Reihenfolge ausgeführt werden, welche Datensatzausgaben welche nachfolgenden Schritte speisen und welche Jobströme durch betriebliche Anforderungen zeitlich begrenzt sind. Dies bildet die strukturelle Grundlage für die Dokumentation der zeitlichen Abhängigkeiten, die für die Modernisierung von SCADA-nahen Systemen erforderlich ist.
Die unternehmensweite Suchfunktion ermöglicht die großflächige Verwaltung fest codierter Parameter: Innerhalb von Sekunden findet sich jede Instanz einer bestimmten technischen Konstante, jeder Alarmgrenzwert und jede fest codierte Protokolladresse in allen COBOL-, C-, RPG- und JCL-Artefakten der Umgebung – und das über Millionen von Codezeilen hinweg. Für Energieversorger, die Hunderttausende Zeilen SCADA-nahen Legacy-Code verwalten, bedeutet diese Suchfunktion den entscheidenden Unterschied zwischen einer monatelangen manuellen Prüfung und einer automatisierten Bestandsaufnahme in nur wenigen Stunden.
Für Teams, die planen Modernisierung des Altbestands von Versorgungssystemen SMART TS XL Die IT-seitige Strukturanalyse ermöglicht es dem Modernisierungsteam, effektiv mit den OT-seitigen Steuerungstechnikern zusammenzuarbeiten, die den Betriebskontext verstehen. Die Grenze zwischen IT und OT kann nicht sicher von IT-Teams allein oder von OT-Teams allein überschritten werden, sondern nur dann, wenn beide Seiten über präzise Kenntnisse der Struktur ihrer Systeme verfügen.
Warum dieser Code eine andere Art von Aufmerksamkeit erfordert
Energieversorger, die ihre SCADA-nahen Legacy-Systeme modernisieren, aktualisieren nicht einfach nur alte Software. Sie verändern die Softwareschicht, die zwischen Geschäftssystemen und physischer Infrastruktur vermittelt. Die Folgen von Fehlern beschränken sich nicht auf Datenfehler, Serviceausfälle oder finanzielle Verluste, sondern betreffen auch die physischen Systeme, die die Menschen versorgen, die auf die Energieversorgung angewiesen sind.
Die besonderen Merkmale dieses Codes – die physikalischen Folgen von Datenfehlern, die für die statische Analyse unsichtbaren Timing-Abhängigkeiten, die Anforderungen der Sicherheitszertifizierung sowie die Hardware- und Protokollkopplung – sprechen nicht gegen eine Modernisierung. Vielmehr plädieren sie dafür, den Code vollständig zu verstehen, bevor Änderungen vorgenommen werden. Das Analyseframework in diesem Leitfaden ermöglicht dieses Verständnis. Das daraus resultierende Modernisierungsprogramm ist sicherer, da der Umfang der Änderungen durch Fakten und nicht durch Annahmen definiert wird, die Timing-Abhängigkeiten dokumentiert und nicht implizit sind, der Code für Sicherheitsfunktionen identifiziert und nicht versehentlich modifiziert wird und die Schnittstellen zwischen IT und OT erfasst und nicht erst durch Betriebsstörungen nach der Implementierung entdeckt werden.
