軍事業界のトレンド・ワード(3)Software Defined

ここ数回、軍事業界のトレンドワードを紹介しているが、今回のお題は、Software Defined。IT業界でも耳にする機会が増えているが、「(ハードウェア制御ではなく)ソフトウェア制御で動く」ぐらいの意味と解釈していただければ良い。

ソフトウェア制御化のメリット

本連載では過去に何回か、ソフトウェア無線機(SDR : Software Defined Radio)の話を書いている。普通、無線機といえば増幅・検波・変復調といった機能を電子機器の組み合わせによって物理的に実現しているが、それを汎用型のプロセッサとソフトウェアの組み合わせに変えたのがソフトウェア無線機SDRといえる。

無線通信が絡むお仕事をしている方、あるいはアマチュア無線をやっている方なら、無線通信で使用する周波数や変調方式が、実に多種多様であるのは御存じだろう。と思ったら、よくよく考えれば移動体通信の分野も同じだ。

そこで使用する無線インタフェース(変調方式や符号化方式などの集合体)、あるいは周波数帯といった話が、普通に一般向けの媒体に出てくる。面白いことになったものである。

• 

  陸上自衛隊の「野外通信システム」を構成する広帯域多目的無線機の概要　資料：防衛省

• 

  陸上自衛隊の「野外通信システム」を構成する広帯域多目的無線機のラインアップ　資料：陸上自衛隊

ともあれ、その多様な通信方式・通信規格にハードウェアで対応しようとすると、個別に回路を設計したり部品を選んだりしなければならない。使用する通信方式・通信規格が変われば、ハードウェアは設計し直し・買い直しである。

そういえばしばらく前に、筆者はVoLTE非対応の携帯電話をVoLTE対応の携帯電話に機種変更する羽目になった。VoLTE対応機でなければ音声通話ができなくなるというからだ。通信方式が変わるせいでハードウェアを変える羽目になった、ひとつの例である。

閑話休題。SDRは、そうした面倒を緩和する際に役に立つ。ソフトウェアの入れ替えだけで新しい通信方式・通信規格に対応できれば、ハードウェアはそのままで済む。ただし、ソフトウェアの開発とテストは大変なことになりそうではある。

ソフトウェア制御化が生きる場面

これが効いてくるのは、実は通信衛星の分野だ。なにしろ、赤道上・高度36,000kmの上空にいる通信衛星のところに、新しい中継機を持って行って取り付け直すのは、現実的な話とはいえない(少なくとも現時点では)。

かといって、既存の衛星を捨てて新しい衛星にするのでは、えらく費用がかかる。静止衛星の寿命はだいたい15年前後だから、それより前に用途廃止にしたのではもったいない上に、投資を回収できるかどうか怪しくなる。

しかし、SDRの技術を応用できれば、新しい通信方式・通信規格に対応するのに、新しいソフトウェアをアップロードするだけで済む。また、不具合対処のためにソフトウェアを更新する使い方もあるだろう。もっとも、衛星のところまで確実に、エラーが生じないように伝送するのは、それはそれで簡単な仕事ではなさそうだけれど。

分かりやすく、事例も多いので通信機の話を例に使ったが、これ以外でも、ハードウェア制御から、ソフトウェア制御に移り変わっている製品分野はいろいろある。

例えば、ソナーがそれだ。相手は電波ではなくて音波だが、変復調を必要とする場面があるところは似ている。また、数年前にイギリスで、キネティック(QinetiQ plc)が、ソフトウェア制御のレーザー装置をセンシングに使用する、SDML(Software Defined Multifunction LIDAR)の開発に乗り出すとの話が出た。レーザー・レーダー(LIDAR : Laser Imaging Detection and Ranging)をソフトウェア制御化して、動作モードを自由に切り替えられるセンシング手段に使うという話であるらしい。

ソフトウェアは開発とテストと維持管理が面倒

ただ、ソフトウェア制御にするということは、そのソフトウェアを走らせる環境を整備する必要がある、ということでもある。すると、単に汎用プロセッサとソフトウェアを用意すれば一件落着という話では済まなくなる。

つまり、ソフトウェアの開発・試験に関する体制作り、コード管理の体制作り、インターフェイス仕様の策定など、ライフサイクル全体を通じた体制作りとアーキテクチャ作りが大事になる。最初のアーキテクチャ作りが後々になって響くところは、次回に取り上げる予定の話と似ている。

それに、ハードウェアが未来永劫にわたって同じというわけではない。何かのタイミングで新しいハードウェアに置き換わるから、それを想定して、ハードウェアの変更に対応できる仕掛けにしておかないと困る。バイナリ互換が無理でも、ソースレベルの互換性は必須だ。

例えばF-35。中核となるコア・プロセッサは、すでに第2世代製品になっているし、ブロック4仕様機からは第3世代製品が出てくる。そこで、何百万行もあるソースコードがゴミになってしまったのではたまらない。

そして、ソフトウェア開発の現場でお仕事をされている皆さんなら御存じの通り、ソフトウェアはコードを書いた後のテストが大変だ。筆者もテスト屋の経験があるから、これは身にしみている。

本連載ではしばしば書いているが、不幸にも、特定の条件の組み合わせがそろってしまった時に限ってとんでもないバグが出る、なんていうのはよくある話。それを避けるためには、どういうテストケースを設定すればよいかが問題になるし、そこでは経験と知見の積み重ねがものをいう。だから、簡単に「ソフトウェア制御にすれば幸せになれる」と浮かれると、(物理的にというよりも論理的に?)怪我をする原因になる。