公益事業組織におけるIT/OT境界は、ネットワーク図上の明確な境界線ではありません。それは、データが双方向に流れる透過性のある膜のようなものです。COBOLバッチプログラムはPLCが消費する設定値構成ファイルを生成し、RPGプログラムは課金および規制報告のためにSCADA履歴データを読み取り、レガシーCブリッジはメインフレームの出力を分散制御システムが理解できる形式に変換し、JCLジョブストリームは運用プロセスが依存するタイミングに基づいて境界を越えたデータ交換をスケジュールおよびシーケンスします。この流れを管理するソフトウェアは、純粋にITでも純粋にOTでもありません。それは公益事業を機能させる結合組織であり、変革プログラムが開始されたときに近代化チームが分析する準備が最もできていないコードカテゴリです。
エネルギー分野は、その歴史上最も大きなデジタル変革の一つを経験しています。電力会社がスマートグリッド、接続された変電所、ICS、高度な自動化によってインフラを近代化するにつれ、OTネットワークはかつてないほど相互接続されています。この相互接続によってレガシーコード層がなくなるわけではなく、むしろその重要性が高まります。なぜなら、新しいスマートグリッドのエンドポイントやクラウド分析プラットフォームはすべて、数十年前のアプリケーションから得られるデータフィードに依存しているからです。運用データチェーンにおけるこれらのアプリケーションの役割を理解せずに近代化することは、近代化ではなく、データセンターだけでなく物理インフラにも影響を及ぼす混乱を招くことになります。
ハードコードされたすべての運用パラメータを見つける
SMART TS XL 既存のコードポートフォリオに埋め込まれているすべてのEU定数、アラーム制限値、およびプロトコルアドレスを特定します。
さらに詳しく…「SCADA隣接」とは実際にはどういう意味なのか
SCADA隣接という用語は、運用技術システムとインターフェースするIT側のソフトウェアを指し、SCADAソフトウェア自体、PLCファームウェア、RTU組み込みコードではなく、これらのシステムにデータを供給し、これらのシステムからデータを受信するビジネスアプリケーション層を指します。このカテゴリは規模が大きく、十分に分析されておらず、エンタープライズアプリケーションポートフォリオの他の部分とは根本的に異なります。
一般的な公益事業環境において、SCADA関連コードには以下が含まれます。
レートおよび設定値計算プログラム。負荷設定値、電圧目標値、圧力閾値、および動作制限値を計算するCOBOLおよびPL/Iプログラムは、構成ファイルまたは直接データフィードとしてSCADAシステムに提供されます。これらのプログラムは、規制遵守要件、エンジニアリング仕様、および物理的な安全制限値をエンコードします。計算が誤っていると、レポートに誤った数値が表示されるのではなく、制御システムが動作する動作設定値が誤って表示されます。
ヒストリアンデータコンシューマー。RPGおよびCOBOLプログラムは、課金、規制報告、およびパフォーマンス分析のために、SCADAヒストリアンデータベースから運用データを読み取ります。これらのプログラムは、ヒストリアンが生成する特定のデータ形式、タイムスタンプ規則、およびエンジニアリング単位定義に依存しています。ヒストリアンの出力形式の変更、またはIT側のコンシューマープログラムの変更は、課金計算や規制提出書類を意図せず破損させる可能性があります。
プロトコルブリッジプログラム。メインフレームの出力フォーマットと、DCS（分散制御システム）やSCADAシステムが利用するファイルベースまたはネットワークベースのインターフェースとの間で変換を行うカスタムCプログラム。これらのブリッジは、Modbus、DNP3、IEC 61850、ベンダー独自のフォーマットなど、特定のプロトコルを実装しており、メッセージ構造、バイト順序、タイミングに関するハードコードされた前提条件が含まれていますが、これらはドキュメントには記載されていません。
バッチ処理からリアルタイム処理へのデータパス。JCLジョブストリームは、特定のタイミングウィンドウ内でIT/OT境界を越えたデータ交換をスケジュールおよびシーケンス化します。電力会社の夜間バッチ処理では、朝の運用開始前にSCADAシステムで利用可能にする必要がある構成データが生成されます。このタイミング依存性は、スケジューラ構成と制御室の運用上の期待に暗黙的に組み込まれており、アプリケーションコードのどこにも文書化されていません。
警報およびイベント処理プログラム。SCADAシステムから警報記録を受信し、分類およびルーティングロジックを適用し、作業指示書を生成し、規制遵守記録を作成するプログラム。どのイベントがどの規制報告をどの期間内に必要とするかといった警報分類ロジックは、数十年にわたる規制変更が蓄積されたプログラムコードに組み込まれていることが多い。
これは、エンジニアとIT開発者が部分的に所有しながらも、どちらも完全に理解していない制御コードです。近代化プログラムで「何を変更できるか？」と問われた場合、SCADA関連コードに対する答えは、ほぼ常に「思ったより少なく、しかも計画以上に分析を重ねた後でなければ変更できない」となります。
標準的な近代化分析がここで失敗する理由
ほとんどの企業近代化分析フレームワークは、分析対象のコードがデータとビジネスロジックのみを制御し、プログラムの変更によって物理世界への影響はなく、データ結果のみが異なると想定しています。SCADA関連コードは、この想定を4つの具体的な方法で覆します。
データエラーの物理的影響
標準的な請求アプリケーションでは、計算ミスは誤った請求書を作成するだけです。このエラーは発見可能で、修正可能であり、影響範囲も限定的です。一方、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に変換します。
この計算コードには、標準的なビジネスロジックとは異なる特徴があります。
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.この計算における定数は、 SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSIこれらは、物理的な計測器の仕様に対応しています。これらがハードコーディングされている場合（レガシーコードではよくあることですが）、物理的な計測器に変更があると、コードも変更する必要があります。これらが間違っている場合（計測器の再校正、交換、または初期設定の誤りなどが原因で）、プログラムがこれまでに生成したすべてのレコードで EU 値が常に不正確になります。静的解析によってこれらの定数が定義されている箇所を特定できますが、現在の計測器構成に対して正しいかどうかは、運用検証によってのみ確認できます。
警報生成および分類ロジック
警報生成コードは、公益事業環境におけるSCADA関連コードの中でも、規制上の制約が最も厳しいものの1つです。電力会社向けのNERC CIP（重要インフラ保護）基準、原子力施設向けのNRC要件、上下水道事業者向けのEPA報告要件など、いずれもどの事象で警報を生成する必要があるか、警報にどのような情報を含める必要があるか、そしてどのくらいの時間内に報告する必要があるかを規定しています。
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.このコードにおけるアラーム制限値は、 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モデルに関する4つの前提条件が組み込まれています。それは、1ベースのレジスタアドレス指定、ファンクションコード03のみ、最大60レジスタ、および大きな要求に対するチャンキング動作です。これらの前提条件はModbusのドキュメントには記載されていません。これらはModicon 984のベンダー固有の動作であり、1998年のハードウェアマニュアルに記載されていますが、現在は入手できない可能性があります。これらの前提条件を理解せずにこのブリッジを近代化した場合、またはPLCを標準の0ベースのアドレス指定を使用する新しいモデルに交換した場合、読み取ったすべてのレジスタの値が、正確に1レジスタアドレスオフセットだけずれた誤った値を返します。
近代化以前の分析：何を生産しなければならないか
SCADA関連コードの変更、リファクタリング、または置換を行う前に、分析によって、標準的な企業近代化分析が提供する以上の成果物群が生成されなければならない。
運用機能のインベントリ。SCADA関連プログラムはすべて、EU計算、設定値配信、履歴データ消費、アラーム生成、プロトコルブリッジ、バッチ処理からリアルタイム処理へのパスウェイといった運用機能ごとに分類する必要があります。この分類により、変更プロセスに関与する担当者（ITエンジニアのみ、または制御エンジニア、運用スタッフ、規制遵守担当者を含むクロスファンクショナルチーム）が決まります。
IT/OT境界交差マップ。IT /OT境界を越えるすべてのデータフローは文書化する必要があります。どのプログラムが、どのような形式で、どのようなスケジュールでデータを生成するのか、どのOTシステムがそれを利用するのか、そしてデータが不正確、遅延、または欠落した場合にどのような結果が生じるのかを明記する必要があります。このマップは、SCADA隣接レイヤーの運用リスクプロファイルです。
安全機能の識別。すべてのプログラムは、IEC 61511、IEC 61508、NERC CIP、またはその他の適用規格に基づき、安全機能を備えているかどうかを評価する必要があります。安全機能コードとして識別されたプログラムは、別途変更管理、規制当局への通知、場合によっては再認証が必要となり、これらのプログラムの近代化スケジュールは、標準的な業務コードとは根本的に異なります。
ハードコードされた動作パラメータレジストリ。動作パラメータ、センサー校正値、アラーム制限値、プロトコル制約、タイミング閾値などを表すすべてのハードコードされた定数は、識別され、その動作上の意味とともに文書化され、現在の機器仕様に対して検証される必要があります。このレジストリは、ハードコードされた定数を外部管理された構成に置き換える構成管理プロセスへの入力となります。
タイミング依存関係の文書化。すべてのプログラムのタイミングコンテキスト、プログラムが完了する必要のある動作ウィンドウ、そのウィンドウを強制するスケジューラの依存関係、プログラムの完了に依存する動作手順は、明示的に文書化されなければなりません。この文書は、最新の実装を検証するための仕様となります。
プロトコルおよびインターフェースの仕様。すべてのプロトコルブリッジプログラムは、ベンダー固有の動作、プロトコルバージョンの前提条件、およびデバイス固有の補正について分析する必要があります。出力は仕様書であり、代替実装の検証に使用できます。この仕様書は、元の仕様に含まれていなかったものも含め、すべての補正動作が維持されていることを確認します。
効果的な近代化アプローチと効果のない近代化アプローチ
慎重に適用された絞め殺しイチジクパターン。古い機能と並行して新しい機能を構築し、段階的にルーティングを行い、徐々に廃止していく絞め殺しイチジクパターンは、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計算プログラムを変更する場合、計算に手を加える前に、これら3つの二次的な影響すべてを理解しておく必要があります。通常の業務コードでは、誤った変更は誤ったデータを生成します。SCADA関連コードでは、誤った運用パラメータが生成されます。
JCL展開機能により、バッチ層のタイミングとシーケンス構造が明らかになります。つまり、どのジョブがどのような順序で実行されるか、どのデータセットの出力が後続のどのステップに供給されるか、そしてどのジョブストリームが運用要件によって時間的に制約されているかが分かります。これは、SCADA関連の近代化に必要なタイミング依存関係のドキュメント作成のための構造的な根拠となります。
エンタープライズ検索機能により、ハードコードされたパラメータレジストリを大規模に管理することが可能になります。環境内のあらゆる COBOL、C、RPG、JCL アーティファクトから、特定のエンジニアリング単位定数、アラーム制限値、ハードコードされたプロトコル アドレスを、数百万行のコードにわたって数秒で検索できます。数十万行もの SCADA 関連のレガシー コードを管理する電力会社にとって、この検索機能は、数ヶ月かかる手動監査と数時間で完了する自動インベントリとの違いを生み出します。
計画中のチーム向け レガシーの近代化 公益事業システムの SMART TS XL このサービスは、IT側の構造分析を提供することで、近代化チームが運用状況を理解しているOT側の制御エンジニアと効果的に連携できるよう支援します。IT/OT境界は、ITチーム単独でもOTチーム単独でも安全に越えられるものではなく、両者がそれぞれのシステムに含まれる構造を正確に把握している場合にのみ安全に越えられるのです。
なぜこのコードは、これまでとは異なる種類の注意を必要とするのか
SCADA関連のレガシーコードを近代化する電力会社は、単に古いソフトウェアを更新しているわけではありません。業務システムと物理インフラストラクチャの間を取り持つソフトウェア層を変更しているのです。これを誤ると、データエラー、サービスの中断、金銭的損失といった事態にとどまらず、電力会社に依存して生活する人々の生活を支える物理システムにも影響が及ぶ可能性があります。
このコードを特別なものにしている特性、すなわちデータエラーの物理的な影響、静的解析では見えないタイミング依存性、安全認証の制約、ハードウェアとプロトコルの結合などは、このコードを近代化することに反対する理由ではありません。むしろ、変更を加える前に完全に理解しておくべき理由なのです。このガイドで紹介する分析フレームワークは、まさにその理解をもたらします。このフレームワークに基づく近代化プログラムは、変更範囲が仮定ではなく証拠に基づいて定義され、タイミング依存性が暗黙のうちにではなく文書化され、安全機能コードが誤って変更されるのではなく特定され、IT/OT境界の交差が展開後の運用上のインシデントを通じて発見されるのではなくマッピングされるため、より安全になります。
