Technical Article 機能安全とAUTOSARソフトウェア ∼安全関連性レベルが異なるソフトウェアコンポーネントのECUへの統合∼ 新たに制定された自動車用規格のISO 26262では、安全に関連したECUソフトウェアの開発プロセスが定義されていま す。個々のソフトウェアコンポーネントには、最終的に得られるシステム固有の安全目標がこの規格を満たすよう、高い レベルの機能安全を達成することが求められます。これはエラー時に危険な状況が生じるのを防ぐためにも必要です。 新機能における機能安全対応は、安全関連ECUの開発において 第一に力が注がれる部分ですが、そのほかにもう1つ、これまで引 き継がれてきた旧来の「実証された」機能を、診断やブートローダー などの「サービス機能」やクリティカルなコアコンポーネントと一体 ネント間の密接な相互作用を考えると、それを実行に移すのが不可 能な場合も少なくありません。 この規格の要件を無駄なく効率的に実装するのに理想的なのが、 モジュラー構造のソフトウェアプラットフォームです。そのプラット 化し、ISO 26262のすべての機能安全要件を満たすという課題があ フォームにおいては、製造元が異なり、Safety ClassificationがQM ります。それには、この規格に従って、新旧の機能が持つ潜在的な からASIL Dまで多岐にわたる各種のソフトウェア機能を、1つのECU リスクを評価し、実装することが不可欠です。車両の各機能の潜在 に統合できることが求められます。以下では、そのような実装につ 的なリスクはASIL（Automotive Safety Integrity Level）で分類さ いて説明します。このプラットフォームによって、実証済みの非安全 れ、QM（「品質管理」、安全性との関連なし）からASIL D（安全性と 関連ソフトウェアをそのままの形で再利用できる一方、最高レベル の関連性が最大）に至る幅広い分類レベルが割り当てられます。こ の安全要件もクリアすることができます。 の規格では、安全性との関連レベルが異なる機能を統合する際に “Freedom from Interference”の保証が求められます [1]。従 は、 来から使用されている部品やQMプロセスに基づいて開発されたソ フトウェアが、安全関連機能に干渉することは許されません。その ため、ASIL分類が異なる機能を組み合わせると、実証済みの機能 製造元もASIL分類も異なるソフトウェア機能を、 1つのECUに統合 ISO 26262では、クリティカルなシステム部品を混在させる際は、 に手を加える必要が生じ、開発コストが肥大する可能性があります。 安全関連ソフトウェアに影響を与えたり、それらを妨害したりしては 開発サイクルの時間枠が限られている点や、数多くのサブコンポー ならないという要件が中核に据えられています。 “Freedom from April 2012 1 Technical Article という概念は、以下に示す3つの要件で構成されてい Interference” に用いられる、個別のSafety Moduleの機能について説明します。 ます。 ドイツの品質評価の専門機関であるTÜVは、このソリューションの > 安全関連機能のメモリーに対して、意図しない変更が加えられ ISO 26262準拠を事前認定しています。 ないこと。たとえば、 「不正なポインターアクセス」によってメモ リーが破壊されたりしないこと。 メモリー違反に対する防御策 > 安全関連機能には、常に、あらかじめ指定された実行時間を与 えることができること。つまり、不正な割り込みが発生したり、 機能の開始が遅れたりすることがないこと。 > 安全関連機能が送受信するデータに、他の影響が及ばないこと。 すなわち、遅れ、ブロック、改ざんなどが生じないこと。 安全関連ソフトウェアコンポーネントのメモリー領域への不正 アクセスは、メモリー保護のメカニズムに対応したオペレーティン グシステム、すなわちScalability Class 3または4（AUTOSAR OS SC3/SC4）のMICROSARオペレーティングシステムを使用すること で防御できます。ここではメモリー保護ユニット （MPU：Memory 以下では、安全関連と非安全関連のソフトウェアモジュール、た Protection Unit）がメモリー保護のメカニズムを実装しますので、 とえば安全関連のインバーター監視ユニットと非安全関連の診断モ このソリューションにおいては、適切なマイクロプロセッサーの ジュールなどを、1つのECU上に共存させる方策について説明しま 使用が前提となります。MICROSAR OSのソフトウェア部分である す。この方策における1つ1つのアクションによって、前述の3つの要 SafeContextは、タスクの切り替えと割り込みの際のソフトウェアコ 件が確実に満たされます。 ンポーネントの分離を担当し、あるソフトウェアコンポーネントが他 なお、この規格において、安全関連ソフトウェアに悪影響や干 のソフトウェアコンポーネントのメモリーに無許可で書き込みを行う 渉が生じない限りは、 “Freedom from Interference”を保証する のを防ぎます。SafeContextはASIL Dとして開発されているため、 ために既存ソフトウェア （AUTOSARベーシックソフトウェアなど） 保護対象となる各種のタスクや割り込みが使用するメモリー範囲に を改めて開発することは求められていません。ただし、Safety 合わせて、実行時に実際の保護動作を行うMPUの再設定を行うこと Classification ASIL Dに至るまでの全ソフトウェアコンポーネント間 が許可されています。このことにより、MPUの設定内容や、コンテ で干渉を常に回避することが、システム全体の安全上必要です。こ キストデータの保存と復元においてもASIL Dが達成されます。 れは図1に示すように、メモリーアクセス、プログラムフロー、コミュ このオペレーティングシステムでは、AUTOSARで規定されている ニケーション用に独立したSafety Moduleを投入し、新たな防御策 OSアプリケーションの概念を使って設定が行われます。ここではオ をソフトウェアコンポーネントに加えることで実現できます。以下で ペレーティングシステムのオブジェクトがタスクや割り込みなどに論 は、ISO 26262の要件に従って、既存のベーシックソフトウェアコン 理的に分類されて、MPU設定に割り当てられます。QMプロセスで ポーネントを再利用しながら、システム全体でASIL Dを達成するの 開発されたベーシックソフトウェアモジュールは、異なるOSアプリ 図1： MICROSAR Safe April 2012 2 Technical Article ケーションに組み込まれ、ASILソフトウェアから切り離されます。こ はデータはチェックサムで保護され、内容の破壊の検出が可能とな うすることで、ベーシックソフトウェアがASILソフトウェアのメモリー ります。また、メッセージカウンターによってメッセージのシーケン を上書きすることを防ぐこともできます。 スの誤り、メッセージの欠落、意図しない反復が検出されます。 ランタイムの干渉に対する防御策 まとめ Safe Watchdog Manager（SWdgM：セーフウォッチドッグマネー ジャー）は安全確保のメカニズムで、タイミングとプログラムフロー 。安全関連機能に対しては、それらがフ の監視を担当します （図2） ロー内で正しい順序で実行されているかの監視が行われます。関 連する全ソフトウェアコンポーネントのチェックポイントが、プログ ここで説明した3つのSafety Moduleは、いずれも相互に機能を 補い、一体となって “Freedom from Interference”を実現します。 ISO 26262で最も高いレベルの要件を満たし、ASIL DのECUでも利 用が可能です。これらを、ベクターのAUTOSARソリューションであ るMICROSARに統合するということは、1つの供給元から、機能安全 ラムフロー上のSWdgMに定期的に通知を送ります。これによって、 の要求を満たしたベーシックソフトウェアを入手できるということで 実行時のあらゆるタイプの干渉を確実に検出できます。あるアプリ もあります。 ケーションで割り込みや機能が正しいタイミングで起動されなかっ 多様なレベルの安全関連ソフトウェアを使用しつつソフトウェアコ た場合、SWdgMがそれを検出してエラー対応を開始します。プログ ンポーネント内の干渉を回避できるため、対応するASILレベルの引 ラムでは時間の長さだけでなく、フローのシーケンスが正しいかも き上げに要するソフトウェア開発の作業を回避することができ、そ 監視されます。SWdgMは、マイコンとは独立したハードウェアウォッ れが大幅なコスト削減につながります。ISO 26262のASIL Dに準拠 チドッグに通知を行い、エラー発生時には、最後の手段として、安 し、事前認証も行われているSafety Moduleを統合･リンクすれば、 全な状態となるようにECUをリセットさせることができます。なお、 全体として、求められる最高のASILに対応したソフトウェアプラット SWdgMそのものが正しく起動しなかった場合には、この独立した フォームを構築することができます。Safety Moduleは、QMの要求 ハードウェアウォッチドッグに通知が行われなくなるため、これによっ に従って開発されたソフトウェアアプリケーションやAUTOSARベー てもエラー対応が確実に行われます。 シックソフトウェアのコンポーネントと統合可能です。 “Freedom from Interference”を保証するASIL DのSafety Moduleを統合する 入出力データの破損に対する防御策 ことで、安全要求が異なるソフトウェアモジュールの共存が可能に なり、安全関連モジュールの開発で相当なコスト削減が可能になる End-To-End Library（E2ELib：エンドツーエンドライブラリー）は、 ほか、開発サイクルも短縮されます。 。ここで 送信方向と受信方向で安全関連の通信を保護します （図3） 図2： MICROSAR Safe Watchdog Manager April 2012 3 Technical Article 図3： SafeCOM Architecture 資料： 執筆者： Matthias Krause (Dr. rer. nat.) ベクターで組込ソフトウェアのプロダクト マネージメントに従事し、セキュリティー 関連のAUTOSARベーシックソフトウェア のコンセプトと実装を担当しています。 [1] ISO/DIS 26262: Road vehicles – Functional safety, Part 1-10. International Organization for Standardization, 2009. http://www.iso.org/ 提供元： 見出し画像/図1 ∼ 3： TTTech AutomotiveおよびVector Informatik GmbH リンク： ベクター・ジャパン http://www.vector-japan.co.jp Carsten Weich (Dipl. Ing. Dr.) TTTechの車両ソフトウェア開発の責任者 であり、また、Audiのシリーズ生産のた めの開発プロジェクトを指揮するととも に、IEC 61508およびISO 26262に準拠 したセキュリティー関連プロジェクトを担 当しました。 April 2012 ■ 本件に関するお問い合わせ先 ベクター・ジャパン株式会社 営業部 （東京） TEL：03-5769-6980 FAX：03-5769-6975 （名古屋）TEL：052-238-5020 FAX：052-238-5077 E-Mail：sales@jp.vector.com 4
© Copyright 2024 Paperzz
