IT/OT-gränsen i en allmännyttig organisation är inte en tydlig linje i ett nätverksdiagram. Det är ett permeabelt membran genom vilket data flödar i båda riktningarna, COBOL-batchprogram som genererar börvärdeskonfigurationsfiler som konsumeras av PLC:er, RPG-program som läser SCADA-historikdata för fakturering och rapportering, äldre C-bryggor som översätter stordatorutdata till format som distribuerade styrsystem förstår, JCL-jobbströmmar som schemalägger och sekvenserar datautbyten över gränsen enligt den tidpunkt som operativa processer är beroende av. Programvaran som hanterar detta flöde är varken ren IT eller ren OT. Det är den bindväv som får allmännyttiga tjänster att fungera, och det är den kodkategori som moderniseringsteam är minst förberedda att analysera när ett transformationsprogram börjar.
Energisektorn genomgår en av de mest betydande digitala transformationerna i sin historia. I takt med att energibolag moderniserar sin infrastruktur med smarta nät, uppkopplade transformatorstationer, ICS och avancerad automation, har OT-nätverk blivit mer sammankopplade än någonsin tidigare. Denna sammankoppling eliminerar inte det äldre kodlagret, den gör det mer kritiskt, eftersom varje ny smart grid-slutpunkt och molnanalysplattform är beroende av dataflöden som kommer från applikationer som skrevs för årtionden sedan. Att modernisera dessa applikationer utan att förstå deras roll i den operativa datakedjan är inte en modernisering, det är en störning med konsekvenser som sträcker sig bortom datacentret till den fysiska infrastrukturen.
Hitta alla hårdkodade operationella parametrar
SMART TS XL lokaliserar varje EU-konstant, larmgräns och protokolladress som är inbäddad i din äldre kodportfölj.
TA REDA PÅ MER…Vad "SCADA-angränsande" egentligen betyder
Termen SCADA-ansluten beskriver IT-programvara som samverkar med operativa tekniksystem, inte själva SCADA-programvaran, inte PLC-firmwaren, inte den inbäddade RTU-koden, utan det affärsapplikationslager som matar data till och tar emot data från dessa system. Denna kategori är stor, underanalyserad och genuint annorlunda än resten av portföljen för företagsapplikationer.
I en typisk verktygsmiljö inkluderar SCADA-angränsande kod:
Program för beräkning av hastighet och börvärde. COBOL- och PL/I-program som beräknar lastbörvärden, spänningsmål, trycktrösklar och driftsgränser som levereras till SCADA-system som konfigurationsfiler eller direkta dataflöden. Dessa program kodar för regelefterlevnadskrav, tekniska specifikationer och fysiska säkerhetsgränser. En felaktig beräkning producerar inte ett felaktigt tal i en rapport, den producerar ett felaktigt driftsbörvärde som ett styrsystem agerar utifrån.
Historikerdatakonsumenter. RPG- och COBOL-program som läser driftsdata från SCADA-historikdatabaser för fakturering, regulatorisk rapportering och prestandaanalys. Dessa program är beroende av specifika dataformat, tidsstämpelkonventioner och definitioner av tekniska enheter som historikern producerar. En formatändring i historikerns utdata, eller en ändring i IT-sidans konsumentprogram, kan i det tysta korrumpera faktureringsberäkningar eller regulatoriska inlämningar.
Protokollbryggprogram. Anpassade C-program som översätter mellan stordatorformat och de filbaserade eller nätverksbaserade gränssnitt som DCS (Distributed Control System) och SCADA-system använder. Dessa bryggor implementerar specifika protokoll, Modbus, DNP3, IEC 61850, proprietära leverantörsformat och har hårdkodade antaganden om meddelandestruktur, byteordning och timing som inte finns någonstans i dokumentationen.
Batch-till-realtidsdatavägar. JCL-jobbströmmar som schemalägger och sekvenserar datautbyten över IT/OT-gränsen inom specifika tidsfönster. Ett verktygs batchkörning över natten kan producera konfigurationsdata som måste vara tillgänglig för SCADA-systemet innan morgondriften börjar. Tidsberoendet är implicit i schemaläggarkonfigurationen och kontrollrummets operativa förväntningar, inte dokumenterat någonstans i applikationskoden.
Larm- och händelsebehandlingsprogram. Program som tar emot larmposter från SCADA-system, tillämpar klassificerings- och routinglogik, genererar arbetsordrar och producerar register över regelefterlevnad. Larmklassificeringslogiken, vilka händelser som kräver vilka regelrapporter, inom vilka tidsramar, är ofta inbäddad i programkod som har samlat på sig årtionden av regeländringar.
Det här är koden som ingenjörer och IT-utvecklare båda delvis äger och ingen av dem helt förstår. När ett moderniseringsprogram frågar "vad kan vi ändra?" är svaret för SCADA-angränsande kod nästan alltid "mindre än du tror, och först efter mer analys än du planerat".
Varför standardmoderniseringsanalys misslyckas här
De flesta ramverk för modernisering av företagsmodeller antar att den kod som analyseras endast kontrollerar data och affärslogik, och att en ändring i ett program producerar ett annat dataresultat utan några konsekvenser för den fysiska världen. SCADA-angränsande kod bryter mot detta antagande på fyra specifika sätt.
Fysiska konsekvenser av datafel
I en vanlig faktureringsapplikation producerar en felaktig beräkning en felaktig faktura. Felet är upptäckbart, reversibelt och har begränsad omfattning. I SCADA-ansluten kod kan en felaktig beräkning producera ett felaktigt börvärde, ett målvärde som ett styrsystem agerar på genom att justera fysiska parametrar: tryck, spänning, flödeshastighet, temperatur. Konsekvensen är inte ett felaktigt tal i en databas. Det är en fysisk process som körs utanför sina avsedda parametrar, med konsekvenser som sträcker sig från ineffektivitet till utrustningsskador och säkerhetsincidenter.
Denna asymmetri mellan datafel och fysiska konsekvenser är den grundläggande anledningen till att SCADA-angränsande kod inte kan analyseras med samma risktolerans som vanlig affärskod. En förändring som "fungerar korrekt" ur perspektivet att producera giltig utdata kan fortfarande producera operativt felaktig utdata, inom datatypens lagliga intervall, syntaktiskt giltig, men fysiskt felaktig för det operativa sammanhang den representerar.
Tidsberoenden som statisk analys inte kan modellera
IT-program intill SCADA-system har ofta tidsbegränsningar som är operativt signifikanta men osynliga för statiska analysverktyg. Ett program som genererar konfigurationsdata måste slutföras innan SCADA-systemets pollingcykel läser den. Ett batchjobb som aggregerar historikdata måste slutföras före den tidsstämpel vid intervallets slut som den regulatoriska rapporteringen kräver. Ett bryggprogram som vidarebefordrar larm måste bearbeta händelser inom den svarstid som kontrollrummets operativa procedurer anger.
Dessa tidsbegränsningar finns i verktygets operativa procedurer, i schemaläggningskonfigurationen och i den implicita förståelsen hos utvecklarna som skrev programmen, inte i källkoden. Statiska analysverktyg som fokuserar på kodstruktur och dataflöde har ingen insyn i tidskrav som finns utanför själva koden.
Den praktiska implikationen: moderniseringsanalys för SCADA-ansluten kod måste explicit dokumentera tidskontexten för varje program inom ramen. Detta kräver operativ kunskap, intervjuer med kontrollrumsoperatörer, granskning av regelefterlevnadsscheman, analys av beroenden för schemaläggarjobb, inte bara kodanalys.
Identifiering av säkerhetsfunktioner
IEC 61511 (funktionell säkerhet för processindustrisektorer) och IEC 61508 (funktionell säkerhet för elektriska/elektroniska/programmerbara elektroniska säkerhetsrelaterade system) definierar certifieringskrav för programvara som utför säkerhetsfunktioner. Kod som har certifierats enligt dessa standarder är inte bara äldre kod som kan omstruktureras för underhållbarhet. Certifieringen avser specifika kodartefakter, den specifika versionen av den specifika binärfil som certifieringsorganet utvärderat. Att ändra koden, även för att åtgärda ett kvalitetsproblem som skulle vara anmärkningsvärt i en affärsapplikation, ogiltigförklarar certifieringen och kräver omcertifiering innan den ändrade koden kan distribueras i en säkerhetsfunktion.
Många energibolag har SCADA-anslutna program som utför säkerhetsrelaterade beräkningar, övertrycksdetektering, beräkning av börvärden för transformatorskydd och logik för nödavstängning, vilket kan omfattas av säkerhetscertifieringskrav utan att IT-moderniseringsteamet vet om det. Den första analytiska frågan för SCADA-ansluten kod är: utför någon av dessa koder en säkerhetsfunktion? Om ja, vilka funktioner, under vilken certifiering och vad krävs för att ändra den?
Hårdvaru- och protokollkoppling
Protokollbryggprogram och inbäddad gränssnittskod har direkta beroenden av de hårdvaru- och protokollversioner de implementerar. Ett program som implementerar Modbus RTU med specifika funktionskoder, registermappningar och timeout-värden för en specifik modell av RTU från en specifik leverantör implementerar inte generellt Modbus, det implementerar den specifika kombinationen, med antaganden som kanske inte gäller för någon annan konfiguration.
När denna kod analyseras för modernisering är beroendet inte bara på COBOL- eller C-källan, utan på RTU-enhetens modell, firmwareversionen, den fysiska kabeltopologin och nätverkskonfigurationen. Ändringar i någon av dessa kan förstöra gränssnittet även om programmets källkod är oförändrad. Och ändringar i programmets källkod kan förstöra gränssnitt som verkar orelaterade eftersom bryggan skrevs för att kompensera för leverantörsspecifika protokollegendomligheter som inte dokumenteras någonstans.
IT/OT-gränsen: Där koden finns
Purdue-modellen (ISA-99 / IEC 62443) definierar den konceptuella arkitekturen för industriella styrsystemnätverk i fem nivåer, från fysiska processer på nivå 0 till företagssystem på nivå 4. SCADA-angränsande äldre kod i verktygsmiljöer finns vanligtvis på nivå 3 och 4, tillverkningsoperationerna och företagsnätverkszonerna, men dess dataflöden korsar nivå 2 (SCADA-övervakningslagret) i båda riktningarna.
IT/OT-gränsen mellan nivå 3 och 2 är där säkerhets- och operativa risker är som högst. Nationella aktörer förbereder sig inuti OT-nätverk månader före aktivering, medan ransomware-grupper nu distribuerar ICS-medvetna nyttolaster som är konstruerade för att låsa HMI och stoppa produktionen. Den vanligaste ingångspunkten är inte den inbyggda SCADA-programvaran, utan IT/OT-gränsskiktet, där IT-kod och OT-system utbyter data via gränssnitt som utformats för driftssäkerhet snarare än fiendtlig säkerhet.
Att förstå exakt vilken uppsättning program som korsar denna gräns, och vad de gör där, är en förutsättning för både moderniseringsplanering och förbättring av säkerhetsställningen. Ett program som läser från en SCADA-historik och skriver resultat till en faktureringsdatabas korsar gränsen i en riktning. Ett program som beräknar börvärden och skriver dem till en konfigurationskatalog som en PLC läser korsar den i den andra. Båda är SCADA-anslutna. Ingen av dem visas i en SCADA-nätverksskanning eller en IT-applikationsinventering, vilket är anledningen till att de systematiskt underanalyseras.
Kodmönster specifika för SCADA-angränsande program
Kod för beräkning av teknisk enhet
EU-beräkningar (Ingeniöra enheter) konverterar råa sensorvärden, vanligtvis heltal från analog-till-digital-omvandlare, till fysiska mätningar med specifika enheter, intervall och precision. En 4–20 mA strömslinga från en trycktransmitter producerar ett råvärde; EU-beräkningen konverterar det till PSI eller bar med korrekt noll- och spannkalibrering.
Denna beräkningskod har egenskaper som skiljer den från vanlig affärslogik:
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.Konstanterna i denna beräkning, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSI, motsvarar specifikationerna för fysiska instrument. Om de är hårdkodade (som de ofta är i äldre kod) kräver en ändring av det fysiska instrumentet en kodändring. Om de är felaktiga (på grund av omkalibrering, utbyte eller felkonfiguration av instrumentet) är EU-värdet systematiskt felaktigt för varje post som programmet någonsin har producerat. Statisk analys kan hitta var dessa konstanter är definierade; endast operationell validering kan bekräfta om de är korrekta för den aktuella instrumentkonfigurationen.
Larmgenerering och klassificeringslogik
Larmgenereringskod är bland de mest regelkänsliga SCADA-anslutna koderna i elmiljöer. NERC CIP-standarder (Critical Infrastructure Protection) för elbolag, NRC-krav för kärnkraftsanläggningar och EPA-rapporteringskrav för vatten- och avloppsvattenbolag specificerar alla vilka händelser som måste generera larm, vilken information dessa larm måste innehålla och inom vilka tidsramar de måste rapporteras.
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.Larmgränserna i denna kod, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMIT, är driftsparametrar av regulatorisk betydelse. Ändringar av dessa gränser påverkar både styrsystemets driftsbeteende och bolagets rapporteringsskyldigheter. Alla moderniseringsprogram som berör larmklassificeringskoder måste ha granskning av regulatoriska frågor i sin ändringskontrollprocess, inte bara teknisk godkännande.
Implementeringar av protokollbryggor
Äldre protokollbryggprogram är bland den svåraste SCADA-anslutna koden att modernisera eftersom deras beroenden är de svåraste att räkna upp. Programmet implementerar en specifik protokollversion för en specifik enhet, med odokumenterade leverantörsspecifika beteenden kompenserade i koden.
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);
}
/* ... */
}Denna kod har fyra inbäddade antaganden om en specifik PLC-modell som inte ingår i Modbus-specifikationen: 1-baserad registeradressering, endast funktionskod 03, maximalt 60 register och chunking-beteendet för större förfrågningar. Inget av dessa förekommer i Modbus-dokumentationen. De är leverantörsspecifika beteenden för Modicon 984, dokumenterade i en hårdvarumanual från 1998 som kanske inte längre är tillgänglig. Om denna brygga moderniseras utan att man förstår dessa antaganden, eller om PLC:n ersätts med en nyare modell som använder standard 0-baserad adressering, returnerar varje registerläsning fel värde med exakt en registeradressförskjutning.
Analysen före moderniseringen: Vad som måste produceras
Innan någon SCADA-anslutande kod modifieras, omstruktureras eller ersätts måste analysen producera en uppsättning leveranser som går utöver vad standardanalys av företagsmodernisering tillhandahåller.
Inventering av operativa funktioner. Varje SCADA-anslutet program måste klassificeras efter sin operativa funktion: EU-beräkning, leverans av börvärde, konsument av historikdata, larmgenerering, protokollbrygga, batch-till-realtidsväg. Denna klassificering avgör vem som måste vara involverad i förändringsprocessen, enbart IT-ingenjörer eller ett tvärfunktionellt team som inkluderar styrtekniker, driftspersonal och regelefterlevnadspersonal.
Karta över IT/OT-gränsövergångar. Varje dataflöde som korsar IT/OT-gränsen måste dokumenteras: vilket program som producerar data, i vilket format, enligt vilket schema; vilket OT-system som förbrukar dem; och vad konsekvensen blir om data är felaktiga, försenade eller saknas. Denna karta är den operativa riskprofilen för det SCADA-angränsande lagret.
Identifiering av säkerhetsfunktioner. Varje program måste utvärderas med avseende på om det utför en säkerhetsfunktion enligt IEC 61511, IEC 61508, NERC CIP eller andra tillämpliga standarder. Program som identifieras som säkerhetsfunktionskod kräver separat ändringskontroll, myndighetsmeddelanden och eventuellt omcertifiering. Moderniseringstidslinjen för dessa program skiljer sig fundamentalt från standard affärskod.
Hårdkodat register över driftsparametrar. Varje hårdkodad konstant som representerar en driftsparameter, sensorkalibreringsvärden, larmgränser, protokollbegränsningar, tidsgränser måste identifieras, dokumenteras med sin operativa betydelse och valideras mot aktuella instrumentspecifikationer. Detta register blir indata till konfigurationshanteringsprocessen som ersätter hårdkodade konstanter med externt hanterad konfiguration.
Dokumentation av tidsberoenden. Varje programs tidskontext, de operativa fönster inom vilka det måste slutföras, schemaläggningsberoendena som framtvingar dessa fönster, de operativa procedurer som är beroende av dess slutförande, måste dokumenteras explicit. Denna dokumentation är den specifikation mot vilken den moderniserade implementeringen måste valideras.
Protokoll- och gränssnittsspecifikation. Varje protokollbryggprogram måste analyseras med avseende på leverantörsspecifika beteenden, antaganden om protokollversioner och enhetsspecifika kompensationer. Utdata är ett specifikationsdokument som kan användas för att validera en ersättningsimplementering, vilket bekräftar att alla kompenserande beteenden bevaras, även de som inte fanns i den ursprungliga specifikationen.
Moderniseringsmetoderna som fungerar och de som inte gör det
Strangler Fig, tillämpad noggrant. Strangler Fig-mönstret, som bygger ny funktionalitet vid sidan av den gamla, routar stegvis och avvecklar gradvis, är lämpligt för SCADA-ansluten kod som utför IT-databehandling (historikdatakonsumenter, faktureringsberäkningar). Det gamla programmet fortsätter att köras under övergången; den nya implementeringen producerar parallella utdata som valideras för ekvivalens innan det gamla programmet tas ur bruk.
Strangler-figuren gäller inte realtidsbanor. För program som sitter i en realtidsdatabana, där det inte finns något säkert sätt att köra gamla och nya parallellt eftersom de skulle producera motstridiga driftseffekter, måste övergången ske omedelbar och valideras offline innan någon produktionsövergång. Att köra ett parallellt börvärdesberäkningsprogram som producerar andra värden än det aktuella programmet skulle skicka motstridiga börvärden till styrsystemet.
Konfigurationsexternalisering före kodändringar. För program med hårdkodade driftsparametrar är det säkraste första moderniseringssteget att externalisera dessa parametrar till en konfigurationsfil eller databas utan att ändra beräkningslogiken. Detta gör parametrarna synliga, hanterbara och granskbara utan att vidröra beräkningskoden som har driftsmässig betydelse. Risken att externalisera parametrar är betydligt lägre än att omstrukturera beräkningslogiken.
Säkerhetsfunktionskod: analys och dokumentation, inte omstrukturering. Säkerhetscertifierad kod bör analyseras och dokumenteras under moderniseringsplaneringsfasen, men ändringar i den bör skjutas upp till ett avsiktligt omcertifieringsprogram med myndighetssamordning, och inte hanteras som en del av ett generellt moderniseringsinitiativ. Risken att ogiltigförklara ett säkerhetsintyg under ett brett moderniseringsprojekt motiveras inte av någon typisk moderniseringsfördel.
Hur SMART TS XL Stöder SCADA-angränsande äldre kodanalys
SMART TS XLÄr statisk kodanalys gäller IT-sidan av SCADA-angränsande gräns, COBOL-, JCL-, RPG-, PL/I- och C-programmen som körs på stordatorer och mellanregister och genererar, transformerar eller konsumerar data som passerar in i OT-miljöer. För denna kod producerar strukturell analys den operativa funktionsinventering och det hårdkodade parameterregister som förmoderniseringsanalysen kräver.
Mappningen av applikationsberoenden bygger IT/OT-gränsövergångskartan: varje program som skriver till ett filgränssnitt som konsumeras av ett SCADA-system, varje JCL-jobbsteg som producerar data med operativ tidsbetydelse, varje program i historikdatavägen från OT-källa till IT-konsument. När ett verktygs COBOL-faktureringsprogram läser historikdata genom en mellanliggande C-brygga, representerar beroendekartan både COBOL-till-C-beroendet och C-till-historiker-beroendet som en sammankopplad kedja, vilket gör hela IT/OT-övergången synlig snarare än upptäckbar endast genom en operativ incident.
Effektanalysfunktionen är särskilt viktig för SCADA-ansluten kod eftersom den räknar upp sprängradien för alla föreslagna ändringar innan ändringen görs . En modifiering av ett EU-beräkningsprogram som delas (via copybook) med larmgenereringskod, börvärdesleveranskod och historikkod kräver förståelse för alla tre sekundära effekter innan man vidrör beräkningen. I vanlig affärskod producerar en felaktig ändring fel data. I SCADA-ansluten kod producerar den fel driftsparametrar.
JCL -expansionskapaciteten avslöjar batchlagrets tids- och sekvenseringsstruktur: vilka jobb som körs i vilken ordning, vilka dataset-utgångar som matar vilka efterföljande steg och vilka jobbströmmar som är tidsbegränsade av operativa krav. Detta är den strukturella evidensbasen för den dokumentation av tidsberoende som SCADA-anslutande modernisering kräver.
Företagssökfunktionen gör det möjligt att använda hårdkodade parameterregistret i stor skala: hitta varje förekomst av en specifik teknisk enhetskonstant, varje larmgränsvärde, varje hårdkodad protokolladress över varje COBOL-, C-, RPG- och JCL-artefakt i miljön, på sekunder, över miljontals kodrader. För företag som hanterar hundratusentals rader SCADA-anslutande äldre kod är denna sökfunktion skillnaden mellan en manuell granskning som tar månader och en automatiserad inventering som tar timmar.
För teamplanering äldre modernisering av allmännyttiga system, SMART TS XL tillhandahåller den strukturella analysen på IT-sidan som gör att moderniseringsteamet kan arbeta effektivt tillsammans med OT-sidans kontrollingenjörer som förstår det operativa sammanhanget. Gränsen mellan IT/OT korsas inte säkert av enbart IT-team eller av enbart OT-team, den korsas säkert när båda sidor har korrekt strukturell kunskap om vad deras system innehåller.
Varför denna kod kräver en annan typ av uppmärksamhet
Energibolag som moderniserar sin SCADA-anslutna äldre kod uppdaterar inte bara gammal programvara. De ändrar programvaruskiktet som medlar mellan affärssystem och fysisk infrastruktur. Konsekvenserna av att göra fel är inte begränsade till datafel, serviceavbrott eller ekonomiska förluster, de sträcker sig till fysiska system som betjänar de människor som är beroende av att energibolagen fungerar.
De egenskaper som gör denna kod speciell, den fysiska konsekvensen av datafel, tidsberoenden som är osynliga för statisk analys, begränsningarna för säkerhetscertifiering, hårdvaru- och protokollkopplingen, är inte argument mot att modernisera den. De är argument för att förstå den helt innan man ändrar något. Analysramverket i denna guide producerar den förståelsen. Moderniseringsprogrammet som följer av det är säkrare eftersom förändringens omfattning definieras av bevis snarare än antaganden, tidsberoendena dokumenteras snarare än implicita, säkerhetsfunktionskoden identifieras snarare än oavsiktligt modifieras, och IT/OT-gränsövergångarna kartläggs snarare än upptäcks genom operativa incidenter efter driftsättning.
