クリティカル・システムに使う市販ソフトウェアの検証方法(3) ―― 検証記録に含めるべき事項を考える

酒井 由夫

tag: 組み込み

技術解説 2013年2月28日

●性能テストを設計できるのは誰か?

 リアルタイムOSの機能に関するテストについては,要求仕様書(取扱説明書など)があれば網羅性の高いテストを設計することができます.しかし,OSの内部構造に関係するテストや性能に関するテスト・ケースは,OSの設計者側でないと作れないことが多いでしょう.例えば次のようなテストです.

  • リアルタイムOSのスケジューラやディスパッチャの動作テスト
  • リアルタイムOSのカーネルの機能テスト
  • TCB(Task Control Block)やスタックに対する動作テスト
  • タスク切り替えの時間計測

 OSの性能に関するテストでは,負荷試験を行わないと潜在的な不具合を発見できない場合があります.また,TCB操作やスタック操作に問題があるとアプリケーション・ソフトウェア側にも致命的な障害が発生するので,いろいろなパターンの負荷試験を考える必要があります.リアルタイムOSは動的な動き(さまざまな同期,通信,優先度の変更など)に対応するため,時間的な要素を考えるとテスト・ケースは無限にあります.機能テストだけではリアルタイムOSのすべての動作を検証できません.

 割り込み(イベント)はどこで発生するか分からないため,タイミングに起因する潜在的な不具合の可能性を完全に排除することはできません.そうなるとリアルタイムOSの性能テストで重要なのはテスト・シナリオの正当性(根拠)です.すなわち,ありそうな不具合状態を想定し,その想定を再現するテスト・ケースを設計することがかぎになります.

 そのような当を得たテスト・ケースを設計できるのは,リアルタイムOSの開発者であり,過去にリアルタイムOSの内部構造の不具合を経験したことがある技術者です.検証対象となるソフトウェアに対する効果的な性能テストを設計できるのは,そのソフトウェアの作成者であって,使用者側ではありません.まして,対象となる市販ソフトウェアの仕様も,市販ソフトウェアを搭載するシステムの使用環境も熟知していない第三者検証機関には,テストの妥当性を評価して安全を保証することができるはずはありません.

 より適切な性能テストを設計できるのは,市販ソフトウェアの開発者です.そして,テストの結果を評価してエンド・ユーザへの安全を保証する責務を負っているのは,市販ソフトウェアを製品に組み込んだ利用者です.このことを忘れてはいけません.


●市販ソフトウェア選定基準の変化

 これまでは,リアルタイムOSに限らず,市販ソフトウェア・ベンダが公に検証記録を利用者に提供することはありませんでした(業種によっては個別契約で提供することはあったようだ).その理由の一つとして,市販ソフトウェアに不具合があったとき,検証記録が製造物責任において不利な証拠になる,という判断もあったと思います.問題はなかったという検証記録を提出したにもかかわらず不具合が起こってしまった場合,検証記録はテストの漏れを示す証拠になるかもしれません.検証記録の提出は対象製品の信頼性の証明であるとともに,信頼性検証の漏れを示す記録にもなり得ます.市販ソフトウェア・ベンダにとって諸刃の剣なのです.

 しかし時代は変わりました.米国FDA(食品医薬品局)などの規制当局が市販ソフトウェアの妥当性確認をクリティカル・システムの製造業者に求めるようになった昨今,自社製品の信頼性の高さを示す検証記録を利用者に対して提出(販売)する市販ソフトウェア・ベンダも現れています.筆者はこの流れを歓迎したいと思います.何かあったときのことを恐れて検証記録を隠すネガティブな考え方ではなく,自分たちがやってきたことに対して自信をもってさらけ出し,現場で問題が起こったなら積極的に改善していくポジティブな姿勢を持つ企業を応援したいと思います.

 市販ソフトウェアは,かつてはブランドで選択することが多く,利用者はブランドを信用していました(図4).しかしそれでは,信頼性の根拠を問われたときに困ります.また,コスト優先で市販ソフトウェアを調達し,テストを自前で実施するという考え方もありますが,網羅性の高いテストを行おうとすると,結果的に高コストになることがあります.巨大化した市販ソフトウェアの検証にはばく大な工数がかかるからです.

 

図4 市販ソフトウェアの選択基準の推移(時代の流れ)

 

 そして現在は,市販ソフトウェアを検証記録の内容で選ぶ時代に変わりつつあると思います.市販ソフトウェアの利用者はまず,検証記録を提出できる企業から市販ソフトウェアの購入を検討し,次に検証記録の内容によって,採用するべきかどうかを選別します.この場合,検証内容を評価するためのスキルが必要になりますが,その評価を行わず,ブラック・ボックスのままで市販ソフトウェアをクリティカル・デバイスに使うことは,社会が認めてくれない時代になっています.見えないソフトウェアは少しでも見えるようになっている方が価値が高い,と評価されるようになってきたのです.

 

さかい・よしお

 

組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日