安全準拠システムの組み込みソフトウェアテストにおけるベストプラクティス

更新済み 2022/12/21

概要

規制関連の規格は、高度な保証を提供する複雑なアプリケーションにとってますます重要なものになっています。そのような規格には、長年にわたって確立されたものもあれば、主要業界で使われている新しい規格もあります。多くの規格は特定の業界のニーズに合うよう策定されていますが、コンプライアンスを明らかにするため、すべて同様の開発プロセスが必要です。同時にこれらの機能安全規格は、こうしたセーフティクリティカルな電子部品を開発するエンジニアや組織に多くの課題をもたらしています。たとえば、必要なドキュメントやアーチファクトを追跡する、機能要件がシステムレベルで適用されていることを確認する、新たな役割や知識の追加に伴って生じる組織的な課題に対処する、すでに導入されている開発プロセスに加えて新たなプロセスを順守できるように調整を図る、などが課題となっており、そうした課題はすべてコストの規模が制御不能とならないようにする必要があります。

通常、製品の設計では、プロセス全体のコンプライアンスや検討事項が考慮されますが、製品開発の検証という側面についても忘れずに対処する必要があります。機能安全規格の多くは、設計に加えてテストについても実施する必要のある要件と手順を具体的に定めています。同時に、開発サイクル全体で発生するあらゆる種類の検証において、それらの検討事項を考慮する必要があります。たとえば、MIL (Model-in-the-Loop) テスト、ラピッドコントロールプロトタイピング、HIL (Hardware-In-the-Loop) シミュレーションなどの純粋なシミュレーション検証、ダイナモメータや環境チャンバを使用した純粋な物理的テストなどが挙げられます。このホワイトペーパーでは、これらの規格に対するテストで発生する可能性のあるいくつかの課題を概説し、そうしたシステムの検証コストを最小限に抑える手法をいくつか紹介します。

機能安全規格の背景

機能安全とは、検証用に組み込みシステムに適用されるプロセス指向の安全認定基準のことです。たとえば、IEC 61508は自動車 (ISO 26262) や医療 (IEC 60601) などさまざまな業界で採用され、航空業界 (DO-178B/DO-254) の安全基準にも類似した機能安全規格としてよく知られています。認定対象の組み込みデバイスに義務付けられるライフサイクルプロセス以外にも、多くの規格がテストシステムの認定のために同様のライフサイクル要求を規定しています。

メーカーは、複雑なシステムの開発にあたって、製品のライフサイクルに機能安全対策を導入しています。たとえばリスク分析や要件トレースを行ったり、開発フェーズ全般にわたってテストとコード解析のプロセスを文書化したりします。例として、ISO 26262ではASIL (Automotive Safety Integrity Level: 安全性要求レベル) を特定して、テストプロセスの厳密性を決めることが必要になります。

図1. 障害の重大度、発生、および可制御性を知ることは、要件のASILを決定するのに役立ちます。

設計とテストの収束

開発者は、製品のライフサイクルの早期にコンポーネントと組み込みソフトウェアのテストを開始して、早い段階で欠陥を検出する必要があります。そうすることで、製品開発にかかる総コストを低く抑えることができます。本来なら開発プロセスの後の方で見つかっていたエラーに、早い段階で対処することが可能となります。最終段階の検証前にそれらの修正を行うことで、開発時間とプロジェクトのコストが全体的に削減できるほか、製品のリコールの可能性も少なくなります。メーカーでは、製品のライフサイクル全般にわたって数回のテストを実施することで、プロセス内でバグを特定することができます。

図2. 開発サイクル全体を通してさまざまなタイプのテストを実行することで、後続のプロジェクトの時間とコストを削減できます。

上図は、開発プロセスの各部分で推奨されるテスト方式を示すソフトウェア開発サイクルを表しています。HIL (Hardware-in-the-Loop) テストやMIL (Model-in-the-Loop) テストなどの方法は、さまざまな安全規格で推奨されるテスト方式です。

再構成可能プラットフォームを使用すると、開発のあらゆるフェーズでさまざまなテストをカスタマイズできるほか、複数のアプリケーション間でコンポーネントを再利用することが可能です。コンポーネントを再利用して、認定済みのテストシステムのコンポーネントをより大規模なアプリケーションの構成要素として使用することで、時間や費用といった大切なリソースを節約することができます。

図3. 共通のテストコンポーネントは、製品開発全体を通してテストのさまざまな段階で再利用できます。

開発プロセスにおいてテスト要件は変更されるため、そのような変更を管理しニーズに合わせてテストを再構成できるプラットフォームが必要です。たとえば、ISO 26262に基づいたテストを行っている自動車メーカーは、ECUテストシステムの一部を別の車種でも再利用することが可能な場合もあります。そのようなコンポーネントには、モデル、刺激プロファイル、ユーザインタフェース、データロギングなどがあります。

図4. テストコンポーネントはプロジェクトごとに大きく異なり、プロジェクトの数多くのさまざまな部分を表しています。

NIのツールは、機能安全テストを実施するための標準化されたテストシステムの開発に最適です。NIでは、機能安全の要求を満たすテストアプリケーションを短時間で開発できるソフトウェア/ハードウェア統合プラットフォームを提供しています。モジュール式ハードウェアプラットフォームを提供していますので、小型でより精巧な組み込みシステムのテスト要件に合わせて、同様のテストアプリケーションをスケールすることができます。NIが提供するソフトウェア定義の再構成可能プラットフォームを使用すれば、設計プロセスのあらゆるフェーズでコンポーネントをテストすることが可能です。

LabVIEW、LabWindows/CVI、NI VeriStand、NI Requirements Gateway、NI TestStandといったソフトウェアツールは、自動テスト業界で幅広く採用されています。そのようなソフトウェアツールを使用すると、PXIシステムなどのハードウェア製品との通信やモジュール式テストアプリケーションの構成が容易になります。コントローラと各種I/Oモジュールを搭載したPXIシステムなら、1つのプラットフォーム上でさまざまなコンポーネントをテストすることができます。テスト要件の変化に伴い、モジュールを追加したりソフトウェアプログラムを修正したりできますので、他社の開発者に新しいテスト用にシステムを再構成してもらうのに比べ少ない開発コストですみます。

DO-178Bなどの安全基準では、たとえばHILといった推奨テスト方式を明確に指定しています。NI HILプラットフォームは、多彩な製品が用意されたオープンなソフトウェア/ハードウェアプラットフォームです。NIが提供するテストアプリケーション用ハードウェア製品には、以下のようなものがあります。

CAN、LIN、FlexRay、MIL-STD-1553、ARINC 429などのネットワーク向けのアナログ/デジタルI/O高性能バスインタフェース用マルチファンクションデータ収集モジュール
欠陥生成ユニットで、電子テストシステムの開放と短絡をシミュレーション
ハードウェアI/O、データロギング、刺激生成、モデル実行などのタスクを確定的に実行するリアルタイムプロセッサ
ユーザによるプログラムが可能なFPGAを搭載した再構成可能I/O (RIO) で、さらに柔軟性に優れた高機能なテストシステムを構築できます。

NIでは、上記のハードウェア製品をすべてPXIフォームファクタで提供しています。そのため組み込みコントローラは複数のシャーシのモジュールと通信し同期をとることができます。リアルタイムPXIコントローラはNI Requirements Gateway、NI VeriStand、NI TestStandといったソフトウェアツールと簡単に通信できますので、要件トレース、HILシミュレーション、テストオートメーションなどが可能です。そのようなソフトウェアツールを使用すると、テストアプリケーションを低コストで効率的に認証することができ、多くの業界で機能安全対策に取り入れられています。

図5. NIのソフトウェアツールは、機能安全のコンプライアンスのテストにおける多くの側面に連携して対処できます。

要件管理と機能安全

品質やテスト戦略を効果的で費用対効果の高いものとするためには、それらの要件を明確に定義する必要があります。要件は、製品の正確な機能を定め、製品が適切かつ完全にテストされることを保証するのに役立ちます。要件管理ツールを使用すると、要件の保存や解析のプロセスをコスト効率の良いものにすることができます。また、コンプライアンス基準を設けることで、高レベル/低レベルの要件と、製品における要件の実装との間の関連性を証明する必要性が明確になります。大部分のエンジニアリングプロジェクトは、仕様書作成に始まり、プロジェクトの進行に従って仕様書がより詳細に定義されます。仕様書には、各技術段階で製品を完成へと導く技術要件と手順要件があります。さらに、ハードウェアの回路図、シミュレーションモデル、ソフトウェアソースコード、テスト仕様書およびテスト手順書などの作業用ドキュメントは仕様書により定義された要件に従い、その要件を網羅している必要があります。

図6. NI Requirements Gatewayを使用すると、元のプロジェクト要件から、実行されたテスト、さらにテスト結果までのトレーサビリティを直接表示することができます。

要件からテスト、測定、制御ソフトウェアに至るまでの関連性のトラッキングは、実装の検証、要件の変更が及ぼす影響の解析、およびテストが不合格になった場合の影響に関する理解に極めて重要です。この範囲と影響の解析はエンジニアが要件を満たし、開発の手間を効率化するために役立ちます。

共通の検証フレームワークを使用して要件を早期に確定

機能安全規格に準拠したプロジェクトや電子システムを開発するためには、要件を厳密に順守することが必要になります。プロジェクトのライフサイクル全体で実行されるすべてのステップが、さかのぼってトレースでき、システムレベルの要件と直接結び付いている必要があります。プロジェクトがどの開発段階にあっても、システム全体の動作を検証するために、一定レベルのテストが実行されます。この検証はいくつかのポイントで行われ、要件へのトレーサビリティを示す必要があります。そのため、要件に一貫性があり、時間の経過とともに変化しないことが重要です。こうしたことは他のプロジェクトと同様に課題となる可能性があり、時間の経過とともにシステムの要件が変更されると、設計の新規追加だけでなく、新たな要件の検証にも非常に多くのコストがかかる可能性があります。こうしたことから、企業各社は要件について当初からできるだけ十分な自信を持てるようにする手段を模索しています。そうした手段であれば，後の変更が少なくなり、テストのコストが大幅に削減されます。

ISO 26262などの規格を見ると、要件にはASIL (Automotive Safety Integrity Level: 安全性要求レベル) が割り当てられています。ASILは、障害の重大度、障害の発生の頻度、そして障害の防止または修正の可制御性という、3つの主要な要素に基づいています。これら3つの要素について把握している情報が多いほど、ASILレベルの割り当てに対する自信が高まります。その結果、明確に定義された要件が得られ、後で変更される可能性が少なくなります。たとえば、ECUのプロトタイプを早期に開発しておけば、具体的な障害の発生頻度を監視、記録して、発生の可能性を理解し、ASIL定義の要素の1つに不可欠な情報を得ることができます。

通常、ECUなどのデバイスのプロトタイプ開発は、要件の定義、および開発サイクルの初期段階での要件の検証という、2つの目的に役立ちます。つまり、プロトタイプ開発で要件を定義し、それを開発の早期の段階で取り入れる、という考え方です。後でラピッドコントロールプロトタイピングなどのステップで要件を検証する際に、提案した同じフレームワークを使用することで、プロトタイプ開発の初期の段階から特定のテストコンポーネントを再利用できるため、時間と労力を大幅に節約できます。初期のプロトタイプ開発の準備に時間と労力をかけることで、後で特定のコンポーネントを再利用できるようになり、初期のプロトタイプ開発がプロジェクトのコストに及ぼす影響を最小限に抑え、プロセスの後半で要件を変更するよりもはるかに妥当なコストにすることができます。

図7. 初期のプロトタイプ開発で、他のタイプの検証の場合と同じテストアーキテクチャで、より適切に要件を定義することで、開発全体の時間を節約できます。

認定を受けた市販の検証ツールの利用

先に進む前に、現在開発中のプロジェクトについて考えてみましょう。通常、現在取り組んでいる作業について検証したいが、それを何らかの要件形式に合わせて検証する必要があるという場合には、テストが正確であることを確認する必要があります。このことは、特に機能安全規格を適用する規制対象の業界の場合に当てはまります。もし検証に誤りがあると、プロジェクトが製造環境のセーフティクリティカルな状況に置かれたときに、極めて悪い結果が生じるおそれがあります。その一方で、自動車/航空宇宙などの多くの業界では電子機器の複雑さが増していることから、テスト項目はますます増えていますが、そのために割り当てられる時間が必ずしも増えるわけではないため、検証の一部を自動化したい、または自動化しなければならないという状況になっています。しかし、たとえば何らかのテスト自動化ツールを利用しようとする場合、そのツールが期待どおりに機能することをどのようにして確かめればよいのでしょうか。テスト自動化ツールを自社で開発するのはコストが非常に高くなる可能性があります。特に機能安全を念頭に置いた設計を確保したい場合はなおさらです。さらに、全体的な検証を行うために、非常に具体的で徹底したドキュメント化が必要になり、そうしたドキュメントの作成をしっかりと進めるためには非常に多くの時間がかかる可能性があります。そのため、ツールを利用する場合は、適切なアーチファクトの作成が必要になるでしょう。では、手動による検証しかないのでしょうか。

機能安全のプロジェクトについて特定の方法で認定を受けた市販の検証ツールであれば、このようなニーズに応え、テストツールに十分な信頼を置くことができます。その一例として、NIのアライアンスパートナーであるCertTech LLCは、テスト自動化ソフトウェアツールであるNI TestStandの認定キットを開発しました。 NI TestStandは、自動テストシステムの開発、実行、デプロイがより短時間で行えるよう設計されたテスト管理ソフトウェアです。 CertTechは規制対象の業界や機能安全規格について豊富な経験を積んでおり、DO-178CやISO 26262といった規格で定められている認定ツールの使用要件を熟知しています。 NI TestStandの認定キットは、ごく一般的に使用される機能について要件とテスト範囲を包括的に網羅しており、指定された要件を検証するためのテスト一式を備えています。また、容易に拡張できるフレームワークも提供しているので、必要に応じてテスト範囲を拡張できます。さらに、必要なドキュメントがツールから作成されるので、コンプライアンスに必要なアーチファクトとして使用できます。必要なドキュメントの準備は欠かすことができません。なぜなら、検証プロセスの完全な透明性を示すことが全体的な目標であり、そうすることでテストを再現し、実行されたことについてすべての詳細を明確にできるからです。

ISO 26262やDO-178Cなど、最近の一部の機能安全規格では、プロジェクトにおいて手動で確認が行われない検証/確認の作業について「認定ツール」を使用することを義務付ける具体的な情報があり、NI TestStandのような認定ツールの使用がさらに重要視されています。これらの規格では、ツールが適切にテストされていない場合の全体的な影響を評価することを求めており、ISO 26262などの規格でツール信頼レベル (TCL) と呼んでいるものを割り当てています。 TCLを決定する要素は2つあります。1つはツールの影響 (TI) で、もう1つはツールのエラー検出 (TD) です。「ツールの影響」には、TI0とTI1の2つのクラスがあります。TI0は、ソフトウェアツールが誤動作しても安全要求に違反する可能性がない場合に選択します。その他のケースでは、TI1を選択します。「ツールエラー検出」は、TD1からTD3に分類されます。TD1は信頼度が高く、TD2は中間、TD3は低信頼度となります。テストツールのTCLレベルが異なると、ユーザに与える余分な負担の度合いが変わります。

		ツールエラー検出
		TD1	TD2	TD3
ツールの影響	TI1	TCL1	TCL1	TCL1
ツールの影響	TI2	TCL1	TCL2	TCL3

図8. ISO 26262規格のツール信頼レベルは、ツールのエラー検出能力とツールの全体的影響を評価して算出されます。

まとめると、ツールの信頼性に対する自信が大きいほど、ツールが期待どおりに機能していることを証明するために実施する必要のある作業は少なくなります。つまり、誰もが機能安全プロジェクトの検証にNI TestStandのような市販のテスト自動化ツールを利用でき、そうしたツールを要件の検証に利用する場合でも必要な自信を得ることができる、ということになります。

検証をプロジェクト管理全体にシームレスに統合して組織への影響を簡素化

新しいプロセスを採用する際の最大の課題の1つは、特に現在のプロセスがすでに現場に導入されている場合に、組織全体に及ぼす影響に対処することです。機能安全規格に準拠する電子システムを開発しようとしている企業は、まさにこうした事例に当てはまります。 ISO 26262のような機能安全規格に準拠した新しいプロセスを採用したいという場合には、組織的な決定や理念を順守する必要があります。通常は、新たな個別の役割と、具体的なプロジェクト管理プロセスを導入し、主要なコンポーネントの知識を共有するのに必要となる新たな手法を取り入れることになります。言うまでもなく、こうした企業では自動車業界のSPICEなど、これまで順守してきた独自の開発プロセスをすでに持っており、そのうえにさらにプロセスを設けたいと考えています。このホワイトペーパーで終始説明しているように、プロセスの検証コンポーネントは非常に重要であり、これらすべての側面にわたって考慮する必要があります。そのため、テストを関連するすべての部分に統合することが必要不可欠です。

こうした課題に対処するうえで、たとえばIBM Rationalが提供しているようなアプリケーションライフサイクル管理ツールは、そのための強力な支援手段となる可能性があります。これらのツールに組み込まれているユーティリティは、プロジェクト管理全体のフロントエンドとバックエンドの知識の両方を共有し保存するのに役立ちます。 NIではIBMと提携して、このツールを検証/確認の分野で特に価値あるものに仕上げました。 NIのテストツールとIBMのRational製品を統合することにより、テストコンポーネントをより簡単に管理し、検証したうえでアプリケーションライフサイクル管理全体に取り入れることで、一貫性、効率性、および再利用を向上させることができます。さらに、NIの製品のテスト結果がIBMのツールにシームレスに組み込まれるため、一貫性のあるドキュメントが作成、保存され、同時にプロセスも自動化されます。こうしたタイプのプロジェクト管理をドキュメント/テスト結果の管理と組み合わせることで、組織の全体的なコラボレーションを大幅に強化し、開発プロセス全体にわたって知識の共有を最大限まで高めることができます。

図9. これまでテストは通常別のものとして捉えられていましたが、アプリケーションライフサイクル管理の他の側面に統合することで、エンドツーエンドの品質管理システムを簡単に構築できます。

まとめ

機能安全規格の導入は企業に多くの課題をもたらしています。ドキュメント化の完全性、システムレベルの要件の収集と検証、組織上の変更、そしてプロセスの効率的な導入を、適切な手法やアプローチでサポートすることができます。テストコンポーネントの再利用性と、要件のトレーサビリティの自動化については、特別な注意を払う必要があります。ライフサイクル管理ツールはトレースの維持に役立ち、プロトタイプ開発は要件を早い段階で統合できます。組織で自動検証のツールを使用する際は、認定キットを利用することで安全基準に準拠できます。 NIでは、パートナー各社とも連携しながら、企業がこうした課題に対処できるよう支援する確認/検証プラットフォームを提供しています。