Граница между ИТ и ОТ в коммунальной организации — это не четкая линия на сетевой диаграмме. Это проницаемая мембрана, через которую данные текут в обоих направлениях: пакетные программы на COBOL, генерирующие файлы конфигурации заданных значений, используемые ПЛК; программы на RPG, считывающие данные SCADA для выставления счетов и отчетности перед регулирующими органами; устаревшие мосты на C, преобразующие выходные данные мэйнфреймов в форматы, понятные распределенным системам управления; потоки заданий JCL, которые планируют и упорядочивают обмен данными через эту границу в соответствии со временем, от которого зависят операционные процессы. Программное обеспечение, управляющее этим потоком, не является ни чисто ИТ, ни чисто ОТ. Это связующее звено, обеспечивающее функционирование коммунальных предприятий, и это категория кода, к анализу которой команды модернизации наименее подготовлены, когда начинается программа трансформации.
Энергетический сектор переживает одну из самых значительных цифровых трансформаций в своей истории. По мере того, как коммунальные предприятия модернизируют свою инфраструктуру с помощью интеллектуальных сетей, подключенных подстанций, систем управления производственными процессами (ICS) и передовой автоматизации, сети операционных технологий (OT) становятся все более взаимосвязанными. Эта взаимосвязь не устраняет устаревший программный слой, а делает его более важным, поскольку каждая новая конечная точка интеллектуальной сети и облачная аналитическая платформа зависят от потоков данных, исходящих из приложений, написанных десятилетия назад. Модернизация этих приложений без понимания их роли в цепочке операционных данных — это не модернизация, а сбой, последствия которого выходят за рамки центров обработки данных и распространяются на физическую инфраструктуру.
Найдите все жестко закодированные параметры работы.
SMART TS XL Находит все константы ЕС, предельные значения сигналов тревоги и адреса протоколов, встроенные в ваш устаревший код.
УЗНАТЬ БОЛЬШЕ…Что на самом деле означает «SCADA-совместимый»?
Термин «SCADA-совместимое программное обеспечение» описывает программное обеспечение на стороне ИТ, которое взаимодействует с операционными технологическими системами, а не само программное обеспечение SCADA, не встроенное ПО ПЛК, не встроенный код RTU, а уровень бизнес-приложений, который передает данные в эти системы и получает данные из них. Эта категория обширна, недостаточно изучена и действительно отличается от остального портфеля корпоративных приложений.
В типичной коммунальной среде код, связанный с SCADA, включает в себя:
Программы для расчета параметров и заданных значений. Программы на COBOL и PL/I, которые рассчитывают заданные значения нагрузки, целевые значения напряжения, пороговые значения давления и рабочие ограничения, передаваемые в системы SCADA в виде файлов конфигурации или прямых потоков данных. Эти программы кодируют требования соответствия нормативным требованиям, технические спецификации и пределы физической безопасности. Неправильный расчет не приводит к неверному числу в отчете, он приводит к неверному рабочему значению, на основе которого работает система управления.
Потребители данных из архива SCADA. Программы на языках RPG и COBOL, которые считывают оперативные данные из баз данных архива SCADA для выставления счетов, подготовки нормативной отчетности и анализа производительности. Эти программы зависят от конкретных форматов данных, соглашений о временных метках и определений инженерных единиц, создаваемых архиватором. Изменение формата выходных данных архиватора или изменение в программе-потребителе на стороне ИТ может незаметно привести к искажению расчетов по выставлению счетов или подготовке нормативной отчетности.
Программы-мостики протоколов. Пользовательские программы на языке C, которые преобразуют выходные форматы мэйнфреймов в файловые или сетевые интерфейсы, используемые системами распределенного управления (DCS) и SCADA. Эти мостики реализуют специфические протоколы: Modbus, DNP3, IEC 61850, проприетарные форматы поставщиков, и содержат жестко заданные предположения о структуре сообщений, порядке байтов и синхронизации, которые нигде не описаны в документации.
Пакетная обработка данных и передача в реальном времени. Потоки заданий JCL, которые планируют и упорядочивают обмен данными между ИТ и ОТ-системами в определенных временных окнах. Ночной пакетный запуск энергосистемы может создавать данные конфигурации, которые должны быть доступны системе SCADA до начала утренних операций. Зависимость от времени неявно заложена в конфигурации планировщика и операционных ожиданиях диспетчерской, и нигде в коде приложения это не задокументировано.
Программы обработки аварийных сигналов и событий. Программы, которые получают записи об аварийных сигналах от систем SCADA, применяют логику классификации и маршрутизации, генерируют рабочие задания и создают отчеты о соответствии нормативным требованиям. Логика классификации аварийных сигналов, определяющая, какие события требуют каких отчетов в соответствии с нормативными требованиями и в какие сроки, часто встроена в программный код, накопивший за десятилетия изменения в законодательстве.
Это код, которым частично владеют инженеры и IT-разработчики, но ни один из них не понимает его до конца. Когда в рамках программы модернизации задают вопрос: «Что мы можем изменить?», ответ для кода, связанного с SCADA, почти всегда звучит так: «Меньше, чем вы думаете, и только после более тщательного анализа, чем вы планировали».
Почему стандартный анализ модернизации здесь терпит неудачу
Большинство аналитических моделей модернизации предприятий предполагают, что анализируемый код управляет только данными и бизнес-логикой, и что изменение программы приводит к изменению результатов обработки данных без каких-либо последствий для физического мира. Код, работающий в системах SCADA, нарушает это предположение четырьмя конкретными способами.
Физические последствия ошибок в данных
В стандартном приложении для выставления счетов неверный расчет приводит к неправильному счету-фактуре. Ошибка обнаруживается, обратима и имеет ограниченную область применения. В коде, совместимом с SCADA, неверный расчет может привести к неправильной уставки — целевому значению, на которое система управления воздействует, корректируя физические параметры: давление, напряжение, расход, температура. Последствием является не неверное число в базе данных. Это физический процесс, работающий за пределами заданных параметров, с последствиями, варьирующимися от неэффективности и повреждения оборудования до инцидентов, связанных с безопасностью.
Эта асимметрия между ошибкой данных и физическими последствиями является основной причиной, по которой код, связанный с SCADA, не может анализироваться с той же степенью допустимого риска, что и стандартный бизнес-код. Изменение, которое «работает правильно» с точки зрения получения корректного результата, может тем не менее привести к операционно некорректному результату, находящемуся в пределах допустимого диапазона типа данных, синтаксически корректному, но физически неправильному для контекста эксплуатации, который оно представляет.
Временные зависимости, которые статический анализ не может смоделировать
Программы, работающие в ИТ-среде и взаимодействующие с системами SCADA, часто имеют временные ограничения, имеющие важное операционное значение, но невидимые для инструментов статического анализа. Программа, генерирующая данные конфигурации, должна завершиться до того, как цикл опроса системы SCADA их прочитает. Пакетное задание, агрегирующее данные архива, должно завершиться до истечения временной метки окончания интервала, требуемой для отчетности перед регулирующими органами. Программа-переходник, передающая сигналы тревоги, должна обрабатывать события в течение времени отклика, указанного в оперативных процедурах диспетчерской.
Эти временные ограничения существуют в операционных процедурах утилиты, в конфигурации планировщика и в неявном понимании разработчиков, написавших программы, а не в исходном коде. Инструменты статического анализа, ориентированные на структуру кода и поток данных, не имеют представления о временных требованиях, существующих за пределами самого кода.
Практическое следствие: анализ модернизации кода, связанного с SCADA, должен явно документировать временной контекст каждой программы, подлежащей анализу. Это требует оперативных знаний, интервью с операторами диспетчерских пунктов, проверки графиков соответствия нормативным требованиям, анализа зависимостей заданий планировщика, а не только анализа кода.
Идентификация функций безопасности
Стандарты IEC 61511 (функциональная безопасность для отраслей обрабатывающей промышленности) и IEC 61508 (функциональная безопасность для электрических/электронных/программируемых электронных систем, связанных с безопасностью) определяют требования к сертификации программного обеспечения, выполняющего функции безопасности. Код, сертифицированный в соответствии с этими стандартами, — это не просто устаревший код, который можно рефакторизовать для улучшения сопровождения. Сертификация относится к конкретным фрагментам кода, к конкретной версии конкретного исполняемого файла, который оценивал орган по сертификации. Изменение кода, даже для исправления проблемы качества, которая была бы незаметной в бизнес-приложении, аннулирует сертификацию и требует повторной сертификации, прежде чем измененный код можно будет использовать в функции безопасности.
Многие коммунальные предприятия используют программы, интегрированные с SCADA-системами, которые выполняют расчеты, связанные с безопасностью, обнаружение избыточного давления, расчет заданных значений защиты трансформаторов, логику аварийного отключения, и которые могут соответствовать требованиям сертификации безопасности, даже если команда по модернизации ИТ об этом не знает. Первый аналитический вопрос для кода, интегрированного с SCADA-системами: выполняет ли какой-либо из этих кодов функции обеспечения безопасности? Если да, то какие функции, в рамках какой сертификации и что требуется для его изменения?
Аппаратная и протокольная связь
Программы мостовых протоколов и код встроенного интерфейса напрямую зависят от аппаратного обеспечения и версий протокола, которые они реализуют. Программа, реализующая Modbus RTU с использованием определенных функциональных кодов, карт регистров и значений тайм-аута для конкретной модели RTU от конкретного производителя, не реализует Modbus в общем виде, а реализует именно эту комбинацию, с предположениями, которые могут не выполняться для любой другой конфигурации.
При анализе этого кода на предмет модернизации обнаруживается зависимость не только от исходного кода на COBOL или C, но и от модели устройства RTU, версии прошивки, физической топологии проводки и конфигурации сети. Изменения в любом из этих параметров могут привести к поломке интерфейса, даже если исходный код программы остался неизменным. А изменения в исходном коде программы могут привести к поломке интерфейсов, которые кажутся несвязанными, поскольку мост был написан с учетом специфических особенностей протокола производителя, которые нигде не задокументированы.
Граница между ИТ и ОТ: где находится код
Модель Purdue (ISA-99 / IEC 62443) определяет концептуальную архитектуру сетей промышленных систем управления на пяти уровнях, от физических процессов на уровне 0 до корпоративных бизнес-систем на уровне 4. Устаревший код, связанный с SCADA, в коммунальных предприятиях обычно находится на уровнях 3 и 4, в зонах производственных операций и корпоративных сетей, но его потоки данных пересекают уровень 2 (уровень управления SCADA) в обоих направлениях.
Граница между ИТ и ОТ уровнями 3 и 2 является местом, где риски для безопасности и эксплуатации наиболее высоки. Государственные субъекты размещаются в сетях ОТ за несколько месяцев до активации, а группы, занимающиеся вымогательством, теперь развертывают вредоносные программы, адаптированные для защиты HMI и остановки производства. Наиболее частой точкой входа является не встроенное программное обеспечение SCADA, а пограничный уровень ИТ/ОТ, где код ИТ-системы и системы ОТ обмениваются данными через интерфейсы, разработанные для обеспечения операционной надежности, а не для защиты от враждебного воздействия.
Понимание точного набора программ, пересекающих эту границу, и того, что они там делают, является необходимым условием как для планирования модернизации, так и для улучшения уровня безопасности. Программа, которая считывает данные из SCADA-архива и записывает результаты в базу данных выставления счетов, пересекает границу в одном направлении. Программа, которая вычисляет заданные значения и записывает их в каталог конфигурации, который считывает ПЛК, пересекает ее в другом направлении. Обе являются смежными с SCADA. Ни одна из них не отображается при сканировании SCADA-сети или в инвентаризации ИТ-приложений, поэтому они систематически недостаточно анализируются.
Шаблоны кода, специфичные для программ, работающих в среде SCADA.
Код расчета инженерных единиц
Расчеты инженерных единиц (ЕЕ) преобразуют исходные значения датчиков, как правило, целочисленные значения от аналого-цифровых преобразователей, в физические измерения с определенными единицами, диапазонами и точностью. Токовая петля 4-20 мА от датчика давления выдает исходное значение; расчет ЕЕ преобразует его в PSI или бар с правильной калибровкой нуля и диапазона.
Данный код вычислений обладает характеристиками, отличающими его от стандартной бизнес-логики:
кобол
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.Константы в этом расчете, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSIЭти значения соответствуют физическим характеристикам прибора. Если они жестко закодированы (что часто бывает в устаревшем коде), изменение физического прибора требует изменения кода. Если они неверны (из-за перекалибровки прибора, его замены или первоначальной неправильной конфигурации), значение EU будет систематически неверным для каждой записи, когда-либо созданной программой. Статический анализ может определить, где определены эти константы; только оперативная проверка может подтвердить, соответствуют ли они текущей конфигурации прибора.
Логика генерации и классификации сигналов тревоги
Коды генерации сигналов тревоги относятся к числу наиболее чувствительных к нормативным требованиям кодов, связанных с системами SCADA в коммунальном хозяйстве. Стандарты NERC CIP (защита критической инфраструктуры) для электроэнергетических компаний, требования NRC к атомным электростанциям и требования EPA к отчетности для предприятий водоснабжения и водоотведения определяют, какие события должны генерировать сигналы тревоги, какую информацию должны содержать эти сигналы и в какие сроки о них необходимо сообщать.
кобол
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.Предельные значения срабатывания сигнализации в этом коде, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMITЭто рабочие параметры, имеющие нормативное значение. Изменения этих пределов влияют как на рабочее поведение системы управления, так и на обязательства энергоснабжающей компании по предоставлению отчетности в соответствии с нормативными требованиями. Любая программа модернизации, затрагивающая коды классификации аварийных сигналов, должна проходить проверку регулирующими органами в рамках процесса управления изменениями, а не ограничиваться только утверждением инженерными специалистами.
Реализации протокольных мостов
Программы мостов устаревших протоколов относятся к числу наиболее сложных для модернизации кодов, связанных с SCADA-системами, поскольку их зависимости сложнее всего перечислить. Программа реализует конкретную версию протокола для конкретного устройства, при этом недокументированные особенности поведения, специфичные для конкретного производителя, компенсируются в коде.
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);
}
/* ... */
}В этом коде заложены четыре предположения о конкретной модели ПЛК, которые не являются частью спецификации Modbus: адресация регистров с отсчетом от 1, только функциональный код 03, максимальное количество регистров — 60, и поведение разбиения на блоки для больших запросов. Ни одно из этих предположений не упоминается в документации Modbus. Это специфические особенности Modicon 984, описанные в руководстве по оборудованию 1998 года, которое, возможно, уже недоступно. Если этот мост модернизируется без учета этих предположений, или если ПЛК заменяется на более новую модель, использующую стандартную адресацию с отсчетом от 0, каждое чтение регистра возвращает неверное значение, смещенное ровно на один адрес регистра.
Анализ домодернизации: что необходимо создать
Прежде чем вносить изменения, переписывать или заменять какой-либо код, связанный с SCADA-системами, необходимо получить набор результатов, выходящих за рамки стандартного анализа модернизации предприятия.
Инвентаризация операционных функций. Каждая программа, связанная с SCADA, должна быть классифицирована по своей операционной функции: расчет EU, подача заданных значений, потребление данных архива, генерация аварийных сигналов, мост протоколов, путь пакетной обработки в реальном времени. Эта классификация определяет, кто должен быть вовлечен в процесс изменений: только ИТ-инженеры или межфункциональная команда, включающая инженеров по управлению, оперативный персонал и специалистов по соблюдению нормативных требований.
Карта пересечения границ ИТ/ОТ. Каждый поток данных, пересекающий границу ИТ/ОТ, должен быть задокументирован: какая программа генерирует данные, в каком формате и по какому расписанию; какая система ОТ их потребляет; и каковы последствия, если данные некорректны, задержаны или отсутствуют. Эта карта представляет собой профиль операционных рисков для уровня, смежного с SCADA.
Идентификация функций безопасности. Каждая программа должна быть оценена на предмет выполнения ею функций безопасности в соответствии со стандартами IEC 61511, IEC 61508, NERC CIP или другими применимыми стандартами. Программы, отнесенные к коду, содержащему функции безопасности, требуют отдельного управления изменениями, уведомления регулирующих органов и, возможно, повторной сертификации; сроки модернизации таких программ принципиально отличаются от стандартных бизнес-кодов.
Реестр жестко закодированных параметров работы. Каждая жестко закодированная константа, представляющая собой параметр работы, значения калибровки датчика, пределы срабатывания сигнализации, ограничения протокола, пороговые значения времени, должна быть идентифицирована, задокументирована с указанием ее рабочего значения и проверена на соответствие текущим техническим характеристикам прибора. Этот реестр становится входными данными для процесса управления конфигурацией, который заменяет жестко закодированные константы конфигурацией, управляемой извне.
Документация по зависимостям времени выполнения. Контекст времени выполнения каждой программы, операционные окна, в рамках которых она должна завершиться, зависимости планировщика, обеспечивающие соблюдение этих окон, и операционные процедуры, зависящие от ее завершения, должны быть явно задокументированы. Эта документация является спецификацией, на основе которой должна быть проверена модернизированная реализация.
Спецификация протокола и интерфейса. Каждая программа моста протокола должна быть проанализирована на предмет особенностей поведения, специфичных для производителя, предположений о версии протокола и компенсаций, специфичных для устройства. Результатом является документ спецификации, который можно использовать для проверки заменяющей реализации, подтверждая, что все компенсирующие особенности поведения сохранены, даже те, которые не были включены в исходную спецификацию.
Эффективные и неэффективные подходы к модернизации
«Запутывающая фига», применяемая с осторожностью. Паттерн «Запутывающая фига», предполагающий создание новой функциональности параллельно со старой, поэтапную маршрутизацию и постепенное выведение из эксплуатации, подходит для кода, смежного с SCADA, который выполняет обработку данных на стороне ИТ (потребители исторических данных, расчеты счетов). Старая программа продолжает работать во время перехода; новая реализация создает параллельные выходные данные, которые проверяются на эквивалентность перед выводом старой программы из эксплуатации.
Принцип Strangler Fig не применим к процессам обработки данных в реальном времени. Для программ, работающих в потоке данных в реальном времени, где нет безопасного способа параллельного запуска старых и новых программ, поскольку это приведет к конфликтующим операционным эффектам, переход должен быть мгновенным и проверен в автономном режиме до любого запуска в производство. Запуск параллельной программы расчета заданных значений, которая выдает значения, отличные от значений текущей программы, приведет к отправке конфликтующих заданных значений в систему управления.
Вынесение конфигурационных данных вовне перед изменением кода. Для программ с жестко закодированными рабочими параметрами наиболее безопасным первым шагом модернизации является вынесение этих параметров в конфигурационный файл или базу данных без изменения логики вычислений. Это делает параметры видимыми, управляемыми и проверяемыми без затрагивания кода вычислений, имеющего операционное значение. Риск вынесения параметров вовне существенно ниже, чем риск рефакторинга логики вычислений.
Анализ и документирование кода, отвечающего за безопасность, а не рефакторинг. Сертифицированный по безопасности код следует анализировать и документировать на этапе планирования модернизации, но изменения в нем следует отложить до завершения целенаправленной программы повторной сертификации с согласованием с регулирующими органами, а не рассматривать в рамках общей инициативы по модернизации. Риск аннулирования сертификата безопасности в ходе масштабной модернизации не оправдан типичными преимуществами модернизации.
Как SMART TS XL Поддерживает анализ устаревшего кода, совместимого с SCADA-системами.
SMART TS XLАвтора статический анализ кода Это относится к ИТ-стороне границы, граничащей с SCADA, к программам на COBOL, JCL, RPG, PL/I и C, которые работают на мэйнфреймах и системах среднего уровня и генерируют, преобразуют или потребляют данные, поступающие в операционные среды. Для этого кода структурный анализ создает перечень операционных функций и реестр жестко закодированных параметров, необходимые для анализа до модернизации.
Карта зависимостей приложений строит карту пересечения границ ИТ и ОТ: каждая программа, которая записывает данные в файловый интерфейс, используемый системой SCADA, каждый шаг задания JCL, который создает данные, имеющие значение для оперативного времени, каждая программа в пути передачи данных из архива от источника ОТ к потребителю ИТ. Когда программа COBOL для выставления счетов коммунального предприятия считывает данные из архива через промежуточный мост C, карта зависимостей представляет как зависимость COBOL-C, так и зависимость C-от архива в виде связанной цепочки, делая полное пересечение ИТ и ОТ видимым, а не обнаруживаемым только в результате оперативного инцидента.
Возможность анализа воздействия особенно важна для кода, совместимого с SCADA, поскольку она позволяет определить масштаб последствий любого предлагаемого изменения еще до его внесения. Модификация программы расчета EU, которая используется (через copybook) совместно с кодом генерации аварийных сигналов, кодом передачи заданных значений и кодом записи в архив данных, требует понимания всех трех вторичных воздействий, прежде чем вносить изменения в расчет. В стандартном бизнес-коде некорректное изменение приводит к неверным данным. В коде, совместимом с SCADA, оно приводит к неверным рабочим параметрам.
Возможности расширения JCL позволяют выявить временную структуру и последовательность выполнения задач на уровне пакетной обработки: какие задания выполняются в каком порядке, какие выходные данные поступают на какие последующие этапы и какие потоки заданий ограничены по времени в соответствии с эксплуатационными требованиями. Это структурная база данных для документации зависимостей по времени, необходимой для модернизации, связанной с SCADA-системами.
Возможность корпоративного поиска позволяет масштабно обрабатывать жестко закодированные параметры реестра: за считанные секунды можно найти каждое вхождение конкретной константы инженерного блока, каждое значение предельного значения аварийного сигнала, каждый жестко закодированный адрес протокола во всех артефактах COBOL, C, RPG и JCL в среде, охватывая миллионы строк кода. Для коммунальных предприятий, управляющих сотнями тысяч строк устаревшего кода, связанного с SCADA, эта возможность поиска — это разница между ручной проверкой, занимающей месяцы, и автоматизированной инвентаризацией, занимающей часы.
Для планирования команд модернизация наследия систем коммунального хозяйства, SMART TS XL Предоставляет структурный анализ со стороны ИТ, который позволяет команде модернизации эффективно работать вместе с инженерами по управлению со стороны ОТ, понимающими операционный контекст. Граница между ИТ и ОТ не может быть безопасно пересечена только командами ИТ или только командами ОТ; она безопасно пересекается, когда обе стороны обладают точными структурными знаниями о содержании своих систем.
Почему этот код требует иного подхода
Коммунальные предприятия, модернизирующие свой устаревший код, связанный с SCADA, не просто обновляют старое программное обеспечение. Они меняют программный слой, который выступает посредником между бизнес-системами и физической инфраструктурой. Последствия ошибок не ограничиваются ошибками в данных, сбоями в обслуживании или финансовыми потерями, они распространяются на физические системы, которые обслуживают людей, зависящих от коммунальных услуг.
Особенности этого кода, его физические последствия, связанные с ошибками данных, временные зависимости, невидимые для статического анализа, ограничения сертификации безопасности, связь оборудования и протоколов — всё это не аргументы против его модернизации. Это аргументы в пользу полного понимания кода перед внесением каких-либо изменений. Аналитическая структура, представленная в этом руководстве, обеспечивает такое понимание. Программа модернизации, вытекающая из этого, более безопасна, поскольку масштаб изменений определяется фактическими данными, а не предположениями, временные зависимости документируются, а не подразумеваются, код функций безопасности идентифицируется, а не изменяется случайно, а пересечения границ ИТ/ОТ отображаются на карте, а не обнаруживаются в результате операционных инцидентов после развертывания.
