News and Views 2015 Summer / Vol. 14: 上流設計&組込み

組込みソフトウェアにおける安全性の確保

はじめに

1996年6月4日、欧州宇宙機関が打ち上げたロケット「Ariane 5」は、打上げから37秒後に軌道を外れ徐々に分解し始めたため、自爆装置が働いて爆破されました。その原因は、64ビット浮動小数点から16ビット整数値への変換におけるオーバーフローとその例外処理の不具合というソフトウェアによる演算ミスでした。

米国では、医療機器の1つである輸液ポンプが200万台以上も使われているそうです。2005年から2009年の間、FDA(アメリカ食品医薬品局)が実施した輸液ポンプの調査の結果、56,000台に有害事象があることが確認され、87台の輸液ポンプがリコール扱いとなりました。組込みソフトウェアの不具合が原因で、アラームが鳴らなかった、誤ったアラームが鳴ったなどの事象が報告されています。

さて、「安全」とは一体何でしょうか。IEC(International Electrotechnical Commission)のWebサイトによれば、「資産や環境への損害の結果として、直接、間接を問わず、肉体的危害や人々の健康への被害など、受容することのできないリスクから開放されること」とあります。また、よく併せて使われる言葉に「セキュリティ」があります。セーフティ(安全)とセキュリティは似て非なるものであり、対局的であるとも言えます。セキュリティは、「世界や環境、人からデバイスを保護すること」を意味するのに対し、セーフティは、「世界や環境、人をデバイスから保護すること」を意味します。そして面白いことに、セキュリティを高めることがセーフティを高めることにもつながるわけです。今回は、組込みソフトウェアのセーフティ、つまり安全について考えてみたいと思います。

安全に関する標準

組込みソフトウェアの安全が求められる分野は、自動車、医療機器、産業機器、民生/軍用航空機など多岐にわたります。また、業界や地域によりさまざまな標準化組織が存在します。例えば、前出のIECをはじめ、RTCA、EUROCAE、EN、ISOなどがその代表例です。多くの標準化組織が存在するものの、それぞれの標準化にあたっては、既存する他の標準を参考にしたり、修正改変してその業界に適合させたりすることも珍しくありません。

例えば、米国のFAA(連邦宇宙航空局)が指示しRTCAが策定した航空機に関する安全基準であるDO-178Cは、欧州ではEUROCAEのED-12Cとして採用されています。また、IEC 61508は産業機器における機能安全の標準ですが、これを医療機器に適合させたものがIEC 62304、自動車の電気電子システムに適合させたものがISO 26262、鉄道における制御や保護に適合させたものがEN 50128であり、枚挙に困りません。

図1. IEC 61508におけるSIL指標図1. IEC 61508におけるSIL指標

安全とリスク

IEC 61508などでは、リスクについて以下のように定義しています。

リスク = 障害の発生頻度 × 障害の帰結

リスクを完全に取り除くことはできないという前提があり、リスクを受容可能なレベルにまで低減させることを目的としています。障害の発生頻度および障害の帰結を質的に段階分けした指標として、SIL(Safety Integrity Level)などが定められています。障害の発生頻度を組込みソフトウェアに当てはめるなら、その機能が要求された時に正しく実行せずにフェイルすると言い換えることができます。SILの例を図1.に示します。

図 2. 安全に関する標準の間での大雑把なレベル比較図 2. 安全に関する標準の間での大雑把なレベル比較

IEC 61508で定められたレベルは、どの標準にも存在します。ISO 26262であればASIL(Automotive Safety Integrity Level)、DO-187CであればDAL(Design Assurance Level)、EN 50128であればSSIL(Software Safety Integrity Level)が該当します。異なる標準の間での安全やリスク、障害のレベルを比較することは乱暴ですが、大雑把に安全のレベルを軸に比較したものを図2.に示します。

安全認証について

組込みソフトウェアの安全認証は、その業界に応じた標準および提供するシステムに求められる安全のレベルに応じて、アセスメントや資料の提出によって行われます。レベルの高い安全認証を得ることは容易ではなく、コストもかかります。しかし、その業界に参入するには認証取得が義務付けられることもあり、少なくともビジネスを有利に進められることは確かです。

組込みソフトウェアの場合、リアルタイムオペレーティングシステム(RTOS)そのものが安全認証を受けていることには大きな意味があります。メンター・グラフィックスのNucleus SafetyCert RTOSは、ソフトウェアの安全認証を手掛ける大手独立機関であるVerocel, Inc.より認証を受けています。その対象は、IEC 61508のSIL3、IEC 62304のClass C、そしてISO 26262のASIL Bです。またDO-178CのDAL A認証に求められるアーティファクトやドキュメント一式も含まれています。

図3. Nucleus SafetyCertのプロセスモデル図3. Nucleus SafetyCertのプロセスモデル
図4. Nucleus SafetyCertのプロセスメモリの考え方図4. Nucleus SafetyCertのプロセスメモリの考え方

さて、一般的に組込みソフトウェアの安全認証を得るには、まずシステムを定義し、その中でソフトウェアによって実現する部分を定義します。その上で、そのシステムの機能がフェイルすることによって引き起こしかねないリスクをアセスメントし、SILなどのレベルが決められます。ソフトウェアアセスメントでは、ソフトウェアが要件通りに実行すること、要件以外のことを実行しないことを見極めます。また、一連のアクションとそのシーケンスを確認し、正しいタイミングで正しい動作をする制御能力を見極めます。その目的は、意図しないソフトウェアの振る舞いによる障害の帰結を抑制し、リスクの度合いを下げることです。

安全認証は、標準によって大きく2つに大別されます。その1つは、DO-178Cのようにシステムのみが安全認証の対象であり、そのシステムを構成する個々のコンポーネントの認証は意味を持ちません。この場合、Nucleus SafetyCert RTOSパッケージに含まれる「認証」そのものは役に立ちませんが、その認証を得るために使用したプロセスプラン、ソフトウェアテストプラン、要件とトレーサビリティ、ソースファイル、その他のアーティファクトなどを、最終的にシステムの認証プロセスの一部として使うことができます。

もう1つは、IEC 61508、IEC 62304、ISO 26262のように、システムが安全認証の対象ではあるものの、それを構成する各コンポーネントの認証をそのまま階層的に使用できるというものです。この場合、Nucleus SafetyCert RTOSパッケージに含まれる認証そのものを使用できます。

安全認証の対象コードと非対象コードの混在

組込みデバイスのソフトウェアが急激に複雑化しているのは、周知の傾向です。使い勝手のよいユーザインタフェースや、有線/無線のデバイス接続、業界プロトコルなどを採用するにつれ、結果として安全認証の対象となるコードと、それ以外のコードが混在することになります。この時に闇雲にコードを混在させてしまうのではなく、安全認証が必要となる最小限のアプリケーションのみを認証対象とし、他とは明確なセパレーションを施すことが重要です。それにより、安全認証が有効なライフサイクルを長期化させ、結果としてコストを抑えることにもつながります。

特にリアルタイム性が求められる場合、安全認証の対象アプリケーションは、非対象のアプリケーションに対して、そのシステムリソースの優先度が保障されなくてはなりません。また、安全非対象のアプリケーションによって安全対象のアプリケーションが使用するメモリ領域を上書きされないように保護する必要があります。また、メモリの領域を明確に分け、rwx – リード、ライト、実行のアクセス権限を管理する必要があります。システム全体として、安全非対象のアプリケーションのダウンやハングアップによって、安全対象のアプリケーションの振る舞いに影響を及ぼすわけにはいきません。

Nucleus SafetyCert RTOSによるプロセスモデルおよびプロセスメモリの考え方は、まさにこのセパレーションを確実に行うものです。図3.にプロセスモデルを、図4.にプロセスメモリの考え方を示します。またNucleusのプロセスモデルについては、技術文献「プロセスモデルベースのRTOSを用いた組込みシステムの信頼性向上」でも詳しく解説しています。併せてご覧ください。

まとめ

航空宇宙、医療機器、産業機器、自動車などでは安全に関する高いニーズがあります。組込みシステムの基本であるRTOSの安全認証をメンター・グラフィックスが受けたことにより、組込みシステム開発者が最終アプリケーションの安全を確保し、安全認証を受ける際のコストや労力を大幅に削減できます。一方で、半導体の性能向上や、組込みソフトウェアの複雑化が進むにつれて、安全が求められるアプリケーションとそうでないアプリケーションの混在が増加します。プロセスモデルやプロセスメモリなどの明確なセパレーション技術を用いてリスク低減を図る必要があり、それも組込みソフトウェアの安全を保全する上での責任となります。