10
1 ホワイトペーパー ISO 26262準拠の自動運転車用 ソフトウェア A VerocelおよびRTIホワイトペーパー Verocel Joe Wlad , 執行役員 ビジネス戦略 RTIDavid Barnett , 副社長 プロダクトマーケティング RTIBob Leigh , マーケティング開発部長 はじめに ソフトウェア駆動システムは現在、あらゆる業界のイノベーションの柱となっています。 この傾向は、自動車用途よりも 深刻なものではありません。 自動車のソフトウェアの使用は、基本的なシステム診断から情報およびエンターテイメント システムまで広がっており、自律走行機能を完成させています。 現代の車両には、エンジンとトランスミッションの制御、 制動、ステアリング、およびあらゆるサブシステムに関する多数の診断情報を管理する数千万のソフトウェアラインが出 荷されています。 この傾向により、自動車設計者は、システム、ハードウェア、およびソフトウェア設計を含む方法で安 全に取り組まなければなりませんでした。 安全関連アプリケーション用のソフトウェアの開発に適用さ れる多くの標準およびガイダンス文書がありますが、ほとん どは特定の業界に固有のものです。 例えば、航空業界は RTCA / DO-178Cを使用し、産業開発者はIEC 61508を使用 し、医療機器メーカはIEC 62304を使用することができる。 自動車業界は、ハードウェアとソフトウェアの両方を含む電 子システムの機能安全基準としてISO 26262を採用していま す。 ISO 26262IEC 61508に適合しており、多くの共通要件 がありますが、特に安全レベルの決定に関連する分野には いくつかの独自の違いがあります。 私たちの顧客から、ISO2626の承認を予定しているシステムで、市販の(COTS)ソフトウェア(安全性の証明されている かどうか)をどのように使っていますかという質問がよくあります。 ISO 26262システムでCOTSソフトウェアを適用する方 法を検討する前に、まずISO 26262規格の内容と構成を理解する必要があります。

ISO 26262準拠の自動運転車用 ソフトウェア道路車両の認定ソフトウェア部品を使用したISO 26262準拠 rti.com 3 以下に、 ISO 26262の各セクションの内容を簡単に説明します。:

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

  • 1

    ホワイトペーパー

    ISO 26262準拠の自動運転車用

    ソフトウェア

    A VerocelおよびRTIホワイトペーパー

    Verocel 社 Joe Wlad , 執行役員 ビジネス戦略

    RTI社 David Barnett , 副社長 プロダクトマーケティング

    RTI社 Bob Leigh , マーケティング開発部長

    はじめに

    ソフトウェア駆動システムは現在、あらゆる業界のイノベーションの柱となっています。 この傾向は、自動車用途よりも深刻なものではありません。 自動車のソフトウェアの使用は、基本的なシステム診断から情報およびエンターテイメントシステムまで広がっており、自律走行機能を完成させています。 現代の車両には、エンジンとトランスミッションの制御、制動、ステアリング、およびあらゆるサブシステムに関する多数の診断情報を管理する数千万のソフトウェアラインが出

    荷されています。 この傾向により、自動車設計者は、システム、ハードウェア、およびソフトウェア設計を含む方法で安全に取り組まなければなりませんでした。

    安全関連アプリケーション用のソフトウェアの開発に適用さ

    れる多くの標準およびガイダンス文書がありますが、ほとん

    どは特定の業界に固有のものです。 例えば、航空業界は

    RTCA / DO-178Cを使用し、産業開発者はIEC 61508を使用

    し、医療機器メーカはIEC 62304を使用することができる。

    自動車業界は、ハードウェアとソフトウェアの両方を含む電

    子システムの機能安全基準としてISO 26262を採用していま

    す。 ISO 26262はIEC 61508に適合しており、多くの共通要件

    がありますが、特に安全レベルの決定に関連する分野には

    いくつかの独自の違いがあります。

    私たちの顧客から、ISO2626の承認を予定しているシステムで、市販の(COTS)ソフトウェア(安全性の証明されている

    かどうか)をどのように使っていますかという質問がよくあります。 ISO 26262システムでCOTSソフトウェアを適用する方

    法を検討する前に、まずISO 26262規格の内容と構成を理解する必要があります。

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 2

    ISO 26262、第1版は10のパートで構成され、電気および電子自動車システムの安全ライフサイクルの側面をカバーして

    います。 下記の図1は、ISO 26262から抜粋したもので、各パートの重要な要件を要約しています。 パート3から7は、コン

    セプトフェーズから設計、生産までの製品開発を扱うコアパートです。 10のセクションの概要を以下に示します。

    図1: ISO 26262プロセスおよび要求(ISO 26262認証)

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 3

    以下に、ISO 26262の各セクションの内容を簡単に説明します。:

    Part1. 用語:標準で使用されている用語の定義と説明を提供します。

    Part2. 機能安全管理:開発中およびリリース後に組織および内部プロセスをどのように使用するかに関する要件とガイダンスを提供します。

    Part3. 概念フェーズ: アイテム定義、アクティビティ、ハザード分析、リスクアセスメントなどのライフサイクルの記述に関する要件とガイダンスを提供します。

    Part4. 商品の開発:システムレベル:システム要件、安全要件、安全コンセプト、システム設計、統合テスト、安全性検証、安全性評価、製品リリースの開発に関する要件とガイダンスを提供します。

    Part5. 商品の開発: ハードウェアレベル: ハードウェア製品の開発、ハードウェアの安全要件、ハードウェアのアーキテクチャメトリクスの評価、およびハードウェアの障害による潜在的なセーフティゴール違反の評価を含むハードウェア

    設計の要件とガイダンスを提供します

    Part6. 商品の開発: ソフトウェアレベル: ソフトウェア製品開発の開始、ソフトウェア安全要件の指定、ソフトウェア設計、ユニット実装、ユニットテスト、統合テスト、ソフトウェア安全要件の検証に関する要件とガイダンスを提供します。

    Part7. 生産および運営: 道路車両に使用される安全関連要素の製造プロセスの開発と維持のための要件と指針を提供し、生産プロセスにおける機能安全を達成する。

    Part8. 支持工程: 全体的な安全管理、分散開発内のインタフェース、構成管理、変更管理、検証、文書化、ツールの使用、ハードウェアとソフトウェアコンポーネントの認定、実証済みの議論に関するガイダンスと要件を提供します。

    Part9. ASIL(自動車安全完全性レベル)志向と安全性の分析: ASIL分解(システム、ハードウェア、ソフトウェア、コンポーネント間)のガイダンスと要件を提供し、安全要件と障害分析および安全性分析。

    Part10. ガイドライン(参考): ISO 26262の主要概念、IEC 61508との違い、ASIL分解、安全性ケース、ハザード分析、およびリスクアセスメントに関する追加の詳細を読者に提供します。

    • ISO 26262の各サブセクションも同様の方法でフォーマットされています。この文書は、一般的な要件(例えば、ソフトウェア

    レベルでの製品開発の開始)、入力(例えば安全計画)、要件(例えば、ソフトウェアレベルでの製品開発のための活動が

    計画されなければならない)製品(ソフトウェア検証計画など)です。全体的な観点から、ISO 26262のすべてのセクション

    は、(適切な自動車安全性インテグリティレベルで)対応されているとみなされる必要があります。コンプライアンスへの高

    いレベルのステップには、安全計画の作成と承認、安全目標と安全性のケース、および双方向トレーサビリティによる完

    全な安全ライフサイクルが含まれます。活動と作業成果物には、検証、検証、独立した評価(認定機関による)、必要な活

    動を支援する完全な文書のリストが含まれます。

    さらに、ISO 26262の構造は、開発の各主要部分の活動、検証、評価が独立して行われるようにカプセル化されています。

    したがって、ハードウェアまたはソフトウェアのコンポーネントを1つのシステムまたは要素で評価および承認した後、他の

    システムおよび評価で承認を再利用することが考えられます。実際、ISO 26262の第8-12項および第8-13項は、それぞれ

    ソフトウェアおよびハードウェアコンポーネントの承認要件を直接扱っています。

    ISO 26262認証, Part6 : ソフトウェア要件

    前述のとおり、Part6はISO 26262の中核プロセス要件であり、機能安全管理、構成管理および変更管理などのサポートプ

    ロセスは含まれていません。 Part6の要件は、開発と検証の滝モデルで指定されています。 ISO 26262は、ソフトウェア開

    発の特定のモデル(機敏性、反復性など)を想定していませんが、ソフトウェアが特定のモデルで設計されているかのよう

    に要件を文書化すると便利です。 実際、DO-178CやIEC 61508などの他のソフトウェア認証ガイダンスと標準も同様の方

    法で書かれています。 ISO 26262に準拠するためにソフトウェアを開発する最初の要件は、安全計画とソフトウェア検証計

    画を開始することです。 これらの計画はもちろん、他のプロセス計画(ISO 26262のPart2と8で定義されている)によってサ

    ポートされます。

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 4

    開始アクティビティが完了すると、ソフトウェア安全要件プロセスの仕様が実行されます。 ここには、安全概念と全体的な

    システム設計への不可解なリンクがあります。 システム設計およびまたはハードウェア設計は、ソフトウェアに制限および

    負担を課し、これらの制約は要件プロセスの一部として考慮する必要があります。 ISO 26262で承認されたソフトウェアコ

    ンポーネントの候補としては、システムやハードウェアのデザインに明確に定義され、公開されている可能性があります。

    これは、任意のシステムまたはハードウェアが特定のソフトウェアコンポーネントをサポートすることを意味するものではな

    く、任意の制限または条件がインテグレータに公開されることを意味します(たとえば、必要に応じてメモリおよびCPUの制

    約が特定の要件になります)。 このフェーズから生じる作業成果物には、ソフトウェア要件仕様、洗練されたハードウェア

    とソフトウェアのインタフェース仕様、およびソフトウェア検証活動の結果が含まれます。

    ソフトウェアアーキテクチャ設計プロセスは、ソフトウェアがあいまいさなく書かれることを可能にする要件を定義します。デ

    ザインはさまざまな方法(正式または半正式)で指定することができ、ISO 26262は、必要なASILに応じてどの表記法を使

    用すべきかに関する推奨事項を持っています。さらに、ISO 26262は、安全性要素(サイズや複雑さの制限など)に役立つ

    ソフトウェア設計の特性を規定しています。設計プロセスがソフトウェアコンポーネントの分割を採用する場合、干渉の自

    由が保持されることを示すために追加の要件が課されます。ソフトウェア設計の検証方法はASILによって異なりますが、

    より重要な点については、設計ウォークスルー、検査と制御、データフロー解析が推奨または推奨されています。設計プロ

    セスの結果として生じる作業成果物は、ソフトウェア設計仕様、障害分析レポート(分割が使用される場合)、および文書

    化された検証結果です。

    ソフトウェアユニットの設計および実装段階は、ソフトウェア要件および設計情報がソフトウェアモジュールの作成に使用さ

    れるコーディング段階として一般的に知られています。コーディングフェーズの要件には、一貫したインターフェイス、堅牢

    な実装、検証可能性、テスト容易性などがあります。 ISO 26262では、実装が各モジュールまたは関数を記述するのに十

    分な設計の詳細に依存していることが必要です。言い換えれば、低レベルの要件または設計情報がソフトウェア機能に対

    して一意にトレーサブルでない場合、コンプライアンスのギャップが存在する可能性があります。 ISO 26262で要求されて

    いる実装のプロパティには、再帰、ポインタの使用制限、無条件ジャンプなどはありません。ソフトウェア実装の検証活動

    には、静的コード分析、コーディング標準への準拠、制御フロー分析とデータフロー分析、規定された要件と設計データに

    よる適合性(トレーサビリティを含む)が含まれます。このフェーズの出力には、検証結果と完成したソフトウェア実装が含

    まれます。

    ソフトウェアユニットのテストフェーズは、単なる個々のソフトウェアモジュールの構造単位テストであるという意味で誤解を

    招くように見えるかもしれません。 ISO 26262では、テストには要件と設計の適切な実装の検証が含まれていることが要求

    されるため、テストケースは実装からではなく要件から直接作成する必要があります。 さらに、ユニットテストフェーズでは、

    実装に意図しない動作が存在せず、実装が堅牢である(たとえば、異常な入力条件に正常に応答できる)ことを示す必要

    があります。 関連性のあるASIL(例えば、声明、決定または修正された条件/決定カバレッジ)に必要なカバレッジを示す

    ことによって、完全性および意図しない行動の欠如が実証されます。 このフェーズの出力には、テスト結果が正確で完全

    であり、必要なカバレッジを発揮していることを示す検証レポートが含まれています。

    ソフトウェアの統合とテストのフェーズは、ソフトウェアユニットのテスト段階で検証されたソフトウェア要素(またはコンポー

    ネント)が完全に統合され、完全にテストできることを実証することを目的としています。統合フェーズには、安全関連と非

    安全関連の両方の要素が含まれる場合があります。統合テストでは、ハードウェアとソフトウェアのインタフェースの正しさ

    と、ソフトウェアアーキテクチャ設計への準拠性を検証します。統合テストには、要件ベースのテスト、統合テスト、フォルト

    インジェクションテスト、リソース使用率テスト(スタック、ヒープ、実行時間など)が含まれ、理想的にはソフトウェアアプリケ

    ーションの実際のターゲットハードウェアで実行する必要があります。統合テストに適用されるメトリックは、機能カバレッジ

    とコールカバレッジです。機能テストおよびコールカバレッジテストでは、実行されていないソフトウェアが表示される場合

    があります。この場合、ソフトウェアを削除するか、無効にする必要があります。無効化されたコードの分析が、検証された

    ソフトウェアの動作を損なわないことを確認するために、無効化されたコードの分析を行う必要があります。ユニットテスト

    フェーズではデッドコードを公開する必要があるため、非アクティブ化されたコードはデッドコードではないという意味で、要

    件へのトレーサビリティがないという意味ではないとみなされます。このフェーズの出力は、統合されたソフトウェアと検証

    レポートであり、統合テストの目的が正常に完了したことを確認します。

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 5

    ソフトウェア安全要件の検証は、ISO 26262のソフトウェア検証の最終段階です。この段階は、実際のターゲット環境でソフ

    トウェア要件が満たされているかどうかを確認するために使用されます。 現時点までに、実際の生産車両に使用すること

    を意図していないシミュレートされたハードウェアまたは参照ハードウェア上で、テストおよび検証を行うことができます。

    この段階のテスト環境は、実際の車両、統合テストベンチ、またはテスト中のソフトウェアに関連する実際の車両アーキテ

    クチャを再現するネットワーク環境であってもよいです。 このフェーズの出力は、実際のハードウェア環境でテストの目的

    が正常に完了したことを確認する検証レポートです。

    Part6の要件を満たすためのCOTSアプローチ

    ISO 26262 Part6およびその他のISO Partの編成は、さまざまなアプリケーションで使用することを意図したCOTSソフトウ

    ェアコンポーネントの承認、評価、および再利用に非常に役立ちます。 まず、ソフトウェアライフサイクル要件の構成と

    Part6のアクティビティがステージングされます。つまり、あるフェーズの出力が次のフェーズの入力であることを意味しま

    す。 Part6で定義されている3レベルのソフトウェアテストがあり、それぞれのテストはソフトウェア統合の増加の結果です。

    例えば、ソフトウェアコンポーネント開発者は、後に自動車制御システムに組み込むことができる参照ハードウェア上の分

    散データサービスまたはソフトウェアバスなどのコンポーネントをテストすることができます。 この場合、ソフトウェアコンポ

    ーネント開発者はPart6の要件のサブセット(およびその他のPart)を満たし、残りのコンプライアンス目標をインテグレータ

    に任せます。

    ソフトウェアコンポーネントに関連するISO 26262の他の部分には、Part2(機能安全管理)とPart8(サポートプロセス)が含

    まれます。 ソフトウェアコンポーネント開発者は、内部計画プロセスがPart2の要件に沿っていることを実証する必要があ

    ります。 最低限、これには機能安全管理計画と品質管理計画だけでなく、開発段階と生産段階の両方で安全文化を実施

    するための訓練を受けた責任者と安全文化の証拠が含まれます。 ISO 26262の要求事項を遵守していることを証明する

    検証計画、検証計画、およびテスト計画が、必要となる(および安全計画または品質計画で定義される)追加の計画です。

    サプライヤーが第2部の要件をサポートできるようになると、第2部で開発されたソフトウェアがISO 26262の他の部分をサ

    ポートできるようにするための枠組みがあります。

    計画プロセスには、該当するツール資格計画への参照も

    含まれます。 これには、ソフトウェアモデリングツール、カ

    バレッジ分析ツール、開発または検証アクティビティで使用

    されるその他のツールが含まれます。

    ISO 26262Part8は、ソフトウェアコンポーネントサプライヤ

    に関連しています。 第8部では、文書管理、構成管理、変

    更管理、およびISO 26262で使用されているツールの資格

    要件に関する要件を定義しています。Part8の第12項は、

    ソフトウェアコンポーネントの資格要件を定義しているため、

    ISO 26262に基づくソフトウェアコンポーネントの承認が可

    能であるという考えを明確にしています。

    Part8の第12節の下でソフトウェアコンポーネントを適格にするための要件は以下のとおりです。

    • 機能、リソースの使用状況、応答時間、障害発生時の動作および堅牢性に対処する要件

    • 構成、インタフェース、およびコンポーネントを統合する方法、および異常条件の下での動作の説明、および既知の制限および回避策(既存の欠陥と限界の両方を含む)の説明

    • 通常および異常状態および提案ASILに適用する必要な構造カバー範囲についての分析を含むことに対する堅牢性が含まれ、検証がすべての適用ソフトウェア要件のフルカバーを示すこと

    • ソフトウェアの識別および構成のドキュメンテーション、目標ASIL、ハードウェア互換性限界、資格を実行する組織、およびソフトウェア構成要素に適用される検証手段の結果

    • 認定の結果および結果の妥当性を検証しなければならず、必要であれば、追加的活動を実行する必要がある

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 6

    上記の最後の点は、ISO 26262のソフトウェアコンポーネント再利用の価値を決定する重要な要素になります。

    異なる環境での資格結果の妥当性を確立することで、インテグレータ側では、いくつかの追加活動が常に強制されます。

    提供されたソフトウェアコンポーネントが使用、承認、および制限の範囲を適切に文書化していない場合、インテグレータ

    は、それぞれの環境でコンポーネントにISO 26262のクレジットを適用しようと試みることに挑戦されることがあります。 認

    定されたソフトウェアコンポーネントを使用する際の考慮事項に関する追加情報は以下のとおりです。

    RTI Connext® DDS Micro ISO 26262認定ソフトウェアコンポーネント

    Real-Time Innovations、Inc.(RTI)は、ミッション・セーフティ・クリティカルなアプリケーションで幅広く使用されている

    Connext DDS製品の認定バージョンを取得しています。 Connext DDSは、ソフトウェア開発者やインテグレータに、デバイ

    ス、アプリケーション、サブシステム間でリアルタイムデータを配信するための高水準インタフェースを提供します。 たとえ

    ば、Connext DDSを使用すると、ビデオ、レーダー、LIDARデータをアナリティクスや自律駆動アプリケーションに流すこと

    ができます。また、これらのアプリケーションを従来のECUと統合することもできます。 Connext DDSは、アプリケーションと

    基礎となるオペレーティングシステムおよびネットワークスタックの間にあるライブラリであるため、低レベルのネットワーキ

    ングの詳細を抽象化する高水準のパブリッシュ/サブスクライブインターフェイスを開発者に提供するため、「通信ミドルウ

    ェア」と呼ばれることがあります。

    Connext DDS Certは、DDS(Data Distribution Service)ファミリの標準をサポートし、ASIL-Dを含むISO 26262の認証をサ

    ポートする、完全かつ商業的にサポートされている認定パッケージで利用可能な認定ミドルウェアです。 このパッケージに

    は、TÜV SÜDなどの証明機関が必要とするすべての証拠が含まれています。

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 7

    広く使用されている業界標準に準拠した認定ミドルウェアを使用すると、多くの重要な利点があります。

    • 大幅なコスト削減:カスタム通信と統合ロジックを大幅に削減することにより、Connext DDS Certは数十万行のコードを節約でき、数百万ドルの認証コストを回避できます。

    • リスクの低減:安全ソフトウェアを開発するためには、厳密な一連の手順に従わなければなりません。これらの手順が元の開発に従わなかった場合、ソフトウェアの開発や再開発は危険です。

    • レバレッジ経験:RTIは、多くのミッションセーフティクリティカルな業界でDDSを使用してきました。 ソフトウェア、DDS標準、および認証パッケージは、1000以上のプロジェクトからの深いアーキテクチャ経験に基づいて開発されてい

    ます。

    • 信頼性:新しい標準またはカスタム開発の取り組みには、長年にわたって信頼性を実証してきた、長年のプロジェクト経験と現場展開がありません。

    • 相互運用性:DDSは多くのベンダーによってサポートされており、標準規格と主要ベンダー間の頻繁なテストにより相互運用性が保証されています。

    • オープンアーキテクチャ:Connext DDSは、FACE(Future Airborne Capability Environment)、UCS Control Segment(UCS)アーキテクチャ、OMS(Open Mission Systems)など多くのオープンアーキテクチャイニシアチブと連携してい

    ます。

    • コンポーネントの分離:認定ミドルウェアの最も重要なメリットは、最高レベルの安全規格に準拠した通信フレームワークにより、システムのさまざまなソフトウェアコンポーネントが分離され、情報の通信や共有が行われていても

    異なる安全レベルでの認定が可能になることです。

    認定されたミドルウェアは、製品ライフサイクル全体を通じてコスト削減を引き続き行うことができます。 開発と認証のコス

    トを最初に節約した後、コンポーネントの分離とアプリケーションの疎結合を組み合わせることで、システムの変更されて

    いない部分を再認証せずに個々のコンポーネントのアップグレードと再認証が可能になるため、メンテナンスコストとライフ

    サイクル開発コストを削減できます。 これらのコスト削減は、製品の寿命にわたってオリジナルの証明コストを犠牲にする

    可能性があり、ソフトウェアシステムの重要な差別化要因になる可能性があります。

    自動車市場では、これは特に、複数のソフトウェアコンポーネントがデータを共有しなければならない車載の高度運転支

    援システム(ADAS)および自律駆動アプリケーションに適用されます。うまく設計されたシステムでは、これらの相互依存

    システムは疎結合であり、機能に応じて様々なレベルの認証が必要です。例えば、感知・回避制動システムは、ASIL-Dへ

    の認定を必要とする可能性が高く、センシング、クリティカル・メイキングに不可欠なソフトウェアは、この認証を必要としま

    す。 (例えば、センサ、ECU、ソフトウェアアルゴリズム、制動およびステアリングモジュールなど)。 しかし、ナビゲーション

    や経路計画などの機能では、同じコンポーネントの一部とやり取りする必要があるかもしれませんが、認証レベルがはる

    かに低いか、認証がまったく必要ない可能性があります。これらの機能を分離して独立させるための認定ミドルウェアがな

    ければ、すべてのコンポーネントが最高の認定を取得する必要があり、非常に高価で、機能が制限されたシステムとなり

    ます。

    ISO 26262適合ソフトウェアコンポーネントの使用に関する考察

    上記のように、ISO 26262の第8部12節は、ソフトウェアの再利用のための要件に対応しています。 再利用は、第三者から

    調達されたベンダー独自のソフトウェアまたはCOTSソフトウェアに適用される可能性があります。 COTSコンポーネントを

    使用すると、インテグレータが親しみがなく、異なる標準や計画を使用したり、さまざまな検証方法やツールが使用されて

    いるため、これらのコンポーネントを承認しようとすると、いくつかの障害が発生します。 COTSサプライヤは、ISO 26262の

    コンプライアンスを実証するために必要な文書とデータを提供することができますが、インテグレータは依然として使用の

    最終承認を得る責任があります。 Verocel の経験では、ISO 26262で承認されたシステムで使用されるソフトウェアコンポ

    ーネントは、次の特性を持つ必要があります。

    • ハードウェア依存性がない。もしくは少ししかない。

    • さまざまなハードウェアプラットフォームへの移植が容易

    • 他のソフトウェアコンポーネントとハードウェアとの境界を明確にする

    • バイナリまたは事前にリンクされた形態で提供され、再構築の必要性を排除する

    • 限られた複雑さ

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 8

    • 変更の影響を最小限に抑えた改良および拡張が可能

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 9

    上記で定義した特性は、サプライヤとユーザの両方に経済的、技術的、および認証的価値を提供します。 認可されたソフ

    トウェアコンポーネントにも、さまざまなアプリケーションで使用されるものと、インテグレータにとってあまり役に立たないも

    のがあります。 再利用可能なソフトウェアコンポーネントの良い例としては、オペレーティングシステム、通信およびメッセ

    ージングソフトウェア(RTI Connext DDS Certなど)、言語およびグラフィックスライブラリ、ファイルシステムインターフェイ

    スなどがあります。 Verocelは、航空宇宙、産業および医療業界のさまざまな顧客向けに、これらのソフトウェアコンポーネ

    ントのそれぞれに認定活動を行っています。

    Verocelは、ソフトウェアコンポーネントとその認証データをどのように使用してさまざまなアプリケーションに適用するかに

    ついてのガイダンスを提供することで、インテグレータの認証負担とリスクを最小限に抑えることができることを学びました。

    ISO 26262で承認されたソフトウェアコンポーネントには、以下のデータと情報が含まれている必要があります。そのため、

    ISO 26262の承認のためにインテグレータがコンポーネントに精通し、より容易に表現できるようになります。

    • 承認済みエンティティ(TüVなど)からのISO 26262準拠証明書。

    • ソフトウェア安全計画: 安全計画はソフトウェアコンポーネントを定義し、求められたコンプライアンスの概要を提供する。また、ソフトウェア計画プロセスを開始し、各ステージの各ライフサイクル段階、入力、アクティビティ、および

    出力の概要を提供する。

    • 機能安全マニュアル: この文書はソフトウェアコンポーネントの概要を説明する。特性、構成、および、 ISO 26262(最大ASIL使用量を含む)の承認の系図。さらに、未解決の問題のリスト、ハザードまたは脆弱性のリスト、お

    よびそれらの問題と脆弱性の回避策を含むべきである。

    • コンプライアンス行列(安全マニュアルの一部とすることができる): この行列はソフトウェアコンポーネントが果たすParts 2、6および8の目的を示す。マトリックスは、各要求事項を、コンプライアンスの関連証拠と、各目的について

    のエクステント信用度とを要約する。完全なクレジットが取られない任意の目的に対して、インテグレータによる必

    要なアクティビティの要約が含まれるべきである。

    • 構成インデックスまたはバージョン記述文書: 関連する構築ツール、環境、および承認済みコンポーネントに関連するすべてのドキュメンテーションの構成を含む、ソフトウェアコンポーネント(ソースおよびバイナリ)の正確な構成

    に関する明白なレポートを提供する。ユーザの環境におけるソフトウェアコンポーネントのバイナリidenticalityをど

    のように保証するかという方法が提供されるべきである。

    • ユーザのガイドおよびマニュアル: 安全マニュアルの一部として提供されない場合、インストール、操作、およびソフトウェアの使用方法を記述したガイドおよびマニュアルが提供されるべきである。インタフェースの使用に関する

    制限事項と共に、インタフェースの記述が含まれる。

    • 検証結果: 検証結果は、要件、設計およびコード、試験事例および結果のレビューに関する情報を含む。また、ソフトウェアコンポーネントに対するテスト結果およびカバレッジ分析も含まれる。

    • テストベクトル: 供給者は、検査ベクトルのコピーを供給して、コンポーネント開発剤によって供給される結果と等価性を確立する手段として、それらの環境において試験ケースを反復できる。

    • ツール資格データおよび結果: ツール資格計画、ツール資格認定レベルおよび認定結果を示す文書は特に、インテグレータがそれらのツールをその環境に使用する必要がある場合に含まれるべきである。

    • 脆弱性分析またはハザード解析: この文献は安全性マニュアルに要約された危険および脆弱さに関する詳細を提供する。この情報は、インテグレータに各ハザードおよび軽減技術の根拠に追加洞察を与える。この情報は、シス

    テムおよびハードウェアレベルの両方での安全分析を構成する際に開発者に支援する。

    • トレーサビリティ情報: この情報は、各ライフサイクルデータ項目の変更管理を含む各アクティビティの要求、設計、コード、テストケースおよび結果間の直接リンクを、トレーサビリティと同様に直接に示す。

    • 分割分析(オプション): ソフトウェアコンポーネントがASIL分離(動作環境のように)のレベルをサポートする場合、パーティショニング解析が必要となる。分割解析は、ASILの低いレベルではどのアイソレーションがどのように構成さ

    れるべきであるかを、インテグレータがどのように保存するかを示す。分割解析はハードウェアまたはハードウェア

    ソフトウェアインターフェースに関する依存関係がある場合、おそらく、一定の仮定および制限を含むだろう

    • 統合ガイド: 安全マニュアルの一部として既に含まれていない場合、統合ガイドは安全マニュアル、コンプライアンス行列、バー

    ジョン記述文書、脆弱性分析およびテストベクトルに提供される情報の要約を提供します。理想的には、統合ガイド

    がコンポーネント供給者によって提供されるドキュメンテーションのセットを使用するISO26262へのインテグレータの

    ロードマップになります。

  • 道路車両の認定ソフトウェア部品を使用したISO 26262準拠

    rti.com 1

    まとめ

    自動車設計の動向には、ソフトウェアの使用の増加、ISO 26262への様々な安全性および規制の遵守の様々なレベル

    におけるソフトウェア構成要素の統合が含まれる。さらに、複雑な安全性の目標および要件をもたらす道路車両のより

    多くの自律的な特徴の傾向があります。自動車に市販ソフトを統合しようとするプロジェクトチームは、ソフトウェア・コン

    ポーネントを検証する必要がある。ハードウェア互換性だけでは、インテグレータはISO 26262の第6部(など)の規制遵

    守を示す必要があります。ソフトウェア・コンポーネント用に、これが、複雑である可能性があるのはすべての「正真正

    銘の」ソフトウェアコンポーネントが値および機能に、一致するわけではないからです。

    ISO 26262 accreditationを超えるCOTS成分の場合、積分器に負担を課す積分アクティビティが存在することが重要です。

    ISO 26262システムで使用されるソフトウェアコンポーネントは一部証拠、ガイダンス、ドキュメンテーションを有し、これに

    よって、積分器は、過度の負担やリスクを伴わずに証明書を再利用することができます。COTSコンポーネントを使用す

    るintegrator試行前、彼らは、どのようにコンポーネントが考慮事項がここで、向上したことを裏付けるかを決定するべき

    です。

    脆弱性分析、安全マニュアル、分配ガイダンス、ならびにユーザのSガイドおよびマニュアルの欠如は、よりやっかいな

    構成を有する、ISO 26262承認を行ないます。VerocelおよびRTIのような企業は他の産業において、自動車設計者が

    ISO 26262準拠の成功を可能にするために適切にそのサービスを整合させるために、それらの経験を使用しています。

    Verocelについて

    Verocel(www.verocel.com)は1999年に設立され、ソフトウェアおよび複合ハードウェアの安全な挙動を複数の産業において

    確実にするために専用になってきた。Verocelは、ソフトウェア証明慣行の金標準を規定するリーダーです。自分の経験に

    基づいて、VerocelはDO-254、-178B/DO-178C、国際規格IEC61508、国際規格IEC62304および国際標準化機構26262以

    上のような基準の厳しさで、私たちの仕事を効率的で完了させる複数の技術およびプロセス を発展させました。Verocelチ

    ームは、とりわけ、原子力炉、産業制御システム、飛行管理コンピュータ、航空機ディスプレイからのプロジェクトのスコアを

    経験しています。Verocelの固有技術はセーフティクリティカル使用のためのCOTSソフトウェアおよび機器を制限することに

    あり、オペレーティングシステム、通信プロトコル、システムオンチップマイクロプロセッサおよび論理装置のようなコンポー

    ネントに、これらの能力を応用しています。

    RTIについて

    Real-Time Innovations(RTI)は、産業用インターネット(IIoT)での接続性を提供しています。 RTI Connext®databusはリ

    アルタイムで情報を共有するソフトウェアフレームワークであり、アプリケーションを1つの統合システムとして連携させま

    す。 フィールド、フォグ、クラウド間を接続させることも可能です。 その信頼性、セキュリティ、性能、拡張性は、最も要求

    の厳しい産業システムで実証されています。 実績のあるシステムとしては、、医療機器やイメージング、 風力、水力およ

    び太陽光発電; 自律飛行機、電車および車; 交通制御; オイルとガス; ロボット工学、船舶、防衛などの産業分野がありま

    す。

    RTIは、OMG(Object Management Group)のデータディスティビューションサービス(DDS)規格に基づく製品の最大のベ

    ンダーです。 RTIは非上場企業で、カリフォルニア州サニーベールに本社があります。

    本書に記載する会社名、商品名は各社の商標または登録商標です。

    232 E. Java Drive、Sunnyvale, CA94089 電話: +1(408)990-7400 FAX: +1(408)990-7402 [email protected] www.rti.com

    (京都本社) 〒600-8482 京都市下京区堀川通綾小路下ル綾堀川町293-1 TEL 075-344-7961 (東京支社) 〒101-0024 東京都千代田区神田和泉町1番地(神田和泉町ビル) TEL 03-5825-2081 www.co-nss.co.jp

    mailto:[email protected]://www.rti.com/

    ISO 26262認証, Part6 : ソフトウェア要件Part6の要件を満たすためのCOTSアプローチRTI Connext® DDS Micro ISO 26262認定ソフトウェアコンポーネントISO 26262適合ソフトウェアコンポーネントの使用に関する考察まとめVerocelについてRTIについて