本連載の第4回で、F-35の要となるアイテム、すなわちソフトウェアの概要を取り上げた。この時はミッション・システム用ソフトウェア、つまりレーダーを初めとするセンサー群や、それらから得た情報を処理するコンピュータの話がメインだった。

何をするにもソフトウェア

しかし実際には、そのミッション・システム用ソフトウェア以外にも、さまざまなソフトウェアが使われている。前回に取り上げた「ALIS(Autonomic Logistics Information System)」は地上側で使用する運用支援のためのシステムだが、機体側でも以下に示すように、さまざまなソフトウェアが必要になる。

  • 飛行制御コンピュータのソフトウェア : 操縦操作をつかさどる。パイロットの入力に応じて適切に舵面をコントロールする。

  • エンジン制御用のソフトウェア : いわゆる「FADEC(Full Authority Digital Electronic Control)」。クルマと同様、飛行機のエンジンも電子制御化されているので、当然ながらソフトウェアが必要になる。開発が難しい分野の1つ。

  • 電子戦装置のソフトウェア : 敵が使用するレーダーの電波を傍受・解析するとともに、使い物にならなくなるように妨害をするためのもの。いわゆる「ECM(Electronic Countermeasures)」。

  • 電子戦対策用のソフトウェア : 逆に、敵が仕掛けてくる妨害を突破するためのECM対策、すなわち「ECCM(Electronic Counter Countermeasures)」にもソフトウェアが必要になる。ECCMの機能は電子戦装置ではなく、敵が妨害のターゲットにするレーダーや通信機器に組み込む。ちなみに、ECCMへの対抗策という話も出てくるが、ECCCMとは言わない。

  • 通信システムのソフトウェア : 本連載の第161回で取り上げた、CNI(Communication, Navigation and Identification)システムのこと。F-35のCNIシステムはソフトウェア無線機(SDR : Software Defined Radio)を使用するから、これまたソフトウェアを記述しないと仕事にならない。

  • ディスプレイ装置のソフトウェア : 厳密に言うと、ミッション・システム用ソフトウェアの一部だが、コックピットに設置してあるタッチスクリーン式ディスプレイ、あるいはヘルメットに取り付けるディスプレイ装置(HMD : Helmet Mounted Display)の動作をつかさどるためのソフトウェア。これがまともに機能しないと、F-35のキモである状況認識能力が画餅と化す。第160回で取り上げた「AN/AAQ-37 EO-DAS (Electro-Optical Distributed Aperture System)」のソフトウェアも、ここに入れてよいかもしれない。

そんなこんなで、機体側で使用する各種ソフトウェアのソースコードだけで総数800万行という仕儀になる。これに、地上側で使用する各種システムのソフトウェアの分が加わる。こうした膨大な量のソフトウェアを開発するとともに、テストして熟成を進めていくだけでも、途方もない仕事になるのは容易に理解できる話だろう。

機体側のソフトウェアとブロック

そのすべてについて言及するのは途方もない仕事になるので、今回は機体側で使用するソフトウェアの「ブロック」について。

大規模なソフトウェアをいきなりすべて開発・実装するのは大変なので、F-35計画では段階的に開発・実装を進めている。つまり、まず「機体を飛ばすためのソフトウェア」を作り、続いてミッション・システムなど「戦うためのソフトウェア」を作り込んでいく。機体が飛べなければテストにならないので、まずそちらを優先するわけだ。

そして大きく分けると、「ブロック1A」「ブロック1B」「ブロック2A」「ブロック2B」「ブロック3i」「ブロック3F」の6種類がある。この辺がメジャーバージョンで、さらに細かいマイナーバージョンがいろいろある。面白いのは、このソフトウェアのブロックの違いが、機能的な違いだけでなく、機体の飛行性能にも影響していること。

戦闘機について回る用語の1つに「荷重制限」(Gリミット)がある。Gとは重力加速度のことで、地上で普通に過ごしている時にかかるのは1G。ところが、戦闘機が機動飛行を実施すると、その何倍もの荷重がかかる。

現代の戦闘機ではおおむね、7G～9G程度が上限になっている。もちろん、荷重制限値が高い戦闘機は、それだけ機体を頑丈に作らなければならない。荷重制限値を越える機動飛行を行えば、パイロットの身体がついて行けないし、機体構造にも悪い影響がある。前回にも少し触れた「オーバーG」である。

ところが、F-35みたいなフライ・バイ・ワイヤ(FBW)を使っている飛行機は、パイロットの操縦操作に飛行制御コンピュータが「待った」をかけることができる。

つまり、操縦桿(F-35の場合、サイドスティックだが機能的には同じ)をめいっぱい引き続けて急反転しようとした時に、飛行制御コンピュータが「これを真に受けて飛ばしたらオーバーGになる」と判断したら、自動的に反転を緩めたり、限界で止めたり、といったコントロールを行う仕組み。

だから、機体やソフトウェアの開発が進んでいないうちはGリミットを抑えておいて、開発が完了して最終版になったら仕様上限までGリミットを引き上げる、なんていうことが可能になった。また、派生型によってGリミットを使い分けることもできる。

高迎角試験を実施中のF-35A。ただし、静止画だと何をしているのかよくわからないのが惜しい Photo : DoD/jsf.mil

コンピュータ制御の面白いところで、ソフトウェアの設定を変更すれば、Gリミットを変えることができる。その際にハードウェアを取り換える必要はない。

F-35では、米空軍向けのF-35A(航空自衛隊向けもこの型だ)はGリミットが9Gになっているが、STOVL(Short Take-Off Vertical Lansing)型のF-35Bは7G、空母搭載型のF-35Cは7.5G、と違いがある。もっとも、F-35CはF-35A/Bより主翼が大きい(つまり機体構造が違う)ので、まるっきり同じ機体でGリミットだけ違うわけではないが。

なお、国やメーカーによっては思想の違いがあり、普段は仕様通りのGリミットを超えないようにしていても、緊急回避時のように生死がかかっている場面に限り、特定の操作を行うと緊急避難的にオーバーGを許容する、という設計になっている機体もある。

荷重制限以外の、例えば迎角(AoA : Angle of Attack)をはじめとする飛行諸元についても事情は同じ。現在、機体がどういう姿勢・速度・荷重条件下で飛んでいるかは飛行制御コンピュータが常に把握しているから、許容範囲内に収めるようにする制御も飛行制御コンピュータがつかさどれるわけだ。

したがって、迎角を大きくしすぎて失速する、なんていう事態も、オーバーGと同様に飛行制御コンピュータの介入によって回避できる理屈となる。