ミサイル防衛に関する最近の話題(8)イージス戦闘システムとCSL

ウェポン・システムが機械仕掛けからコンピュータ制御に変わったことで、そのコンピュータを動かすためのソフトウェア開発が重要な課題になった。開発や保守を効率的に実施するのは不可欠な課題だが、この辺の事情は、民間で使われている情報通信機器となんら違わない。

ソフトウェアのモジュール化

前回に、イージス戦闘システムのハードウェアはTI(Technology Insertion)、ソフトウェアはACB(Advanced Capability Build)という概念を取り入れている、という話を書いた。

これには、ハードウェアとソフトウェアを切り離して、それぞれの変更や改良を容易にする狙いがある。ハードウェアとソフトウェアの分離ができていないと、どちらか一方を改良あるいは変更する際に他方も影響を受けてしまい、開発や試験に余計な工数がかかってしまう。

• 現在のイージス・システムはオープン・アーキテクチャ化を図り、ハードウエアとソフトウェアの分離を実現している。最上段に並んでいるのが、個別の機能を実現するソフトウェア群　資料：Lockheed Martin

そのソフトウェアは、いろいろな機能を実現しなければならない。イージス戦闘システムの表芸である対空戦を例にとると、以下のようになるだろうか。

• AN/SPY-1レーダーの制御とシグナル処理
• AN/SPY-1レーダーが捕捉した個々の探知目標ごとのトラック管理
• 探知目標の追尾データに基づく未来位置の予測
• 予測した未来位置に基づいて実施する脅威評価
• 脅威評価に基づいて定めた優先順に基づく武器割当と交戦

ミサイル防衛については別途、イージスBMDという名称で専用のハードウェアやソフトウェアが加わる。対水上戦や対潜戦も事情は同じだ。どの分野であれ、新しい能力や武器を加えるには、その武器に関するデータと制御のためのソフトウェアを追加する必要がある。

こうなってくると、理想的なやり方は「機能ごとにソフトウェアを部品化しておいて、必要に応じて組み合わせる」という形になる。すべての機能をひとまとめにしてしまったのでは、柔軟な対応ができない。なにもウェポン・システムの分野に限った話ではない。

また、艦載指揮管制装置はイージス戦闘システムだけではないから、異なる艦載指揮管制装置の間でソフトウェアを共用できるとありがたい。同じ機能を実現するのに、艦載指揮管制装置ごとにソフトウェアを書いていたのでは、開発・試験の手間がそれに比例して増えてしまう。

例えば、米海軍の空母や強襲揚陸艦はSSDS(Ship Self Defense System)という指揮管制装置を備えている。イージス戦闘システムは艦隊全体に防空の傘を差し伸べるものだが、SSDSは個艦防空、つまり自艦に向かってくる脅威を払いのけることに特化したシステムだ。とはいえ、飛来する対艦ミサイルを探知・追尾して脅威評価を行い、適切な武器を割り当て交戦するという基本動作は共通している。脅威評価のロジックはイージス戦闘システムと異なり、「自艦に向かってくる脅威」を優先するようになっていると思われるが。

このほか、ロッキード・マーティンの製品ラインアップには、COMBATSS-21(Component Based Total Ship System - 21st Century)という艦載指揮管制装置がある。米海軍の新型フリゲートに搭載する話はボツになったが、フリーダム級沿海域戦闘艦をベースとするサウジアラビア向けの水上戦闘艦が、これを搭載することになっている。

COMBATSS-21も、基本的には同じ艦載指揮管制装置なのだから、機能的にはイージス戦闘システムと共通する部分がある。それなら、共通化できるものは共通化したい。そこで、使えるところはイージス戦闘システムとソースコードを共用している。

CSL(Common Source Library)という解決策

こういう状況を受けて登場したのが、CSL(Common Source Library)だ。

過去に開発してきた各種のソフトウェアをCSLで一括管理して、大規模・小規模な能力向上やバグフィックスについても、成果をすべてCSLに取り込む。そして、既存艦の能力向上でも新規建造艦でも、必要なソフトウェアをCSLから引っ張り出して展開する。こうすることで、以下のメリットが得られるとされる。

• ソフトウェアの再利用と共通化の実現
• バグフィックスや新機能の追加を複数の対象システムに展開
• 共通化と部品化による試験プロセスの合理化

• イージス・システム、あるいはそれとソースコードを共用する各種システムのソフトウェア開発成果は、すべてCSLを通じて一括管理する仕組みができている　資料：US Navy

例えば、同じハードウェア(TI○○の数字が同じ)を使っているイージス艦でも、イージスBMDの機能を備えている艦と、備えていない艦がある。それなら、前者はイージスBMDで必要とするソフトウェアをCSLから引っ張り出して実装するし、後者はそれを省く。

イージス・アショアにしても、ハードウェアは艦載型と共通だが、機能的には違いがある。例えば、政治的制約があって何か特定の機能を外すということになれば、その機能に関するソフトウェアは使わない。逆に、何か特定の機能が必要だということになれば、CSLから引っ張り出してきて実装する。

日本向けイージス・アショアも同じで、実はAN/SPY-7(V)1レーダーを使うために必要なソフトウェアもCSLに用意してある、というのがロッキード・マーティンの説明だった。

そして、複数のシステムの間で可能な限りソースコードを共通化していれば、特定の機能に関するバグフィックスの成果は、そのソースコードを使用しているすべてのシステムに反映される。

もちろん、コンピュータのハードウェアが新しくなったり、オペレーティング・システムが変わったりすれば、ビルドはやり直さなければならない可能性が高い。しかし、バイナリ互換が無理でもソースコードの互換性が保たれていれば、ビルドし直すことで対応できる。