これまで、本連載では何か1つテーマを決めて、そのテーマに関わるさまざまな話題について技術解説を中心に展開する、というスタイルをとってきた。しかし、ずっと同じスタイルを続けていると飽きられそうだし、書く方もネタに詰まってしまうので、ここはスタイルを変えてみようと思う。

新テーマは「実機拝見」

そこで考え出したアプローチが、毎回、特定の機体を「お題」にして、情報通信技術の観点から、その機体特有の話を拾い出してみようというものである。筆者のフィールドの関係で軍用機の話題が多くなりそうだが、そこのところは御容赦いただきたく。場合によっては、同じ機体で複数回にまたがったり、同じ機体が再登場したりということもあるかもしれない。

というわけで、栄えある(?)第1回に選んだのは、情報通信技術の申し子みたいな戦闘機、すなわちロッキード・マーティン社のF-35ライトニングIIである。航空自衛隊でも採用を決めているし、その航空自衛隊向けの機体が工場で姿を現しつつあるタイミングだから、ちょうどいいだろう。

2200万行に及ぶソースコード

F-16(この機体もいずれは取り上げてみたいと思っている)の頃から顕著になった傾向だが、飛行機が「ハードウェア主導」から「ソフトウェア主導」になって、コンピュータで制御される部分がどんどん増えている。

例えば、エンジンがコンピュータ制御になれば、コンピュータが作動しないとエンジンをかけることもできない。操縦翼面がコンピュータ制御になれば、飛行制御コンピュータが生きていないと真っすぐ水平飛行することすらできない。

もちろん、ウェポン・システムの分野も言うに及ばずだ。その極めつけがF-35である。機体そのものだけでなく、レーダーはAESA(Active Electronically Scanned Array)と呼ばれる電子走査式だし、さまざまなセンサーからの情報を融合して、ひとまとめにしてパイロットに提示する仕掛けまである。

また、以前に「軍事とIT」で取り上げたが、機体の各所に合計6基のカメラを設置して、そこから得た映像を合成してパイロットのヘルメットに組み込んだHMD(Helmet Mounted Display)に表示する仕掛けもある。ノースロップ・グラマン製のAN/AAQ-37　EO-DAS(Electro-Optical Distributed Aperture System)という機材だが、これも前述のデータ融合も、開発に苦労している部位だ。

航法機材はGPS(Global Positioning System)や慣性航法装置(INS : Inertial Navigation System)みたいなコンピュータ依存型だし、通信機はソフトウェア無線機(SDR : Software Defined Radio)だ。もちろん電子戦装置も充実しているし、それがちゃんと仕事をするには脅威ライブラリをそろえてコンピュータ制御の電子戦装置を構築、それを他のウェポン・システムと連接・連動させる必要がある。

そして、機体の状態診断機能もあるし、交換部品の発注・供給はALIS(Autonomic Logistics Information System)というシステムがつかさどる。ALISはすべてのF-35カスタマーが共同利用する国際的な情報インフラだ。

と、具体例を挙げ始めるとキリがないのだが、そうやってソフトウェア制御の部分が機上と地上の両方でたくさん出現した結果、F-35という1つのシステム(機体だけでなく、地上の支援システムも含む)で使われるコンピュータのソースコードは、ベラボーな分量になった。

資料によって数字がだいぶ違うのだが、1,800万行とか2,200万行とかいう世界である。これをC++言語で書く。さあ、そこで何が大変なのか。

ソースコード管理とテストの苦労

ソフトウェア開発に携わった経験がある方なら御存じの通り、コードの記述やテストと並ぶ大事な作業の1つに、ソースコードの管理がある。

バグが見つかって修正することになれば、修正前のソースコードと修正後のソースコードができる。修正後のソースコードを使ってビルドしなければ、何のためにコードを書き直したのかわからない。時には「直し壊す」とか「直したら別のところが壊れる」とかいうこともあり得るから、過去のソースコードを引っ張り出せるようにする必要もある。ということで、ソースコードの管理システムを整備するのは当たり前の話になる。

ところが、F-35みたいな大規模システムになると、部位によって担当メーカーが違う。機体そのものを扱うソフトウェアの担当、電子戦機器の担当、レーダーの担当、ミッション・コンピュータの担当、光学センサーの担当、データリンク装置の担当、暗号化装置の担当、ALISの担当などなど。

しかも、それぞれの部位がバラバラに独立して動作しているわけではなくて、互いに連接・連携して動作するのだから、個別のメーカーの中で完結して仕事をできるわけではない。特に、仕上がった機器同士を連接してテストする段階まで話が進めば、単体ではちゃんと動いていたモノが、連接したらトラブルを起こすこともある。

そして、ソフトウェアが大規模になれば、開発者もひとつところにまとまっているとは限らず、あちこちに分散して作業を進めることになる。すると、機密情報の塊であるソースコードをいかにして安全に管理してやりとりするか、という課題までくっついてくる。

防衛産業界を狙うサイバー・スパイ行為の脅威が顕在化している昨今、こういうところにもちゃんと気を使わないといけない。実際、F-35計画がサイバー・スパイ行為の被害に遭ったとする報道が出たこともある(どの分野で、どの程度の被害が出たかは定かでないが)。

ICT時代の申し子

というわけで、F-35は「ちゃんと動作するソフトウェアを書く」というだけでも大変なのに、さらに「ソースコード管理の苦労」「テストの苦労」「保全の苦労」といった宿題までくっついてくる、そういう環境の中で開発している機体なのである。まさにICT時代の申し子だ。

もちろん、古典的な苦労、例えば重量増加とか機械的不具合とかいったトラブルにも直面しているのだが、それと並んでソフトウェアで制御される機能の不具合、あるいはソフトウェアの開発難航がしばしば話題に上るのが、F-35プログラムの特徴と言える。

ところが、某社のネットワーク機器(レイヤー3スイッチだったと思うが記憶が定かでない)のファームウェアが、F-35ばりに一千何百万行だかのソースコードから成り立っていると聞いて、またビックリである。