Hranice mezi IT a OT v organizaci dodavatele energií není na síťovém diagramu čistou linií. Je to propustná membrána, skrz kterou data proudí oběma směry: dávkové programy v COBOLu generují konfigurační soubory spotřebované PLC, programy RPG čtou historická data SCADA pro fakturaci a regulační reporting, starší mosty C převádějí výstupy sálových počítačů do formátů, kterým rozumí distribuované řídicí systémy, a toky úloh JCL, které plánují a sekvenují výměny dat přes hranici podle načasování, na kterém závisí provozní procesy. Software, který tento tok řídí, není ani čistě IT, ani čistě OT. Je to pojivová tkáň, která zajišťuje fungování dodavatelů energií, a je to kategorie kódu, kterou jsou modernizační týmy nejméně připraveny analyzovat, když začíná transformační program.
Energetický sektor prochází jednou z nejvýznamnějších digitálních transformací ve své historii. S tím, jak energetické společnosti modernizují svou infrastrukturu pomocí inteligentních sítí, propojených rozvoden, ICS a pokročilé automatizace, se OT sítě staly propojenějšími než kdykoli předtím. Toto propojení neodstraňuje vrstvu staršího kódu, ale činí ji důležitější, protože každý nový koncový bod inteligentní sítě a platforma pro cloudovou analytiku závisí na datových zdrojích, které pocházejí z aplikací napsaných před desítkami let. Modernizace těchto aplikací bez pochopení jejich role v provozním datovém řetězci není modernizací, ale narušením s důsledky, které sahají za hranice datového centra až po fyzickou infrastrukturu.
Najděte všechny pevně zakódované provozní parametry
SMART TS XL vyhledá každou konstantu EU, limit alarmu a adresu protokolu obsaženou ve vašem portfoliu starších kódů.
ZJISTĚTE VÍCE…Co vlastně znamená „SCADA-Adjacent“
Termín „souvisí se SCADA“ popisuje software na straně IT, který je propojen s operačními technologickými systémy, nikoli samotný software SCADA, ani firmware PLC, ani vestavěný kód RTU, ale vrstvu podnikových aplikací, která do těchto systémů vkládá data a přijímá data z těchto systémů. Tato kategorie je rozsáhlá, nedostatečně analyzovaná a skutečně se liší od zbytku portfolia podnikových aplikací.
V typickém prostředí energetických společností zahrnuje kód související se SCADA:
Programy pro výpočet rychlosti a nastavených hodnot. Programy v COBOL a PL/I, které vypočítávají nastavené hodnoty zatížení, cílové hodnoty napětí, prahové hodnoty tlaku a provozní limity, jsou dodávány do systémů SCADA jako konfigurační soubory nebo přímé datové kanály. Tyto programy kódují požadavky na shodu s předpisy, technické specifikace a limity fyzické bezpečnosti. Nesprávný výpočet nevede k chybnému číslu v protokolu, ale k nesprávné provozní nastavené hodnotě, na kterou řídicí systém reaguje.
Uživatelé dat z historie. Programy RPG a COBOL, které čtou provozní data z databází historie SCADA pro účely fakturace, regulačního reportingu a analýzy výkonu. Tyto programy závisí na specifických formátech dat, konvencích časových razítek a definicích technických jednotek, které historie vytváří. Změna formátu ve výstupu historie nebo změna v uživatelském programu na straně IT může nenápadně narušit výpočty fakturace nebo regulační podání.
Programy pro přemostění protokolů. Vlastní programy v jazyce C, které převádějí mezi výstupními formáty sálových počítačů a rozhraními založenými na souborech nebo síti, která využívají systémy DCS (Distributed Control System) a SCADA. Tyto přemostění implementují specifické protokoly, Modbus, DNP3, IEC 61850, proprietární formáty dodavatelů a mají pevně zakódované předpoklady o struktuře zpráv, pořadí bajtů a načasování, které nikde v dokumentaci neexistují.
Cesty dávkového přenosu dat do reálného času. Toky úloh JCL, které plánují a sekvenují výměny dat napříč hranicemi IT/OT v určitých časových oknech. Noční dávkové spuštění energetického podniku může produkovat konfigurační data, která musí být k dispozici systému SCADA před zahájením ranního provozu. Časová závislost je implicitní v konfiguraci plánovače a provozních očekáváních velínu a není nikde v kódu aplikace zdokumentována.
Programy pro zpracování alarmů a událostí. Programy, které přijímají záznamy alarmů ze systémů SCADA, aplikují logiku klasifikace a směrování, generují pracovní příkazy a vytvářejí záznamy o shodě s předpisy. Logika klasifikace alarmů, tedy které události vyžadují jaké regulační zprávy a v jakých časových rámcích, je často zabudována v programovém kódu, který nashromáždil desetiletí regulačních změn.
Toto je kód, který ovládají inženýři a IT vývojáři, kteří oba částečně ovládají a ani jeden z nich mu plně nerozumí. Když se modernizační program zeptá: „Co můžeme změnit?“, odpověď pro kód související se SCADA je téměř vždy: „Méně, než si myslíte, a až po větší analýze, než jste plánovali.“
Proč zde standardní modernizační analýza selhává
Většina rámců pro analýzu modernizace podniků předpokládá, že analyzovaný kód řídí pouze data a obchodní logiku a že změna programu produkuje odlišný datový výstup bez jakýchkoli důsledků pro fyzický svět. Kód sousedící se SCADA tento předpoklad porušuje čtyřmi specifickými způsoby.
Fyzické důsledky chyb v datech
Ve standardní fakturační aplikaci vede nesprávný výpočet k chybné faktuře. Chyba je zjistitelná, vratná a má omezený rozsah. V kódu podobném SCADA může nesprávný výpočet vést k nesprávné nastavené hodnotě, cílové hodnotě, na kterou řídicí systém reaguje úpravou fyzikálních parametrů: tlaku, napětí, průtoku, teploty. Důsledkem není chybné číslo v databázi. Jde o fyzikální proces probíhající mimo zamýšlené parametry s následky od neefektivity přes poškození zařízení až po bezpečnostní incidenty.
Tato asymetrie mezi chybou dat a fyzickými důsledky je základním důvodem, proč kód sousedící se SCADA nelze analyzovat se stejnou tolerancí rizika jako standardní obchodní kód. Změna, která „funguje správně“ z hlediska produkce platného výstupu, může stále produkovat provozně nesprávný výstup v rámci povoleného rozsahu datového typu, syntakticky platný, ale fyzicky chybný pro provozní kontext, který reprezentuje.
Časové závislosti, které statická analýza nedokáže modelovat
IT programy sousedící se systémy SCADA mají často časová omezení, která jsou provozně významná, ale pro nástroje statické analýzy neviditelná. Program, který generuje konfigurační data, musí být dokončen dříve, než je cyklus dotazování systému SCADA načte. Dávková úloha, která agreguje historická data, musí být dokončena před časovým razítkem konce intervalu, které vyžaduje regulační reporting. Můstkový program, který přenáší alarmy, musí zpracovat události v rámci doby odezvy specifikované provozními postupy velínu.
Tato časová omezení existují v provozních postupech utility, v konfiguraci plánovače a v implicitním chápání vývojářů, kteří programy napsali, nikoli ve zdrojovém kódu. Nástroje statické analýzy, které se zaměřují na strukturu kódu a tok dat, nemají žádný přehled o požadavcích na časování, které existují mimo samotný kód.
Praktický důsledek: analýza modernizace kódu souvisejícího se SCADA musí explicitně dokumentovat časový kontext pro každý program v rozsahu. To vyžaduje znalosti provozu, rozhovory s operátory velínu, kontrolu harmonogramů dodržování předpisů, analýzu závislostí úloh plánovače, nejen analýzu kódu.
Identifikace bezpečnostní funkce
Normy IEC 61511 (funkční bezpečnost pro procesní průmysl) a IEC 61508 (funkční bezpečnost pro elektrické/elektronické/programovatelné elektronické systémy související s bezpečností) definují certifikační požadavky na software, který plní bezpečnostní funkce. Kód, který byl certifikován podle těchto norem, není pouze starší kód, který lze refaktorovat z hlediska údržby. Certifikace se vztahuje na specifické artefakty kódu, specifickou verzi konkrétního binárního souboru, který certifikační orgán vyhodnotil. Změna kódu, a to i za účelem opravy problému s kvalitou, který by byl v podnikové aplikaci nevýrazný, zneplatňuje certifikaci a vyžaduje opětovnou certifikaci, než lze změněný kód nasadit do bezpečnostní funkce.
Mnoho dodavatelů energií má programy podobné SCADA, které provádějí bezpečnostní výpočty, detekci přetlaku, výpočet nastavených hodnot ochrany transformátoru a logiku nouzového vypnutí, a které mohou spadat pod požadavky bezpečnostní certifikace, aniž by o tom tým modernizace IT věděl. První analytická otázka pro kód podobný SCADA zní: plní některý z těchto kódů bezpečnostní funkci? Pokud ano, jaké funkce, pod jakou certifikací a co vyžaduje jeho změna?
Propojení hardwaru a protokolu
Programy pro přemostění protokolů a kód vestavěného rozhraní přímo závisí na hardwaru a verzích protokolů, které implementují. Program, který implementuje Modbus RTU se specifickými funkčními kódy, mapami registrů a hodnotami časového limitu pro konkrétní model RTU od konkrétního dodavatele, neimplementuje Modbus genericky, ale implementuje tuto specifickou kombinaci s předpoklady, které nemusí platit pro žádnou jinou konfiguraci.
Při analýze modernizace tohoto kódu se nejedná pouze o závislost na zdrojovém kódu COBOL nebo C, ale také o model zařízení RTU, verzi firmwaru, topologii fyzického zapojení a konfiguraci sítě. Změny kteréhokoli z těchto faktorů mohou narušit rozhraní, i když zdrojový kód programu zůstává nezměněn. A změny zdrojového kódu programu mohou narušit rozhraní, která se zdají být nesouvisející, protože most byl napsán tak, aby kompenzoval specifické zvláštnosti protokolu daného dodavatele, které nejsou nikde zdokumentovány.
Hranice IT/OT: Kde žije kód
Purdueův model (ISA-99 / IEC 62443) definuje koncepční architekturu sítí průmyslových řídicích systémů v pěti úrovních, od fyzických procesů na úrovni 0 až po podnikové obchodní systémy na úrovni 4. Starší kód související se SCADA v energetických prostředích se obvykle nachází na úrovních 3 a 4, tedy ve výrobních operacích a v zónách podnikové sítě, ale jeho datové toky přecházejí do úrovně 2 (dozorčí vrstva SCADA) v obou směrech.
Hranice IT/OT mezi úrovněmi 3 a 2 představuje nejvyšší bezpečnostní a provozní riziko. Národní aktéři se předem umisťují do OT sítí měsíce před aktivací, zatímco skupiny šířící ransomware nyní nasazují datové zátěže s podporou ICS, které jsou navrženy tak, aby uzamkly HMI a zastavily výrobu. Nejčastějším vstupním bodem není vestavěný software SCADA, ale hraniční vrstva IT/OT, kde si kód na straně IT a OT systémy vyměňují data prostřednictvím rozhraní, která byla navržena spíše pro provozní spolehlivost než pro zabezpečení proti nepřátelským stranám.
Pochopení přesné sady programů, které tuto hranici překračují, a toho, co v ní dělají, je předpokladem jak pro plánování modernizace, tak pro zlepšení bezpečnostního stavu. Program, který čte z historie SCADA a zapisuje výsledky do fakturační databáze, překračuje hranici v jednom směru. Program, který vypočítává nastavené hodnoty a zapisuje je do konfiguračního adresáře, který PLC čte, ji překračuje v opačném směru. Oba jsou sousedící se SCADA. Ani jeden z nich se neobjevuje ve skenu sítě SCADA ani v inventáři IT aplikací, a proto jsou systematicky nedostatečně analyzovány.
Vzory kódu specifické pro programy související se SCADA
Kód výpočtu technických jednotek
Výpočty v technických jednotkách (EU) převádějí nezpracované hodnoty senzorů, obvykle celočíselné hodnoty z analogově-digitálních převodníků, na fyzikální měření se specifickými jednotkami, rozsahy a přesností. Proudová smyčka 4–20 mA z tlakového snímače vytváří nezpracovaný údaj; výpočet EU jej převádí na PSI nebo bary se správnou kalibrací nuly a rozsahu.
Tento výpočetní kód má vlastnosti, které ho odlišují od standardní obchodní logiky:
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.Konstanty v tomto výpočtu, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSI, odpovídají specifikacím fyzického přístroje. Pokud jsou pevně zakódovány (jak je tomu často ve starším kódu), změna fyzického přístroje vyžaduje změnu kódu. Pokud jsou nesprávné (kvůli rekalibraci přístroje, výměně nebo původní chybné konfiguraci), je hodnota EU systematicky nesprávná pro každý záznam, který program kdy vytvořil. Statická analýza dokáže najít, kde jsou tyto konstanty definovány; pouze provozní validace může potvrdit, zda jsou správné pro aktuální konfiguraci přístroje.
Logika generování a klasifikace alarmů
Kód generování alarmů patří mezi kódy SCADA, které jsou nejvíce citlivé na regulaci v prostředí energetických společností. Normy NERC CIP (ochrana kritické infrastruktury) pro energetické společnosti, požadavky NRC pro jaderná zařízení a požadavky EPA na hlášení pro vodovodní a kanalizační společnosti specifikují, které události musí generovat alarmy, jaké informace musí tyto alarmy obsahovat a v jakých časových rámcích musí být hlášeny.
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.Limity alarmu v tomto kódu, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMIT, jsou provozní parametry s regulačním významem. Změny těchto limitů ovlivňují jak provozní chování řídicího systému, tak i povinnosti energetické společnosti v oblasti regulačních reportingu. Jakýkoli modernizační program, který se dotýká kódu klasifikace alarmů, musí být v procesu řízení změn přezkoumán regulačními záležitostmi, nejen schválen technickým schvalováním.
Implementace mostů protokolů
Programy pro přemostění starších protokolů patří mezi nejobtížněji modernizovatelný kód související se SCADA, protože jejich závislosti se nejobtížněji vyčíslují. Program implementuje specifickou verzi protokolu pro konkrétní zařízení, přičemž v kódu je kompenzováno nedokumentované chování specifické pro daného dodavatele.
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);
}
/* ... */
}Tento kód má čtyři vložené předpoklady o konkrétním modelu PLC, které nejsou součástí specifikace Modbus: adresování registrů založené na 1, funkční kód pouze 03, maximum 60 registrů a chování při rozdělování do bloků pro větší požadavky. Žádný z těchto předpokladů se v dokumentaci k Modbusu neobjevuje. Jedná se o chování Modiconu 984 specifické pro dodavatele, zdokumentované v hardwarové příručce z roku 1998, která již nemusí být k dispozici. Pokud je tento můstek modernizován bez pochopení těchto předpokladů nebo pokud je PLC nahrazen novějším modelem, který používá standardní adresování založené na 0, každé čtení registru vrátí nesprávnou hodnotu přesně o jeden posun adresy registru.
Analýza před modernizací: Co je třeba vyrobit
Než je jakýkoli kód související se SCADA upraven, refaktorován nebo nahrazen, musí analýza vytvořit sadu výstupů, které jdou nad rámec toho, co poskytuje standardní analýza modernizace podniku.
Inventář provozních funkcí. Každý program sousedící se SCADA musí být klasifikován podle své provozní funkce: výpočet EU, doručování nastavených hodnot, příjemce historických dat, generování alarmů, most protokolu, cesta dávkového přenosu do reálného času. Tato klasifikace určuje, kdo musí být zapojen do procesu změn, zda IT inženýři sami, nebo mezifunkční tým, který zahrnuje řídicí techniky, provozní personál a pracovníky zabývající se dodržováním předpisů.
Mapa překračování hranic IT/OT. Každý datový tok, který překračuje hranici IT/OT, musí být zdokumentován: který program data vytváří, v jakém formátu, podle jakého harmonogramu; který OT systém je spotřebovává; a jaké jsou důsledky, pokud jsou data nesprávná, zpožděná nebo chybí. Tato mapa představuje profil provozního rizika pro vrstvu sousedící se SCADA.
Identifikace bezpečnostní funkce. Každý program musí být vyhodnocen z hlediska toho, zda plní bezpečnostní funkci podle norem IEC 61511, IEC 61508, NERC CIP nebo jiných platných norem. Programy identifikované jako kód bezpečnostní funkce vyžadují samostatnou kontrolu změn, regulační oznámení a potenciálně recertifikaci. Časový harmonogram modernizace těchto programů se zásadně liší od standardního obchodního kódu.
Registr pevně zakódovaných provozních parametrů. Každá pevně zakódovaná konstanta, která představuje provozní parametr, kalibrační hodnoty senzorů, limity alarmů, omezení protokolu, časové prahy, musí být identifikována, zdokumentována s jejím provozním významem a validována podle aktuálních specifikací přístroje. Tento registr se stává vstupem pro proces správy konfigurace, který nahrazuje pevně zakódované konstanty externě spravovanou konfigurací.
Dokumentace závislostí na časování. Časový kontext každého programu, operační okna, ve kterých musí být dokončen, závislosti plánovače, které tato okna vynucují, a operační postupy, které závisí na jeho dokončení, musí být explicitně zdokumentovány. Tato dokumentace je specifikací, podle které musí být modernizovaná implementace validována.
Specifikace protokolu a rozhraní. Každý program pro přemostění protokolů musí být analyzován z hlediska chování specifického pro dodavatele, předpokladů verzí protokolu a kompenzací specifických pro zařízení. Výstupem je specifikační dokument, který lze použít k ověření náhradní implementace a potvrdí, že je zachováno každé kompenzační chování, a to i ty, které nebyly v původní specifikaci.
Modernizační přístupy, které fungují, a ty, které nefungují
Vzor Strangler Fig, aplikovaný opatrně. Vzor Strangler Fig, který vytváří novou funkcionalitu vedle staré, směruje postupně a vyřazuje ji z provozu, je vhodný pro kód sousedící se SCADA, který provádí zpracování dat na straně IT (spotřebitelé historických dat, výpočty fakturace). Starý program během přechodu pokračuje v běhu; nová implementace produkuje paralelní výstupy, jejichž ekvivalence je ověřena před vyřazením starého programu.
Obr. škrtiče se nevztahuje na datové cesty v reálném čase. U programů, které se nacházejí v datové cestě v reálném čase, kde neexistuje bezpečný způsob, jak spouštět staré a nové programy paralelně, protože by to vedlo k konfliktním provozním účinkům, musí být přechod okamžitý a ověřený offline před jakýmkoli vypnutím výroby. Spuštění paralelního programu pro výpočet nastavených hodnot, který produkuje jiné hodnoty než aktuální program, by do řídicího systému odeslalo konfliktní nastavené hodnoty.
Externalizace konfigurace před změnami kódu. U programů s pevně zakódovanými provozními parametry je nejbezpečnějším prvním krokem modernizace externalizace těchto parametrů do konfiguračního souboru nebo databáze bez změny výpočtové logiky. Díky tomu jsou parametry viditelné, spravovatelné a auditovatelné, aniž by se muselo dotýkat výpočtového kódu, který má provozní význam. Riziko externalizace parametrů je podstatně nižší než refaktorování výpočtové logiky.
Kód bezpečnostních funkcí: analýza a dokumentace, nikoli refaktoring. Bezpečnostně certifikovaný kód by měl být analyzován a dokumentován během fáze plánování modernizace, ale jeho změny by měly být odloženy do záměrného programu recertifikace s regulační koordinací, nikoli řešeny jako součást obecné modernizační iniciativy. Riziko zneplatnění bezpečnostní certifikace během rozsáhlé modernizace není odůvodněno žádným typickým přínosem modernizace.
Jak SMART TS XL Podporuje analýzu staršího kódu v souladu se SCADA
SMART TS XLJe statická analýza kódu platí pro IT stranu hranice sousedící se SCADA, programy v jazycích COBOL, JCL, RPG, PL/I a C, které běží na sálových počítačích a systémech střední třídy a generují, transformují nebo spotřebovávají data, která přecházejí do prostředí OT. Pro tento kód strukturální analýza vytváří inventář provozních funkcí a pevně zakódovaný registr parametrů, které vyžaduje analýza před modernizací.
Mapování závislostí aplikací vytváří mapu hranic IT/OT: každý program, který zapisuje do souborového rozhraní spotřebovaného systémem SCADA, každý krok úlohy JCL, který produkuje data s provozním časovým významem, každý program v cestě historických dat od zdroje OT ke spotřebiteli IT. Když fakturační program COBOL dodavatele energií čte historická data přes mezilehlý most C, mapa závislostí představuje jak závislost COBOL-C, tak závislost C-historic jako propojený řetězec, takže úplné přechody IT/OT jsou viditelné, nikoli zjistitelné pouze prostřednictvím provozního incidentu.
Schopnost analýzy dopadů je obzvláště důležitá pro kód související se SCADA, protože vypočítává poloměr výbuchu jakékoli navrhované změny před jejím provedením. Úprava výpočetního programu EU, která je sdílena (prostřednictvím sady nástrojů) s kódem generování alarmů, kódem pro doručování nastavených hodnot a kódem pro zápis do historian systému, vyžaduje pochopení všech tří sekundárních dopadů před zahájením výpočtu. Ve standardním obchodním kódu vede nesprávná změna k nesprávným datům. V kódu souvisejícím se SCADA vede k nesprávným provozním parametrům.
Možnost rozšíření JCL odhaluje strukturu časování a řazení dávkové vrstvy: které úlohy běží v jakém pořadí, které datové sady výstupně zásobují které následné kroky a které streamy úloh jsou časově omezeny provozními požadavky. Toto je strukturální důkazní základna pro dokumentaci časových závislostí, kterou vyžaduje modernizace související se SCADA.
Díky podnikovému vyhledávání je registr pevně zakódovaných parametrů dostupný ve velkém měřítku: lze najít každý výskyt specifické konstanty inženýrské jednotky, každou mezní hodnotu alarmu, každou pevně zakódovanou adresu protokolu napříč každým artefaktem COBOL, C, RPG a JCL v prostředí, během několika sekund, napříč miliony řádků kódu. Pro energetické společnosti spravující stovky tisíc řádků staršího kódu souvisejícího se SCADA představuje tato vyhledávací funkce rozdíl mezi manuálním auditem, který trvá měsíce, a automatizovanou inventarizací, která trvá hodiny.
Pro plánování týmů starší modernizace inženýrských sítí, SMART TS XL poskytuje strukturální analýzu na straně IT, která umožní modernizačnímu týmu efektivně spolupracovat s řídicími techniky na straně provozních technologií, kteří rozumí provoznímu kontextu. Hranici IT/OT nepřekračují bezpečně pouze IT týmy nebo pouze OT týmy, ale bezpečně ji překračují, když obě strany mají přesné strukturální znalosti o tom, co jejich systémy obsahují.
Proč tento kód vyžaduje jiný druh pozornosti
Dopravci, kteří modernizují svůj starší kód související se SCADA, neaktualizují pouze starý software. Mění softwarovou vrstvu, která je prostředníkem mezi obchodními systémy a fyzickou infrastrukturou. Důsledky chybného provedení se neomezují pouze na chyby v datech, narušení služeb nebo finanční ztráty, ale rozšiřují se i na fyzické systémy, které slouží lidem, jejichž fungování je na energetických společnostech závislé.
Charakteristiky, které činí tento kód výjimečným, fyzické důsledky chyb v datech, časové závislosti neviditelné pro statickou analýzu, omezení bezpečnostní certifikace, propojení hardwaru a protokolu, nejsou argumenty proti jeho modernizaci. Jsou argumenty pro jeho úplné pochopení před jakoukoli změnou. Analytický rámec v této příručce toto pochopení vytváří. Modernizační program, který z něj vyplývá, je bezpečnější, protože rozsah změn je definován důkazy spíše než předpoklady, časové závislosti jsou zdokumentovány spíše než implicitně, kód bezpečnostní funkce je identifikován spíše než náhodně upraven a překračování hranic IT/OT jsou mapována spíše než zjišťována prostřednictvím provozních incidentů po nasazení.
