パトリオットのクロックドリフトと戦場の説明責任

概況

1991年2月25日、ダーランのパトリオット砲台が飛来するイラクのスカッドミサイルの追跡と迎撃に失敗した。米国会計検査院(GAO)は、兵器管制コンピュータのソフトウェア問題が不正確な追跡計算を引き起こし、連続稼働時間とともに悪化したと結論付けた。スカッドは陸軍兵舎に着弾し、GAO は28人の米国人が死亡したと報告した。
技術的メカニズムは有限精度の時間変換であった。システムは0.1秒単位で時刻を保持し、レンジゲート計算のために増加する大きな整数クロック値を変換していた。その24ビットレジスタが変換の精度を制限していた。ダーランの砲台が100時間以上連続稼働した後、累積時間誤差は約0.3433秒となり、予測レンジゲートは約687メートルずれていた。
この誤差は機関的に可視化されつつあった。2月11日に受信したイスラエルのデータは、8時間後に有意なレンジゲートシフトを示していた。2月16日に補償ソフトウェア修正がリリースされ、2月21日のメッセージは非常に長い稼働時間がレンジゲートをシフトさせる可能性があると警告した。しかし、警告は「非常に長い」を定義しておらず、当局は砲台が故障するほど長く稼働し続けることはないと想定し、修正ソフトウェアがダーランに到着したのは攻撃の翌日である2月26日であった。
したがって、説明責任は算術を超えて拡張される。それは数値表現、耐久性の想定、異常分析、運用限界、警告内容、再起動権限、ソフトウェア配布、ユニット構成、および修正措置が必要とされる前に砲台に届いたことの証明に対する管理に及ぶ。小さな計算誤差は、技術的および運用上の制御システムが配備条件下でそれを制限しなかったために壊滅的なものとなった。

ダーランが稼働時間を安全重要状態に変えた

ソフトウェアの稼働時間はしばしば信頼性の証拠と見なされる。何日も利用可能であり続けたシステムは、最近再起動したシステムよりも信頼できるように見えるかもしれない。ダーランのパトリオットの失敗はその逆の可能性を露呈する。経過時間自体が増大する危険性となり得る。内部計算がクロック値の増加に伴って精度を失う場合、継続運転は中立的ではない。システムの状態を変化させる。どのコンポーネントも目に見えてクラッシュせず、オペレーターがアラームを見なくても。

GAO の1992年2月の報告書は中心的な出来事を確立した。1991年2月25日、サウジアラビアのダーランで運用されていたパトリオットミサイル防衛システムが、飛来するスカッドミサイルの追跡と迎撃に失敗した。ミサイルは米陸軍兵舎に着弾した。GAO は28人の米国人が死亡したと報告した。その調査は、ソフトウェア問題が関与していたかどうか、問題は何か、そしてそれを修正するために何が行われたかを判断するために依頼された。

報告書の回答は直接的であった。兵器管制コンピュータのソフトウェア問題が不正確な追跡計算を引き起こし、それはシステムの稼働時間が長くなるほど悪化した。インシデント発生時、砲台は100時間以上連続稼働していた。累積された不正確さにより、システムは飛来する目標を間違った場所で探すことになった。

その記述が重要なのは、このケースを完全な電力喪失、フリーズしたディスプレイ、または従来のクラッシュと区別するからである。パトリオット砲台は稼働中のシステムであり続けた。危険な劣化は、レーダー処理が次にどこを探すべきかを決定するために使用される計算の内部に存在していた。したがって、システムは管理的な意味では稼働している（電源が入り、人員が配置され、利用可能である）が、特定の安全機能に対しては運用上不適格になり得る。

説明責任の問題は、単にコンピュータが不完全に分数を表現した理由ではない。バイナリマシンは、固定ビット数内で正確に表現できない量を日常的に近似する。より難しい問題は、なぜその近似が生きた防衛任務において安全な限界を超えて蓄積することを許され、ソフトウェア、運用、および現場サポートを管理する組織が既知の限界を配備ユニットの保護に変換しなかったのかである。

公式記録が確立すること

GAO 報告書は、ダーランのソフトウェアに関する発見の主要な権威として残るべきである。それは民間伝承から組み立てられた回顧的な教室の逸話ではなかった。GAO はパトリオットソフトウェア保守を担当する当局者にインタビューし、陸軍の分析を検討し、アーキテクチャおよびアセンブリ言語の資料を調査し、不正確さに関連する機械語命令を分析し、修正計算をチェックし、パトリオットソフトウェアテスト施設でのシミュレーションに参加した。報告書は、当局者は概ね提示された事実に同意したと述べている。

それは、報告書が湾岸戦争中のパトリオットの性能に関するすべての論争を解決するという意味ではない。システムのより広範な迎撃記録は、政治的、技術的、および証拠上の論争の対象となった。他の交戦が飛来する弾頭を破壊したかどうかに関する主張は、異なる証拠、定義、および因果関係の問題を含む。それらの議論は、互換性があるかのようにダーランのソフトウェア事件に持ち込まれるべきではない。

このインシデントについて、GAO はより狭く、十分に裏付けられた連鎖を説明した。兵器管制コンピュータはレーダーからの目標情報を使用した。レンジゲートアルゴリズムは、システムが次にスカッドの可能性があるものを探すべき領域を計算した。その計算された領域外のデータはフィルタリングされ、内部の情報は追跡、照準、および迎撃をサポートした。予測は目標の速度と最後のレーダー検出時間に依存していた。

システムクロックは0.1秒単位で時刻を整数として保持していた。追跡計算では時間と速度を実数として表現する必要があった。コンピュータのレジスタが24ビット長であったため、時間値の変換に精度の低下が生じた。その影響は稼働時間と目標速度の両方で増大した。長時間の運用により、計算されたレンジゲートが目標の実際の位置からずれた。

GAO は次に計算を現場の結果に結び付けた。アルファ砲台は100時間以上連続稼働していた。レンジゲートは大きくずれ、砲台は飛来するスカッドを追跡できず、したがって迎撃しなかった。これがソフトウェア障害の公式の因果的境界である。分析はそこからガバナンスの教訓を引き出すことができるが、追加の戦場命令、個人の動機、または文書化されていない決定をでっち上げるべきではない。

数値誤差は計算ごとには小さく、文脈上は大きかった

算術はしばしば「丸め誤差」というフレーズに圧縮される。そのフレーズは方向としては正しいが、制度的には不完全である。それは無害な小数点以下の不一致やプログラマーの孤立したミスを示唆する。実際のリスクは、表現、蓄積、目標速度、連続使用の相互作用から生じた。

システムは時間を0.1秒単位でカウントしていた。0.1秒はバイナリでは有限の正確な表現を持たない。ちょうど3分の1が10進数で有限の正確な表現を持たないのと同じである。コンピュータは近似値を保存しなければならない。パトリオットコンピュータのアーキテクチャは、追跡計算で使用される変換に利用可能な精度を制限していた。各変換は意図された値に近かったが、同一ではなかった。

経過時間は、システムがオンである間に増加する整数で表現された。そのより大きなクロックカウントが制限精度の近似を使用して変換されたとき、計算された時間と実際の時間の間の絶対差も増加した。ソフトウェアはある瞬間から次の瞬間に注意深さを失う必要はなかった。同じ表現方法がより大きな運用誤差を生成した。なぜなら、それがより大きな経過時間値に適用されたからである。

GAO の付録は進行を定量化した。1時間後、計算された時間は約0.0034秒短く、約7メートルのレンジゲートシフトに対応した。8時間後、報告書は約0.0275秒の時間不正確さと約55メートルのシフトを挙げた。20時間後、不正確さは約0.0687秒、シフトは約137メートルであった。100時間では、計算は約0.3433秒短く、近似シフトは687メートルであった。

これらの数字は、「ほんの数分の一秒」がなぜ間違ったリスク枠組みであるかを示している。数分の一秒は、目標の速度と時間値を消費するロジックに対して評価されなければならない。GAO は、この運用コンテキストではスカッドが約マッハ5で移動すると説明した。高速で移動する目標は、短い時間間隔の間に結果的な距離をカバーする。レンジゲートの役割は、レーダー処理が次にどこを探すかを制限することであった。予測誤差がそのゲートを目標から十分に遠くに移動させると、実際の目標は関連性があるとして扱われる領域の外側に落ちる可能性がある。

結果は単により洗練されていない推定ではなかった。それはシステムが目標として認識できるものを変えた。計算は、物体が識別され、追跡され、射程内にあると見なされるかどうかを決定するのに役立った。したがって、数値近似は、交戦に直接的な結果をもたらす決定境界の内側にあった。

これは繰り返し現れる安全原則である。誤差の大きさは、計算と行動の間の伝達関数から切り離して評価することはできない。小さな時間誤差は給与バッチでは重要でないかもしれないが、衝突回避、医療投薬、産業制御、またはミサイル追跡では壊滅的となり得る。エンジニアリング保証は、数値誤差を最悪の信頼できる運用状態におけるドメイン効果に変換しなければならない。

設計上の想定が宣言されていない運用限界になった

GAO は、パトリオットは当初、機動式防空システムとして設計されたと報告した。その初期の運用概念は移動と1か所での数時間の運用を想定していた。湾岸戦争中、砲台は資産、人員、民間人をスカッド攻撃から保護するために比較的恒久的な位置に配置された。システムはまた、その本来の任務を定義していなかった目標クラスと飛行プロファイルに対して使用されていた。

これは適応が本質的に無責任であったという証明ではない。配備されたシステムはしばしば変化した脅威に対応するよう求められる。これは、元の運用エンベロープに基づく保証が、静かにシステムに従って異なるエンベロープに入ることができないという証拠である。数時間ごとに再起動または再配置されることが期待される機動システムには、長時間の動作が安全重要として扱われなかった状態変数が含まれている可能性がある。何日も継続的に利用可能に保たれた砲台は、異なる耐久性要件を生み出す。

したがって、クロックドリフトは設計想定と現場ドクトリンの間のインターフェース障害でもあった。ソフトウェアは、経過時間がどの程度大きくなるかについての想定を具現化していた。戦時中の慣行ははるかに大きな値を作り出した。どちらか一方だけでは安全性を定義しない。システムは、配備された運用パターンが検証されたエンベロープ内に留まるか、エンベロープが拡張される前にソフトウェアと手順が変更された場合にのみ安全である。

算術に暗黙的にのみ存在する運用期間制限は、効果的な制限ではない。オペレーターは与えられなかった閾値を遵守できない。指揮官は、ドクトリンに変換されていない数値の周りで交代、再起動ウィンドウ、または重複カバレッジを計画できない。ロジスティクスチームは、どのユニットが危険な状態に近づいているかを知らされなければ、ソフトウェア修正を優先順位付けできない。

したがって、ダーランのケースは、誰が運用エンベロープを所有していたのかを問う。ソフトウェア保守担当者は計算の知識を管理していた。プロジェクトオフィスは異常データを分析し、コードを変更できた。運用コマンドは砲台が実際にどのように運用されているかを知っていた。配備ユニットは、与えられた権限と脅威条件の範囲内で即時の構成と再起動アクションを管理していた。陸軍上級指導部は警告と更新を配布するシステムを管理していた。安全性はこれらのビューが調整されることに依存していた。

関連する要件は単に「スカッドを追跡する」ではなかった。それは「戦時配備が要求する可能性のある最長の連続運用期間にわたって必要な追跡精度を維持する」に近かった。その耐久条件が明示的であったならば、数値誤差分析、長期テスト、現場指示、および構成報告が同じ測定可能な境界に対して評価できたであろう。

攻撃前にイスラエルのデータがリスクを可視化した

欠陥はダーランの後でのみ知られるようになったわけではない。GAO はインシデント前に受け取った現場証拠を説明した。1991年2月11日、パトリオットプロジェクトオフィスは、8時間の連続運転後にレーダーレンジゲートの20%シフトを特定するイスラエルのデータを受け取った。イスラエル管理下のシステムは外部データレコーダーを使用しており、陸軍の分析に有用な情報を提供した。

プロジェクトオフィスの当局者は、レンジゲートシフトが50%以上に達するとシステムはスカッドを追跡しないと述べた。シフトは稼働時間に比例するため、8時間の結果から外挿できた。GAO は、約20時間の連続使用後、不正確な時間計算がレーダーを間違った場所を探すのに十分な大きさになったと報告した。

そのシーケンスは古典的な異常エスカレーションテストである。証拠は存在したが、証拠は制御された決定に変換されるまでシステムを保護しない。初期の20%シフトは、即時故障ではなく劣化マージンとして説明できる。しかし、その重要性は誤差の軌道に依存していた。既知の故障閾値を持つ増大する誤差は、単なる観察ではなく予測を必要とする。

GAO は、陸軍当局者は当初、イスラエルの経験は非典型的であると信じていたと報告した。彼らは他のユーザーが8時間以上システムを運用していないと想定した。その信念は運用上の想定であり、ダーランのアルファ砲台にとっては間違っていた。そのユニットは最終的に100時間以上連続運用されていた。

ガバナンスの失敗は、当局者がすべての証拠を無視したことではなかった。彼らはデータを分析し、精度の低下を確認し、ソフトウェア変更を行った。ギャップは、異常がすべての露出したユニットに修正が届く前に完全で現場で実施可能な安全対応を生み出さなかったことである。GAO は、当局者はイスラエルのデータを使用して、不正確な計算がシステムを効果的にしなくなるまでにパトリオットがどれだけ運用できるかを判断しなかったと述べた。

その区別は重要である。修正開発と中間リスク管理は別々の責任である。パッチが準備されている間、組織は問題が解決に向かっているかのように行動するかもしれない。配備されたユニットは、修正された構成がインストールされるか、効果的な緩和策が実施されるまで露出したままである。欠陥確認から艦隊全体へのインストールまでの時間は、それ自体が管理された危険間隔である。

警告はオペレーターが必要とする閾値を述べていなかった

2月21日、パトリオットプロジェクトオフィスはユーザーにメッセージを送り、非常に長い稼働時間がレンジゲートをシフトさせ、目標をオフセットする可能性があると述べた。メッセージはまた、目標設定を改善するためにソフトウェア変更が送られていると述べた。GAO は決定的な弱点を特定した。メッセージは何が「非常に長い」とみなされるかを指定していなかった。

定性的な言語は懸念を伝えることができるが、行動を可能にしない。「非常に長い」はソフトウェアアナリストには8時間を意味し、指揮官には1日を、絶え間ない脅威の下で運用する乗組員には数日を意味するかもしれない。運用上の警告は、危険を測定可能な状態と必要な対応に結び付けなければならない。リスクが許容できなくなる時期、ユニットが何をすべきか、誰がその行動を承認できるか、およびコンプライアンスがどのように記録されるかを述べるべきである。

陸軍当局者は GAO に、ユーザーが故障するほど長く連続して砲台を運用することはないと想定していたため、より詳細なガイダンスは必要ないと考えたと語った。その想定は、警告設計が危険に関与する同じ想定に依存できない理由を示している。現場の慣行が不確かな場合、警告プロセスはそれを検証すべきである。確認応答には、ユニットの現在の稼働時間、ソフトウェアバージョン、および計画された緩和策を含めるべきであり、単にメッセージが受信されたことの確認だけではない。

ダーラン砲台の実際の状態（100時間以上の連続稼働）は、予測された20時間の追跡喪失点の微妙な端ではなかった。それをはるかに超えていた。警告をユニット状態に一致させることができる制御システムは、アルファ砲台を緊急と特定したはずである。

ここで説明責任は証拠に基づくものとなる。本部が一般的なメッセージを送信したことを示すだけでは十分ではない。関連する証明は、露出したユニットが理解可能な制限を時間内に受け取り、その結果を理解し、行動する権限と機会を持ち、完了を報告したかどうかである。送信ログはその連鎖の始まりのみを証明する。

安全重要ソフトウェアの警告は、バージョン管理された運用指令であるべきである。欠陥識別子、影響を受ける構成、観察可能なトリガー、最大安全状態、緩和策、責任者、期限、受信確認、および閉鎖証拠が必要である。閾値が時間依存である場合、警告は現在の稼働時間の報告も要求すべきである。そうでなければ、中央のリスク変数はそれを制御しようとする組織に不可視のままである。

再起動は緩和策であったが、完全な制御システムではなかった

GAO は、パトリオットシステムを数時間ごとに再起動すると、コンピュータクロックをゼロに再初期化することにより、有意なレンジゲートシフトを排除できると報告した。再起動には約60～90秒かかると説明した。純粋に技術的な観点からは、それは蓄積された経過時間誤差に対する単純な緩和策であった。

運用上、「再起動する」は自己実行可能ではない。防空砲台は継続的な保護を提供するために存在する。短い中断でも、現在の警報、他の砲台からのカバレッジ、指揮権限、および乗組員のワークロードに対して調整する必要があるかもしれない。同じ報告書は、ソフトウェア修正のインストールには少なくとも1～2時間のシステム停止が必要であり、明らかな計画上の影響があると述べた。

これは、特定の瞬間に再起動が不可能であったり、オペレーターが利用可能な命令を拒否したことを確立するものではない。ソースセット内の公開証拠はその主張を支持しない。それは、緩和策が制御として信用される前にドクトリンに変換されなければならない理由を示している。

信頼できる再起動制御は、危険閾値を下回る最大稼働時間を特定し、その限界が近づくにつれて警告し、誰が再起動を命令するかを指定し、一時的なカバレッジを調整し、クロックがリセットされたことを確認し、新しい開始時刻を記録する。継続的な保護が再起動を許容しない場合、組織は重複容量を提供するか、修正ソフトウェアのインストールを加速しなければならない。現場の乗組員が不正確な警告から手順を推測することを期待して危険を管理することはできない。

技術的に簡単な緩和策の存在は、時には制度的対応を弱める可能性がある。意思決定者は、システムの近くの誰かが非公式に問題を解決できると想定するかもしれない。その想定は、指示、権限、または証拠を移すことなく責任を移す。安全ケースでは、緩和策は運用条件下で実現可能であり、実証可能に実施された場合にのみカウントされる。

ソフトウェア修正は攻撃前に存在したが、攻撃後に到着した

イスラエルのデータを分析した後、パトリオットプロジェクトオフィスは不正確な時間計算を補償し、長時間の稼働を可能にするソフトウェア変更を開発した。GAO は修正バージョンが1991年2月16日にリリースされたと報告した。それはダーランに2月26日に到着した。致命的な攻撃の翌日である。

陸軍当局者は、配布の遅れは戦時環境においてすべてのパトリオット所在地への航空および地上輸送を手配するのに必要な時間によるものだと述べた。そのコンテキストは関連する。物理的なソフトウェアメディア、技術サポート、または管理された構成変更を戦域全体に配達することは、日常的な消費者アップデートの配布と同じではない。しかし、運用上の困難は露出を消し去らない。それは安全プロセスが管理しなければならないロジスティクス要件を定義する。

リリースからダーランインシデントまでの9日間の間隔は、構成リスクウィンドウとして扱われるべきである。そのウィンドウの間、一部のユニットは持続時間依存の追跡問題があることが知られているソフトウェア上に残っていた。成熟したプロセスは、影響を受ける砲台、そのソフトウェアバージョン、現在の稼働時間、ミッションクリティカリティ、更新出荷状況、および中間緩和策のライブインベントリを維持するであろう。

優先順位は、単なる標準的な配布順序ではなく、リスクに従うべきである。すでに予測された安全運用期間を超えているユニットは即時の注意を必要とする。修正バージョンがすぐに到着できない場合、コマンドシステムは再起動スケジュールまたは他の承認された措置を強制する必要がある。各ユニットは明示的な状態を経るべきである。影響を受けている、警告済み、緩和済み、更新発送済み、更新受信済み、インストール済み、機能確認済み、クローズ済み。

ダーランのケースは、現在一般的に理解されているようなネットワーク配信ソフトウェア運用に先行するが、説明責任の問題は現在も続いている。ベンダーまたはプロジェクトオフィスは、インストールベースが脆弱なままである間に修正をリリースするかもしれない。「パッチ利用可能」は「リスク除去」と同じではない。結果重大性の高いシステムを担当する組織は、ラストマイルでの証拠を必要とする。

同じロジックは、病院、産業プラント、公共安全ネットワーク、および重要インフラにも適用される。本部に座っている修正コードはリモートシステムを保護しない。安全性は、配布時間、ローカル権限、インストール機会、互換性テスト、および結果の構成の証明に依存する。

限られた性能記録が学習を弱めた

GAO はまた、証拠の制約を説明した。パトリオットには、詳細な性能情報を保持する組み込みの内部データレコーダーがなかった。ポータブル外部レコーダーは利用可能であったが、米国の指揮官はレコーダーが予期しないシステムシャットダウンを引き起こす可能性があるという懸念から使用しないことを決定した。イスラエルの指揮官はレコーダーを使用し、レンジゲート異常を明らかにするのに役立つデータを提供した。

その決定は現実の安全トレードオフを示している。生きている兵器システムに計装を追加することは、それ自体のリスクを生み出す可能性がある。運用を妨害する可能性のあるレコーダーは無害として扱うことはできない。しかし、データ収集を拒否することにもコストがかかる。劣化は不可視のままであり、異常分析は遅くなり、事後再構築は不確実になる。

説明責任のあるエンジニアリングは、このトレードオフが明示的に行われることを要求する。好ましいレコーダーが日常的な使用にはリスクが高すぎる場合、代替の証拠経路が必要である。それには、独立して検証されたパッシブ計装、スケジュールされた診断収集、代表的な長時間状態を使用したラボリプレイ、選択された砲台での冗長記録、または交戦を妨害せずに異常データをキャプチャするための正式な計画が含まれる可能性がある。

重要な点は、指揮官が常により多くのテレメトリを選択すべきであるということではない。それは、新しい目標と新しい運用パターンに適応する結果重大性の高いシステムには、定義された学習システムが必要であるということである。砂漠の嵐作戦中、運用経験が蓄積されるにつれてソフトウェアは繰り返し修正された。GAO は1990年8月から1991年2月の間に6つのソフトウェア修正を報告した。迅速な適応は、信頼できる性能証拠と構成トレーサビリティの重要性を高める。

適切な記録がなければ、組織はユーザーレポート、想定、および孤立した観察により大きく依存する。それにより、異常を非典型的として却下しやすくなり、変更が艦隊全体で機能したかどうかを判断するのが難しくなる。したがって、証拠収集は保護システムの一部であり、単に失敗後の歴史家のためのリソースではない。

説明責任は実践的な管理に従う

ダーランの連鎖のすべてのリンクを管理した単一の役割はなかった。それがまさにシステム説明責任モデルが必要な理由である。分散された責任は希釈された責任になるべきではない。

ソフトウェアおよびハードウェアエンジニアリングは、表現の選択、24ビット制限の知識、修正アルゴリズム、および修正された計算の検証を管理していた。彼らの義務は数学的な完全性を保証することではなかった。それは、信頼できる運用範囲にわたって誤差限界を特定し、追跡が必要な許容範囲内に留まることを示すことであった。

パトリオットプロジェクトオフィスは、異常分析、ソフトウェア保守、および警告と配布の重要な部分を管理していた。イスラエルのデータが劣化を示した後、オフィスは観察を運用限界、修正バージョン、および優先順位付けされた現場行動に変換する立場にあった。GAO の説明は、それが修正を開発し、警告を伝達したことを示している。説明責任分析は、なぜそれらの行動がダーランでのタイムリーな保護にならなかったのかを問う。

運用リーダーシップは、ドクトリンと砲台が実際にどのように使用されているかについての知識を管理していた。システムが何日も継続的にアクティブなままであった場合、その事実は耐久性の想定を評価している人々に届く必要があった。コマンドはまた、再起動、更新ダウンタイム、および重複保護を計画できるかどうかを管理していた。

ソフトウェア配布および戦域サポートチェーンは、修正バージョンの配備された場所への移動を管理していた。戦時環境では、輸送遅延は理解できるかもしれないが、それらは依然としてシステムのリスクの一部である。ロジスティクス性能は危険の緊急性に対して測定されるべきである。

ユニットリーダーシップとオペレーターは、自分たちに利用可能な命令、情報、および権限の範囲内でローカルアクションを管理していた。彼らは述べられていない閾値を推測しなかったことに対して単独で非難されるべきではない。逆に、安全プロセスは、ユニットレベルの証拠として何が必要かを定義しなければならない。稼働時間ログ、警告確認、再起動記録、インストールされたバージョン、および機能チェック。

陸軍および防衛リーダーシップは、より大きなガバナンスシステムを管理していた。即応性基準、報告チャネル、配備権限、独立したレビュー、および可用性と修正ダウンタイムのバランス。制度的説明責任はこのレベルに位置する。なぜなら、ローカルチームは艦隊全体の構成可視性を作成したり、警告ポリシーを自分たちで書き換えたりできないからである。

製造者の役割も証拠によって境界付けられるべきである。ソース記録はソフトウェア保守と技術的修正の議論をサポートするが、一人のプログラマーまたは一つの企業を完全な原因として扱うことを正当化しない。運用障害は、技術的な欠陥がシステムアーキテクチャ、変更されたミッション条件、稼働時間に関する想定、不完全な警告内容、および修正の遅延配備と相互作用して発生した。

この階層的な割り当ては、犯人を指名するよりも要求が厳しい。各所有者は自分が保持する管理の証拠を生成する必要がある。エンジニアリングは誤差分析とテスト結果を生成する。プロジェクトオフィスは危険決定とリリース記録を生成する。コマンドは運用ドクトリンとユニット状態の可視性を生成する。ロジスティクスは配達証拠を生成する。ユニットは構成と緩和確認を生成する。監視は、露出が続く前に連鎖が閉じていることを検証する。

このケースはすべてのパトリオット交戦に対する評決ではない

パトリオットのより広範な湾岸戦争における有効性は争われた。GAO の証言、技術政策分析、およびその後の公開報告は、公式の成功主張に疑問を呈し、弾頭キルの確立の難しさを検討した。他の当事者はシステムの性能を擁護した。それらの議論は証拠の質に関連するコンテキストであるが、ダーランのクロックドリフトの発見を膨らませるために必要ではない。

特定のケースには独自の公式記録がある。一つの砲台が不正確なタイミング計算が長時間の運用中に増大したために、飛来するスカッドの追跡と迎撃に失敗した。境界を狭く保つことは説明責任を向上させる。文書化されたソフトウェア障害が兵器システムに関するすべての主張のレトリカルな代理になるのを防ぐ。

同じ規律が死傷者報告にも適用される。GAO のダーラン報告書は、スカッドが陸軍兵舎に着弾し、28人の米国人が死亡したと述べている。その数字は GAO に帰属できる。この記事は、同様に信頼できる証拠によってサポートされない限り、正確な負傷者数、兵舎内の詳細なシーケンス、または個人の対応行動に関する主張を追加すべきではない。

また、記録は意図的な不正行為を確立していない。証拠は想定、計算限界、警告の具体性、および更新タイミングに関する発見をサポートする。それは妨害行為、犯罪行為、またはユニットを既知の致命的結果にさらす意図的な決定の主張をサポートしない。

また、すべての有限精度計算を欠陥として説明しないことも重要である。近似はコンピューティングに内在する。欠陥は、累積誤差が信頼できる運用条件下でシステムの許容範囲を超え、効果的な検出または制御がない近似を使用することにある。

最後に、このケースはオペレーターエラーに還元されるべきではない。GAO は、当局者はユーザーが非常に長い期間砲台を運用しないと想定していたが、ダーランの現場現実は100時間以上の連続稼働であったと報告した。そのミスマッチは制度的インターフェース問題である。オペレーターはシステムの一部であるが、エンジニアリングとコマンドが明示的で実行可能にしていない限界を強制することはできない。

より強力な制御システムが必要とするもの

ダーランからの最も有用な教訓は具体的である。「より高い精度を使用する」は一つの修復であるが、完全なガバナンスプログラムではない。

数値許容範囲を運用条件で定義する

要件は、最長の信頼できる稼働時間と最も高い関連目標速度における最大許容予測誤差を述べるべきである。レンジゲートが必要な追跡確率を提供しなくなるポイントを特定すべきである。ビット幅の決定は、物理的効果に変換された場合にのみレビュー可能になる。

エンジニアは、変換ごとの誤差だけでなく、最悪の場合の累積誤差を計算すべきである。テストはクロックを耐久限界付近およびそれを超えて実行すべきである。ソフトウェアが複数の機能で経過時間を使用する場合、各パスには誤差バジェットが必要である。

運用エンベロープを明示的にする

検証されたエンベロープには、連続運用期間、目標特性、再起動想定、ソフトウェアバージョン、および環境条件を含めるべきである。配備がモバイルで短期間の使用から固定で継続的な即応性に変わるとき、変更は正式な再評価をトリガーすべきである。

稼働時間制限は、技術命令、オペレーターディスプレイ、即応性ダッシュボード、およびコマンド計画に属する。それは後日アセンブリ命令の分析を通じてのみ発見可能であるべきではない。

稼働時間とマージンを計装する

システムは安全関連状態を公開すべきである。オペレーターとサポートコマンドは、連続ランタイムの正確な測定と残りの追跡マージンの明確な表示を必要とする。警告は限界の前にエスカレートすべきであり、計算が効果的でなくなった後ではない。

計装自体は非干渉についてテストされなければならない。記録が許容できないリスクを生み出す場合、プログラムは別の検証された証拠メカニズムを必要とする。記録しないことを選択することは、学ばないことを選択することを意味してはならない。

修正開発と中間緩和策を分離する

恒久的なソフトウェア変更が進行中の場合、中間的な危険制御は依然として所有者を必要とする。緩和策は、スケジュールされた再起動、最大稼働時間の短縮、重複カバレッジ、制限されたミッションモード、または他の工学的措置である可能性がある。文書化された実現可能性と完了の証拠が必要である。

影響を受けるすべてのユニットが保護されるまでリスクは開いたままである。コードがリリースされるまでではない。

定量化された警告を使用する

安全メッセージは「非常に長い」のようなフレーズを閾値に置き換えるべきである。影響を受けるバージョンを特定し、結果を述べ、特定の行動を要求し、その行動の責任者を命名すべきである。閾値が現在の状態に依存する場合、ユニットは確認応答とともにその状態を報告すべきである。

メッセージは本部を出たときに閉じられない。閉鎖には、受信、理解、行動、および検証が必要である。

艦隊構成の可視性を維持する

プログラムおよび運用リーダーは、各砲台がどのソフトウェアバージョンを実行しているか、最後にいつ再起動したか、どの警告を確認したか、および修正変更がローカル機能チェックに合格したかどうかを知るべきである。そのインベントリは、動きの速い運用中にリスクを優先順位付けするのに十分に最新であるべきである。

構成記録はまた、組織が公開された修正がすべての場所で露出を除去したと想定する一般的な故障モードを防ぐ。

安全なメンテナンスウィンドウを計画する

再起動またはソフトウェアのインストールは保護を中断する可能性がある。それは正当な運用問題を生み出すが、危険を管理しない言い訳にはならない。コマンドは重複カバレッジ、段階的メンテナンス、または他の継続性措置を計画すべきである。増大する計算リスクと比較して短いメンテナンスリスクを受け入れる権限は明示的であるべきである。

実際に実行されているミッションをテストする

耐久テストは、元のコンセプトで想定されたより短いセッションだけでなく、継続的な戦時運用を反映すべきである。目標モデルは、システムが交戦するように割り当てられた脅威の速度と行動を反映すべきである。テストは、ランタイム、数値表現、およびレンジゲートロジックの相互作用をカバーしなければならない。

GAO は、長時間の稼働が他のシステム困難を引き起こさないことを確認するために、後に耐久テストが実施されたと報告した。耐久性のある制御は、配備条件が限界を露出させる前にそのクラスのテストをルーチンにすることである。

独立した検証を維持する

安全重要な修正は、述べられた誤差限界と運用シナリオに対して独立してチェックされるべきである。GAO 自体がレビューの一部として修正を再計算した。プログラムは、長時間の算術が評価されたかどうかを発見するために失敗後の監査を必要とするべきではない。

独立したレビューはまた、警告の適切性、現場配布、および構成クロージャを評価すべきである。ソフトウェア検証だけでは、修正バージョンが露出したシステムに到達したことを示すことはできない。

反実仮想は制御を明確にするが、歴史を書き換えない

いくつかの反実仮想は、欠落している制御を特定するのに役立つ。時間変換が100時間で適切な精度を維持していた場合、GAO によって説明された特定のレンジゲート変位は同じようには発生しなかったであろう。砲台が強制された安全間隔内で再起動されていた場合、内部クロックはゼロに戻り、蓄積誤差は減少していたであろう。修正ソフトウェアが2月25日より前に到着してインストールされていた場合、補償計算が既知の問題に対処していたかもしれない。

これらは制御指向の命題であり、単一の変更が攻撃のすべての結果を確実に防いだであろうという主張ではない。迎撃は複雑な物理的および運用プロセスである。公開証拠は、アルファ砲台がこのスカッドを追跡して迎撃しなかった理由を確立する。それは仮想的な交戦の結果についての保証を正当化しない。

別の反実仮想は警告内容に関するものである。2月21日に発行され、影響を受けるすべてのユニットの現在の稼働時間に一致し、再起動権限によって裏付けられた定量化された指令は、リスクをより実行可能にしたであろう。それがダーランで実行されたかどうかは、ここで完全には確立されていない事実に依存する。教訓は、実際の定性的警告がオペレーターが必要とする閾値を提供しなかったことである。

反実仮想分析の目的は、各障害点をテスト可能な制御に結び付けることである。それは後から確実性を生み出したり、戦時運用の制約を消し去ったりするために使用されるべきではない。

現代のシステムも依然として不可視の時間リスクを蓄積する

GAO 報告書のアーキテクチャはその時代を反映しているが、リスクパターンは現代的なものである。長時間稼働するシステムは状態を蓄積する。カウンタが増加し、クロックがラップし、リースが期限切れになり、証明書が古くなり、オフセットがドリフトし、キューが深くなり、数値近似が複合する。サービスは短いテストに合格しても、数日または数か月の稼働後に失敗する可能性がある。

現代のハードウェアはより広いレジスタとより高い精度を提供するが、幅だけでは安全性を保証しない。ソフトウェアは依然として時間単位、クロックドメイン、および数値型の間で変換する。分散システムはウォールクロック、モノトニッククロック、およびリモートタイムスタンプを組み合わせる。組み込みデバイスはメモリまたは処理能力を節約するかもしれない。安全性は、実際の表現とミッション期間を分析することに依存する。

運用上の想定も、システムよりも速く変化し続けている。断続的な使用のために設計されたプラットフォームは、継続的に利用可能なインフラになる可能性がある。バックアップツールがプライマリサービスになる可能性がある。地域展開がグローバルになる可能性がある。一つのワークロード用に構築されたシステムが、より高速またはより変動の多い環境にさらされる可能性がある。各変更は暗黙の制限を無効にする可能性がある。

警告チェーンの問題も同様に現代的である。セキュリティおよび安全チームは日常的に勧告を公開するが、リモートオペレーターは脆弱なバージョンを使い続けている。ダッシュボードはパッチが存在することを示しても、インストールを証明しない。メッセージは閾値や期限、影響を受ける状態を述べずにリスクを定性的に説明するかもしれない。ダーランはラストマイルの証拠が重要である理由を示している。

最も深い教訓は、時間がデータとして統治されなければならないということである。その単位、精度、エポック、最大値、リセット動作、および変換パスはインターフェース要件である。稼働時間は安全ケースへの入力である。誤差が時間とともに増大する場合、すべての運用時間がマージンを消費する。

監督とリーダーシップのための質問

結果重大性の高いソフトウェアに責任を持つリーダーは、コンパクトな一連の質問に答えられるべきである。

最も長い信頼できる連続ランタイムは何か、システムはそれを超えてテストされたか？どの計算が経過時間とともに誤差を蓄積するか？最悪の場合の誤差からどのような物理的またはサービスの影響が生じるか？最大安全期間はどこに文書化されているか？

現場から異常データを受け取るのは誰か、そしてそれが運用エンベロープを変更するかどうかを決定するのは誰か？危険が確認されたとき、恒久的な修正が開発されている間、中間緩和策を所有するのは誰か？その人は再起動またはサービス中断を命令できるか？

警告には測定可能な閾値、影響を受けるバージョン、および必要な行動が含まれているか？確認応答はユニットの実際の状態を報告するか？行動が発生したという証拠はあるか？

リーダーシップはすべての配備された構成、現在の稼働時間、および更新ステータスを特定できるか？修正ソフトウェアが最も遠いサイトに到達するのにどのくらい時間がかかるか？配布の優先順位は露出に結び付けられているか？

運用中にどのような証拠が収集されるか？計装は非干渉についてテストされたか？直接記録が安全でない場合、異常検出と独立した再構築をサポートする代替手段は何か？

コード変更だけでなく、現場でのクロージャを独立して検証するのは誰か？「修正リリース済み」から「リスク除去済み」にステータスを変更する条件は何か？

これらの質問は、有名なソフトウェアストーリーを説明責任のある運用モデルに変える。それらは確信声明ではなく、成果物、所有者、および閾値を求める。

結論

ダーランのパトリオットの失敗はソフトウェアのタイミング問題によって引き起こされたが、「丸め誤差」は制度的失敗の説明としては小さすぎる。制限された精度が稼働時間とともに増大する誤差を生み出した。変更された配備条件は、システムを当局者が想定した運用期間をはるかに超えて押しやった。現場データが劣化を露呈した。ソフトウェア修正がリリースされ、警告が送られたが、警告には使用可能な時間閾値が欠けており、修正バージョンは攻撃後にダーランに到着した。

GAO の記録は、責任の規律ある割り当てをサポートする。エンジニアリングは数値挙動とその検証を所有していた。プロジェクトオフィスは異常変換、警告、および修正を所有していた。運用リーダーシップはドクトリンと連続使用の可視性を所有していた。ロジスティクスは変更された構成の配達を所有していた。配備されたユニットは緩和策のための明示的な権限と指示を必要とした。上級リーダーシップはそれらの制御を接続する証拠システムを所有していた。

永続的な教訓は、コンピュータが近似を避けなければならないということではない。それは、組織が重要な条件下で近似を制限しなければならないということである。経過時間、ソフトウェアバージョン、警告受信、および修正行動は可視の制御対象にならなければならない。人命を保護するシステムでは、安全限界は分数のバイナリ展開に隠されたままであってはならない。

パトリオット、クロックドリフトを戦場ソフトウェアの説明責任テストに変えた

概況