認証取得までの敷居が高いDO-178

設計・製造の分野において、ISO/IECといった規格が、国際標準化機関により定められていることをご存知の方も多いのではないだろうか。例えば自動車ならISO26262、産業機器ならIEC61508といった名称で規定されている。同じように民間航空機向けアビオニクス(航空機に搭載される電子機器)向けのソフトウェアに対する安全規格として、DO-178がある。この規格を発行しているのはRTCA(Radio Technical Commission for Aeronautics)という組織であるが、米国ならFAA(連邦航空局)、欧州ならEASA(欧州航空安全機関)、日本なら国土交通省が民間航空機に関する許認可を担っており、いずれもこの規格に準拠して搭載ソフトウェアを開発することを求めている。

幾度かの改定を経て、最新のDO-178Cは2012年に定められた。同規格の改定の際に追加されたものの一つがDO-331である。これはモデルベース開発を適用してアビオニクスを開発する際に準拠すべき規格をまとめたものである。

前置きが長くなったが、今回お話を伺ったのはMHIエアロスペースシステムズシステム開発部 部長の各務博之氏である。同社は三菱重工業のグループ会社で、航空宇宙関連のソフトウェア開発を主業務としている会社である。三菱重工業といえば国産初のジェット旅客機「三菱リージョナルジェット(MRJ)」を連想するかもしれないが、MRJに使用されているパーツの国産化率は30%程度だという。胴体や主翼は三菱重工業製だが、アビオニクスはほぼ海外製である。特にソフトウェアに関しては日本国内で作られたコードは1行も搭載されていない。

MHIエアロスペースシステムズ システム開発部 部長 各務 博之氏

MHIエアロスペースシステムズ システム開発部 部長 各務 博之氏

この要因の一つとしてDO-178に準拠したソフトウェアの認証取得までの敷居が非常に高いことが挙げられる。一方で、同社は衛星や自衛隊向けのアビオニクス用ソフトウェアを手がけていることもあり、「航空宇宙分野のソフトウェアの専門会社として民間航空機用のソフトウェアの認証が取れないのは問題」(各務氏)という認識のもと、７年ほど前からDO-178に関する研究を重ねてきた。

図らずもその時期は、経済産業省が開催していた航空宇宙産業フォーラムの会期中で、民間航空機向けアビオニクスのソフトウェア開発にも注力していく方針を定めた頃であり、国内のアビオニクスメーカーに対して、DO-178CやDO-331に関する研究会やコンサルティングを実施してきた。こうしたアビオニクスメーカーがターゲットとするのは、当面はボーイングやエアバスなどの国外航空機メーカーであるが、将来的にはMRJへの参画も視野に入れているという。同社は、今後DO-331への対応が必要になるアビオニクスメーカーに対してノウハウや知見の共有を図っている。

MBDのメリットを活かすMathWorksのSimulinkモデル

ここで本題である。DO-331はアビオニクス用のソフトウェアをMBD(Model Based Development)を利用して開発する際の手順を定めているが、利用するツールは特定していない。しかしながら各務氏は「モデルの開発にはMathWorks のSimulinkモデルを用いるのが有効であろう」と語る。

MBDの場合、UML(Unified Modeling Language)に代表される「振る舞い」のモデルと、Simulinkに代表される「制御構造」のモデルがある。どちらが良いかは目的によって異なり、ハードウェアを制御するようなソフトウェアの場合、MBDの一番の利点はモデルを設計段階でシミュレーションすることによりその正しさを早期に検証することができることと、そのモデルを元にソースコードを自動生成できることであり、これが実現できるのは現時点ではSimulinkモデルのみ、というのがその理由である。

UMLベースの場合、厳密なシミュレーションを行うのは難しい。また、時としてこれらのツールのCode Generatorが吐き出すのはスケルトンだけで、あとは手作業で埋めていく事が多く、これではMBDのメリットが皆無になってしまう。実際、DO-331の研究会に集まったアビオニクスメーカーにアンケートを取ったところ、ほぼすべてのメーカーがSimulinkを利用してモデルを構築しているという話もあった。

MathWorksと他のMBD開発ツールとの違いとは

ところでDO-331に対応したMBD開発ツールは複数存在するが、MathWorksのソリューションは他の開発ツールとは異なった特徴をもつ。例えば他のツールはCode GeneratorそのものがDO-178CやDO-331のQualificationを取得しているが、MathWorksの場合、Code GeneratorであるEmbedded Coder自身はQualificationを取得せず、代わりにQualificationを取得したVerification Toolで同等の効果を得る戦略をとっている。Code GeneratorのQualificationを取得するのは難易度が高いため、当然これはコストに跳ね返ることにも繋がる。

一方、Verification ToolのQualificationは比較的容易に取得することができる。各務氏によれば、「Verification Tool側でQualificationを取得し、同等の効果を得るというMathWorksの戦略は、コスト的にもパフォーマンス的にも評価できる点」とのことだ。さらに「どちらのプロセスがより自社のやり方に適合しているかは各アビオニクスメーカーが判断するべきことである」と続けている。同社では実際にアビオニクスメーカーがその違いを体感できるトレーニング器材の整備も併せて進めている。

ちなみにそのVerificationについて、MathWorksはMATLAB R2012aからDO Qualification Kit を用意しているが、同社はあえてこれを利用していない。なぜなら同社は現在DO-178CやDO-331に対応する方法論やメソッドを、他のメーカーに公開して行くというのが主な活動だからだ。

DO-178C/DO-331に準拠できるノウハウを蓄積し、公開していく

また、内部を理解するという意味でも、敢えて自分たちでフローを構築していきたいという狙いもある。下記図は、実際にDO-331ベースでのVerificationの一例だそうだが、個々の検証ツールをどう組み合わせ、どう使えばDO-178C/DO-331に準拠できるのか、ノウハウとして蓄積し、これらの情報を公開していくという。

  • 開発フローにおけるMathWorks社検証ツールの位置付け

    開発フローにおけるMathWorks社検証ツールの位置付け

興味深いのは、同社はSimulinkそのものを高く評価するものの、必ずしもすべてをMathWorksの提供するツールで固めることなく、それ以外の方法論も模索していることだ。

「例えば今年5月には弊社が他社のツールキットを採用したニュースが流れましたが、我々がアビオニクスメーカーに提案しているのは、ツールは何を使うにせよ、モデリングはSimulinkモデルが良い選択肢ではないか、という点です」(各務氏)。前述したようにどちらのMBD開発ツールを用いたプロセスにするかは、各アビオニクスメーカーの開発スタイルに適合したものを選択するべきであり、無理にMathWorksで全部揃えるべきとは言い難い。同社は言ってみればオブザーバー的な位置にいるので、あくまでも俯瞰的に情報提供を行うというスタンスを保っている。

ちなみに同社は自ら何か特定のアビオニクス(ハードウェア)の開発を指向しているわけではない。というのも、同社はあくまでもアビオニクスメーカーが製品を開発する際にそのプロジェクトに参画し、ソフトウェア開発、及びソフトウェア認証を担当すると言う立場だからである。その観点からも、同社は日本のアビオニクスメーカーが認証技術を向上させこの業界が活性化するための活動を続けている。これらの活動が実を結び、近い将来、MATLAB/Simulinkを用いた民間航空機向けソフトウェアの開発が日本に根付く日がくることを期待している。

[PR]提供：MathWorks Japan