유틸리티 조직에서 IT/OT 경계는 네트워크 다이어그램에서 명확하게 구분되는 선이 아닙니다. 오히려 데이터가 양방향으로 흐르는 투과성 막과 같습니다. COBOL 배치 프로그램은 PLC에서 사용하는 설정값 구성 파일을 생성하고, RPG 프로그램은 청구 및 규제 보고를 위해 SCADA 히스토리 데이터를 읽고, 레거시 C 브리지는 메인프레임 출력을 분산 제어 시스템이 이해하는 형식으로 변환하며, JCL 작업 스트림은 운영 프로세스가 의존하는 시점에 맞춰 경계를 넘나드는 데이터 교환을 예약하고 순서를 지정합니다. 이러한 흐름을 관리하는 소프트웨어는 순수한 IT 영역도, 순수한 OT 영역도 아닙니다. 이는 유틸리티 조직이 기능하도록 하는 연결 조직이며, 변혁 프로그램이 시작될 때 현대화 팀이 분석할 준비가 가장 부족한 코드 범주이기도 합니다.
에너지 부문은 역사상 가장 중요한 디지털 전환을 겪고 있습니다. 전력 회사들이 스마트 그리드, 연결된 변전소, 산업 제어 시스템(ICS), 첨단 자동화 등을 통해 인프라를 현대화함에 따라, OT 네트워크는 그 어느 때보다 긴밀하게 연결되고 있습니다. 이러한 상호 연결은 기존 레거시 코드 계층을 없애는 것이 아니라 오히려 더욱 중요하게 만듭니다. 모든 새로운 스마트 그리드 엔드포인트와 클라우드 분석 플랫폼은 수십 년 전에 작성된 애플리케이션에서 생성된 데이터 피드에 의존하기 때문입니다. 운영 데이터 체인에서 이러한 애플리케이션의 역할을 이해하지 않고 현대화하는 것은 진정한 현대화가 아니라, 데이터 센터를 넘어 물리적 인프라에까지 영향을 미치는 파괴적인 변화를 초래할 것입니다.
"SCADA 관련"이라는 말의 실제 의미는 무엇일까요?
SCADA 관련 소프트웨어라는 용어는 SCADA 소프트웨어 자체, PLC 펌웨어, RTU 내장 코드가 아닌, 운영 기술 시스템과 상호 작용하는 IT 측 소프트웨어를 의미합니다. 즉, 이러한 시스템에 데이터를 입력하고 수신하는 비즈니스 애플리케이션 계층을 말합니다. 이 범주는 규모가 크고, 제대로 분석되지 않았으며, 기업 애플리케이션 포트폴리오의 나머지 부분과는 확연히 구분됩니다.
일반적인 유틸리티 환경에서 SCADA 관련 코드는 다음과 같습니다.
정격 및 설정값 계산 프로그램. 부하 설정값, 전압 목표값, 압력 임계값 및 작동 한계를 계산하여 구성 파일 또는 직접 데이터 피드 형태로 SCADA 시스템에 제공하는 COBOL 및 PL/I 프로그램입니다. 이러한 프로그램은 규정 준수 요구 사항, 엔지니어링 사양 및 물리적 안전 한계를 반영합니다. 계산 오류가 발생하면 보고서에 잘못된 숫자가 나타나는 것이 아니라 제어 시스템이 작동하는 데 영향을 미치는 잘못된 작동 설정값이 생성됩니다.
히스토리안 데이터 소비자. 청구, 규제 보고 및 성능 분석을 위해 SCADA 히스토리안 데이터베이스에서 운영 데이터를 읽는 RPG 및 COBOL 프로그램입니다. 이러한 프로그램은 히스토리안이 생성하는 특정 데이터 형식, 타임스탬프 규칙 및 엔지니어링 단위 정의에 의존합니다. 히스토리안 출력의 형식 변경 또는 IT 측 소비자 프로그램의 변경으로 인해 청구 계산이나 규제 제출 자료가 오류 없이 손상될 수 있습니다.
프로토콜 브리지 프로그램은 메인프레임 출력 형식과 DCS(분산 제어 시스템) 및 SCADA 시스템에서 사용하는 파일 기반 또는 네트워크 기반 인터페이스 간의 변환을 수행하는 사용자 정의 C 프로그램입니다. 이러한 브리지는 Modbus, DNP3, IEC 61850, 자체 개발 벤더 형식과 같은 특정 프로토콜을 구현하며, 메시지 구조, 바이트 순서 및 타이밍에 대한 하드코딩된 가정을 포함하고 있지만, 이러한 가정은 문서 어디에도 명시되어 있지 않습니다.
배치 처리에서 실시간 처리로의 데이터 경로. 특정 시간대에 IT/OT 경계를 넘어 데이터 교환을 예약하고 순서를 지정하는 JCL 작업 스트림입니다. 예를 들어, 한 유틸리티 회사의 야간 배치 실행에서 생성된 구성 데이터는 아침 작업 시작 전에 SCADA 시스템에서 사용할 수 있어야 합니다. 이러한 시간적 종속성은 스케줄러 구성과 제어실의 운영 기대치에 내재되어 있으며, 애플리케이션 코드 어디에도 문서화되어 있지 않습니다.
경보 및 이벤트 처리 프로그램. SCADA 시스템에서 경보 기록을 수신하고, 분류 및 라우팅 로직을 적용하고, 작업 지시서를 생성하고, 규정 준수 기록을 생성하는 프로그램입니다. 경보 분류 로직, 즉 어떤 이벤트가 어떤 규정 보고서를 어떤 시간 내에 필요로 하는지에 대한 정보는 수십 년에 걸친 규정 변경 사항이 누적된 프로그램 코드에 내장되어 있는 경우가 많습니다.
이 코드는 제어 엔지니어와 IT 개발자 모두가 부분적으로 소유하고 있지만, 그 누구도 완전히 이해하지 못하는 코드입니다. 현대화 프로그램에서 "무엇을 바꿀 수 있을까요?"라고 질문할 때, SCADA 관련 코드에 대한 답은 거의 항상 "생각보다 바꿀 수 있는 것이 적고, 계획했던 것보다 더 많은 분석을 거쳐야 합니다."입니다.
표준 현대화 분석이 여기서 실패하는 이유
대부분의 기업 현대화 분석 프레임워크는 분석 대상 코드가 데이터와 비즈니스 로직만 제어하며, 프로그램 변경이 물리적 세계에 아무런 영향을 미치지 않고 데이터 결과만 바꾼다고 가정합니다. 하지만 SCADA 관련 코드는 네 가지 구체적인 방식으로 이러한 가정을 위반합니다.
데이터 오류의 물리적 결과
일반적인 청구 애플리케이션에서는 계산 오류가 발생하면 잘못된 청구서가 발행됩니다. 이러한 오류는 발견 가능하고, 되돌릴 수 있으며, 그 영향 범위도 제한적입니다. 그러나 SCADA 관련 코드에서는 계산 오류가 발생하면 제어 시스템이 압력, 전압, 유량, 온도와 같은 물리적 매개변수를 조정하여 작동하는 목표값인 설정값이 잘못될 수 있습니다. 그 결과는 단순히 데이터베이스의 잘못된 숫자에 그치는 것이 아닙니다. 물리적 프로세스가 의도된 매개변수 범위를 벗어나 작동하게 되며, 비효율성부터 장비 손상, 안전 사고에 이르기까지 다양한 결과를 초래할 수 있습니다.
데이터 오류와 물리적 결과 사이의 이러한 비대칭성은 SCADA 관련 코드를 표준 비즈니스 코드와 동일한 위험 허용 범위로 분석할 수 없는 근본적인 이유입니다. 유효한 출력을 생성하는 관점에서 "정확하게 작동하는" 변경 사항이라도 데이터 유형의 허용 범위 내에 있고 구문적으로는 유효하지만 해당 운영 맥락에서는 물리적으로 잘못된 출력을 생성할 수 있습니다.
정적 분석으로는 모델링할 수 없는 시간적 종속성
SCADA 시스템과 연관된 IT 측 프로그램은 종종 정적 분석 도구로는 파악할 수 없지만 운영상 중요한 시간 제약 조건을 갖습니다. 예를 들어, 구성 데이터를 생성하는 프로그램은 SCADA 시스템의 폴링 주기가 데이터를 읽기 전에 완료되어야 합니다. 히스토리 데이터를 집계하는 배치 작업은 규제 보고에 필요한 간격 종료 타임스탬프 이전에 완료되어야 합니다. 경보를 전달하는 브리지 프로그램은 제어실 운영 절차에 명시된 응답 시간 내에 이벤트를 처리해야 합니다.
이러한 시간 제약 조건은 소스 코드 자체가 아니라 유틸리티의 운영 절차, 스케줄러 구성, 그리고 프로그램을 작성한 개발자들의 암묵적인 이해 속에 존재합니다. 코드 구조와 데이터 흐름에 초점을 맞춘 정적 분석 도구는 코드 자체 외부에 존재하는 시간 요구 사항을 파악할 수 없습니다.
실질적인 의미는 다음과 같습니다. SCADA 관련 코드의 현대화 분석 시, 분석 범위에 포함된 모든 프로그램의 타이밍 컨텍스트를 명확하게 문서화해야 합니다. 이를 위해서는 코드 분석뿐 아니라 운영 지식, 제어실 운영자와의 인터뷰, 규정 준수 일정 검토, 스케줄러 작업 종속성 분석 등이 필요합니다.
안전 기능 식별
IEC 61511(공정 산업 분야의 기능 안전) 및 IEC 61508(전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전)은 안전 기능을 수행하는 소프트웨어에 대한 인증 요구 사항을 정의합니다. 이 표준에 따라 인증된 코드는 단순히 유지보수성을 위해 리팩토링할 수 있는 레거시 코드가 아닙니다. 인증은 특정 코드 아티팩트, 즉 인증 기관이 평가한 특정 바이너리의 특정 버전에 대한 것입니다. 비즈니스 애플리케이션에서는 중요하지 않은 품질 문제를 수정하는 경우에도 코드를 변경하면 인증이 무효화되며, 변경된 코드를 안전 기능에 배포하기 전에 재인증을 받아야 합니다.
많은 전력 회사들은 SCADA 시스템과 연계된 프로그램들을 통해 안전 관련 계산, 과압 감지, 변압기 보호 설정값 계산, 비상 차단 로직 등을 수행하고 있는데, 이러한 프로그램들이 안전 인증 요건을 충족해야 할 수도 있지만 IT 현대화 팀은 이를 인지하지 못하는 경우가 많습니다. SCADA 연계 코드에 대한 첫 번째 분석 질문은 다음과 같습니다. 이 코드 중 안전 기능을 수행하는 부분이 있는가? 있다면 어떤 기능을 수행하는가? 어떤 인증을 받아야 하는가? 그리고 코드를 변경하려면 무엇이 필요한가?
하드웨어와 프로토콜의 결합
프로토콜 브리지 프로그램과 임베디드 인터페이스 코드는 구현하는 하드웨어 및 프로토콜 버전에 직접적인 의존성을 갖습니다. 특정 제조사의 특정 RTU 모델에 대해 특정 기능 코드, 레지스터 맵, 타임아웃 값을 사용하여 Modbus RTU를 구현하는 프로그램은 Modbus를 일반적인 방식으로 구현하는 것이 아니라, 다른 구성에서는 성립하지 않을 수 있는 가정을 바탕으로 해당 특정 조합을 구현하는 것입니다.
이 코드를 현대화하기 위해 분석할 때, 의존성은 COBOL이나 C 소스 코드에만 국한되지 않고 RTU 장치 모델, 펌웨어 버전, 물리적 배선 토폴로지, 네트워크 구성에도 존재합니다. 이러한 요소 중 하나라도 변경되면 프로그램 소스 코드가 변경되지 않았더라도 인터페이스가 제대로 작동하지 않을 수 있습니다. 또한 프로그램 소스 코드를 변경하면 겉보기에는 관련이 없어 보이는 인터페이스까지 손상될 수 있는데, 이는 브리지가 특정 공급업체의 프로토콜 특성에 맞춰 작성되었지만 관련 문서가 없는 경우가 많기 때문입니다.
IT/OT 경계: 코드가 존재하는 곳
퍼듀 모델(ISA-99/IEC 62443)은 산업 제어 시스템 네트워크의 개념적 아키텍처를 레벨 0의 물리적 프로세스부터 레벨 4의 기업 비즈니스 시스템에 이르기까지 5단계로 정의합니다. 유틸리티 환경에서 SCADA와 관련된 기존 코드는 일반적으로 레벨 3과 4, 즉 제조 운영 및 기업 네트워크 영역에 존재하지만, 데이터 흐름은 양방향으로 레벨 2(SCADA 관리 계층)를 넘나듭니다.
레벨 3과 2 사이의 IT/OT 경계는 보안 및 운영 위험이 가장 높은 곳입니다. 국가 차원의 공격자들은 공격 개시 몇 달 전부터 OT 네트워크 내부에 사전 침투를 시도하며, 랜섬웨어 그룹은 이제 HMI를 잠그고 생산을 중단시키도록 설계된 ICS 인식 페이로드를 배포합니다. 가장 흔한 침입 경로는 내장된 SCADA 소프트웨어가 아니라 IT/OT 경계 계층입니다. 이 계층에서는 IT 측 코드와 OT 측 시스템이 운영 안정성을 위해 설계되었지 공격적인 보안을 위해 설계되지 않은 인터페이스를 통해 데이터를 교환합니다.
이 경계를 넘나드는 프로그램들을 정확히 파악하고, 그 프로그램들이 어떤 역할을 하는지 아는 것은 현대화 계획 수립과 보안 강화 모두에 필수적입니다. SCADA 히스토리안에서 데이터를 읽어 청구 데이터베이스에 기록하는 프로그램은 한 방향으로 경계를 넘나듭니다. 설정값을 계산하여 PLC가 읽는 구성 디렉터리에 기록하는 프로그램은 다른 방향으로 경계를 넘나듭니다. 둘 다 SCADA 시스템과 관련이 있지만, SCADA 네트워크 스캔이나 IT 애플리케이션 목록에는 나타나지 않기 때문에 체계적으로 분석이 부족한 실정입니다.
SCADA 관련 프로그램에 특화된 코드 패턴
공학 단위 계산 코드
공학 단위(EU) 계산은 아날로그-디지털 변환기에서 나오는 정수 형태의 센서 원시값을 특정 단위, 범위 및 정밀도를 가진 물리적 측정값으로 변환합니다. 압력 트랜스미터의 4-20mA 전류 루프는 원시 값을 생성하며, EU 계산은 이를 정확한 영점 및 범위 보정을 거쳐 PSI 또는 bar 단위로 변환합니다.
이 계산 코드는 표준 비즈니스 로직과 구별되는 특징을 가지고 있습니다.
코볼
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 사양에 포함되지 않은 특정 PLC 모델에 대한 네 가지 가정을 전제로 합니다. 1 기반 레지스터 주소 지정, 기능 코드 03만 사용, 최대 60개 레지스터, 그리고 대용량 요청에 대한 청킹 동작이 그것입니다. 이러한 가정들은 Modbus 문서에 나와 있지 않습니다. 이는 Modicon 984의 공급업체별 동작으로, 현재는 구할 수 없을 수도 있는 1998년 하드웨어 설명서에 기술되어 있습니다. 이러한 가정을 이해하지 못한 채 이 브리지를 현대화하거나, 표준 0 기반 주소 지정을 사용하는 최신 PLC 모델로 교체할 경우, 모든 레지스터 읽기에서 정확히 한 레지스터 주소 오프셋만큼 잘못된 값이 반환됩니다.
근대화 이전 분석: 무엇을 생산해야 하는가
SCADA 관련 코드를 수정, 리팩토링 또는 교체하기 전에, 표준적인 기업 현대화 분석에서 제공하는 것 이상의 결과물을 도출하는 분석을 수행해야 합니다.
운영 기능 목록. 모든 SCADA 관련 프로그램은 운영 기능별로 분류되어야 합니다. 예를 들어, EU 계산, 설정값 전달, 히스토리 데이터 소비, 경보 생성, 프로토콜 연결, 배치-실시간 경로 등이 있습니다. 이러한 분류를 통해 변경 프로세스에 누가 참여해야 하는지, 즉 IT 엔지니어만 참여할지, 아니면 제어 엔지니어, 운영 담당자, 규정 준수 담당자를 포함하는 다기능 팀이 참여할지를 결정할 수 있습니다.
IT/OT 경계 교차 지도. IT/OT 경계를 넘는 모든 데이터 흐름은 문서화되어야 합니다. 어떤 프로그램이 어떤 형식으로 어떤 일정에 따라 데이터를 생성하는지, 어떤 OT 시스템이 해당 데이터를 사용하는지, 그리고 데이터가 부정확하거나 지연되거나 누락될 경우 어떤 결과가 발생하는지 등을 기록해야 합니다. 이 지도는 SCADA 시스템 인접 계층에 대한 운영 위험 프로필입니다.
안전 기능 식별. 모든 프로그램은 IEC 61511, IEC 61508, NERC CIP 또는 기타 적용 가능한 표준에 따라 안전 기능을 수행하는지 여부를 평가해야 합니다. 안전 기능 코드로 식별된 프로그램은 별도의 변경 관리, 규제 기관 통보 및 재인증이 필요할 수 있으며, 이러한 프로그램의 현대화 일정은 표준 비즈니스 코드와 근본적으로 다릅니다.
하드코딩된 작동 매개변수 레지스트리. 작동 매개변수, 센서 교정 값, 경보 한계, 프로토콜 제약 조건, 타이밍 임계값 등을 나타내는 모든 하드코딩된 상수는 식별하고, 작동 의미와 함께 문서화하고, 최신 장비 사양에 따라 검증해야 합니다. 이 레지스트리는 하드코딩된 상수를 외부에서 관리되는 구성으로 대체하는 구성 관리 프로세스의 입력으로 사용됩니다.
타이밍 의존성 문서화. 모든 프로그램의 타이밍 컨텍스트, 즉 프로그램이 완료되어야 하는 운영 시간 범위, 해당 시간 범위를 강제하는 스케줄러 의존성, 그리고 프로그램 완료에 의존하는 운영 절차는 명시적으로 문서화되어야 합니다. 이 문서는 현대화된 구현의 유효성을 검증하는 데 사용되는 명세입니다.
프로토콜 및 인터페이스 명세. 모든 프로토콜 브리지 프로그램은 공급업체별 동작, 프로토콜 버전 가정, 장치별 보정 사항에 대해 분석해야 합니다. 그 결과물은 대체 구현을 검증하는 데 사용할 수 있는 명세 문서이며, 원래 명세에 포함되지 않았던 보정 동작을 포함하여 모든 보정 동작이 유지되었는지 확인합니다.
효과적인 현대화 접근법과 효과적이지 않은 접근법
신중하게 적용된 스트랭글러 피겨( Strangler Fig) 패턴은 기존 기능과 함께 새로운 기능을 구축하고, 라우팅을 점진적으로 진행하며, 단계적으로 기능을 폐기하는 방식으로, IT 측 데이터 처리(이력 데이터 소비, 요금 계산)를 수행하는 SCADA 관련 코드에 적합합니다. 전환 과정 동안 기존 프로그램은 계속 실행되며, 새로운 구현은 병렬 출력을 생성하고, 기존 프로그램이 폐기되기 전에 두 출력의 동등성을 검증합니다.
스트랭글러 그림은 실시간 경로에는 적용되지 않습니다. 실시간 데이터 경로에 있는 프로그램의 경우, 기존 프로그램과 새 프로그램을 병렬로 실행하면 서로 충돌하는 운영 효과가 발생하므로 안전하게 병렬 실행할 수 없습니다. 따라서 전환은 즉각적으로 이루어져야 하며, 프로덕션 환경으로 전환하기 전에 오프라인에서 검증해야 합니다. 현재 프로그램과 다른 값을 생성하는 병렬 설정값 계산 프로그램을 실행하면 제어 시스템에 충돌하는 설정값이 전송됩니다.
코드 변경 전에 설정값을 외부화하는 것이 좋습니다. 하드코딩된 운영 매개변수가 있는 프로그램의 경우, 가장 안전한 첫 번째 현대화 단계는 계산 로직을 변경하지 않고 해당 매개변수를 설정 파일이나 데이터베이스로 외부화하는 것입니다. 이렇게 하면 운영상 중요한 계산 코드를 건드리지 않고도 매개변수를 확인하고 관리하고 감사할 수 있습니다. 매개변수를 외부화하는 위험은 계산 로직을 리팩토링하는 위험보다 훨씬 낮습니다.
안전 기능 코드: 분석 및 문서화에 집중해야 하며, 리팩토링은 지양해야 합니다. 안전 인증을 받은 코드는 현대화 계획 단계에서 분석 및 문서화해야 하지만, 코드 변경은 규제 기관과의 협의를 거친 재인증 프로그램을 통해 진행해야 하며, 일반적인 현대화 계획의 일환으로 처리해서는 안 됩니다. 광범위한 현대화 과정에서 안전 인증이 무효화될 위험은 일반적인 현대화의 이점에 비해 정당화될 수 없습니다.
방법 SMART TS XL SCADA 관련 레거시 코드 분석을 지원합니다.
SMART TS XL의 정적 코드 분석 이 분석은 SCADA 인접 경계의 IT 측면, 즉 메인프레임 및 미드레인지 시스템에서 실행되고 OT 환경으로 데이터를 생성, 변환 또는 소비하는 COBOL, JCL, RPG, PL/I 및 C 프로그램에 적용됩니다. 이러한 코드에 대한 구조 분석을 통해 사전 현대화 분석에 필요한 운영 기능 목록과 하드코딩된 매개변수 레지스트리가 생성됩니다.
애플리케이션 종속성 매핑은 IT/OT 경계 교차 지도를 구축합니다. 여기에는 SCADA 시스템에서 사용하는 파일 인터페이스에 데이터를 쓰는 모든 프로그램, 운영 시간 측면에서 중요한 데이터를 생성하는 모든 JCL 작업 단계, OT 소스에서 IT 소비자에게 전달되는 히스토리안 데이터 경로상의 모든 프로그램이 포함됩니다. 예를 들어, 유틸리티 회사의 청구용 COBOL 프로그램이 중간 C 브리지를 통해 히스토리안 데이터를 읽을 때, 종속성 지도는 COBOL-C 종속성과 C-히스토리안 종속성을 연결된 체인으로 나타내어, 운영상의 문제 발생 시에만 파악되는 것이 아니라 전체 IT/OT 교차 경로를 시각적으로 보여줍니다.
영향 분석 기능은 SCADA 관련 코드에 특히 중요합니다. 변경 사항을 적용하기 전에 변경으로 인한 파급 효과를 파악할 수 있기 때문입니다. 경보 생성 코드, 설정값 전달 코드, 히스토리안 기록 코드와 (복사본을 통해) 공유되는 EU 계산 프로그램을 수정할 경우, 계산을 변경하기 전에 세 가지 2차적인 영향을 모두 이해해야 합니다. 일반적인 업무 코드에서는 잘못된 변경으로 인해 잘못된 데이터가 생성되지만, SCADA 관련 코드에서는 잘못된 운영 매개변수가 생성됩니다.
JCL 확장 기능을 통해 배치 계층의 타이밍 및 순서 구조를 파악할 수 있습니다. 즉, 어떤 작업이 어떤 순서로 실행되는지, 어떤 데이터 세트 출력이 후속 단계의 결과로 이어지는지, 그리고 어떤 작업 흐름이 운영 요구 사항에 따라 시간 제약을 받는지 알 수 있습니다. 이는 SCADA 관련 현대화에 필요한 타이밍 종속성 문서화의 구조적 근거가 됩니다.
엔터프라이즈 급 검색 기능을 통해 하드코딩된 파라미터 레지스트리를 대규모로 관리할 수 있습니다. 특정 엔지니어링 단위 상수, 경보 한계값, 하드코딩된 프로토콜 주소 등 환경 내 모든 COBOL, C, RPG, JCL 아티팩트에서 해당 파라미터를 수백만 줄에 걸쳐 단 몇 초 만에 찾아낼 수 있습니다. 수십만 줄에 달하는 SCADA 관련 레거시 코드를 관리하는 유틸리티 회사에게 이 검색 기능은 수개월이 걸리던 수동 감사를 단 몇 시간 만에 자동화된 인벤토리로 전환하는 데 있어 결정적인 차이를 만들어냅니다.
계획 중인 팀을 위해 레거시 현대화 유틸리티 시스템, SMART TS XL 본 보고서는 IT 측 구조 분석을 제공하여 현대화 팀이 운영 환경을 이해하는 OT 측 제어 엔지니어와 효과적으로 협력할 수 있도록 지원합니다. IT/OT 경계는 IT 팀 단독 또는 OT 팀 단독으로는 안전하게 넘을 수 없으며, 양측 모두 시스템 구성 요소에 대한 정확한 구조적 지식을 갖추고 있을 때 비로소 안전하게 넘을 수 있습니다.
이 코드가 다른 종류의 관심을 요구하는 이유
유틸리티 기업들이 SCADA 관련 레거시 코드를 현대화하는 것은 단순히 오래된 소프트웨어를 업데이트하는 것이 아닙니다. 비즈니스 시스템과 물리적 인프라를 연결하는 소프트웨어 계층을 변경하는 것입니다. 이 과정에서 오류가 발생할 경우 데이터 오류, 서비스 중단, 재정적 손실에 그치지 않고, 유틸리티 서비스에 의존하는 사람들의 삶을 좌우하는 물리적 시스템에까지 영향을 미칠 수 있습니다.
이 코드를 특별하게 만드는 특징들, 즉 데이터 오류의 물리적 결과, 정적 분석으로는 파악할 수 없는 타이밍 종속성, 안전 인증 제약 조건, 하드웨어 및 프로토콜 결합은 이 코드를 현대화하지 말아야 할 이유가 아닙니다. 오히려 이러한 요소들은 변경하기 전에 코드를 완전히 이해해야 한다는 것을 보여주는 근거입니다. 이 가이드의 분석 프레임워크는 바로 그러한 이해를 가능하게 합니다. 이를 바탕으로 진행되는 현대화 프로그램은 변경 범위가 추측이 아닌 증거에 기반하여 정의되고, 타이밍 종속성이 암묵적인 것이 아닌 문서화되며, 안전 기능 코드가 우연히 수정되는 것이 아니라 식별되고, IT/OT 경계 교차점이 배포 후 운영 사고를 통해 발견되는 것이 아니라 매핑되기 때문에 더욱 안전합니다.