画像
Shijia Guo
Shijia Guo
Staff Engineer – Functional Safety

先日掲載した機能安全に関するブログ記事1ではルネサスの機能安全サポートプログラムとCAR toolについてご紹介しました。本稿ではISO 26262の背景についても簡単にご紹介します。ISO 26262は量産される自動車2に組み込まれる電気/電子システムの機能安全に関する国際標準です。ISO 26262のPart 6では安全関連ソフトウェアの開発に関するガイダンスや要求事項が定義されています3。ルネサスでは、お客様がより素早く、より簡単に安全な車載向けECU、システム、および車両の開発を実現できるようなソフトウェア製品の提供を心掛けています。

本稿はルネサス機能安全シリーズのブログの第3回目です。以前のブログでもお伝えしている通り、ルネサスの機能安全製品の多くはSafety Element out of Context (SEooC)として開発されています。SEooCソフトウェアはルネサスの車載向けMCUとSoCをターゲットとしており、幅広いアプリケーションのために開発されています。本稿ではSEooCソフトウェアを開発する際のいくつかの重要な面や課題、およびルネサスが提供するSEooCソフトウェアのソリューションについてご紹介します。

ISO 26262において定義されているSEooCは “Safety Element out of Context” の略称であり、エレメントが特定のアイテムのコンテキストにおいて開発されていないことを意味します。SEooCは想定に基づいて開発されます。SEooCの統合においてその想定が妥当であれば、そのエレメントは様々なアイテムにおいて使用されます。本稿はソフトウェアに焦点を合わせていますが、SEooCはシステム単体、システムの組み合わせ、サブシステム、ソフトウェアコンポーネント、ハードウェアコンポーネント、パーツ3に適用することができます。幾つかの代表的なSEooCソフトウェアの例としては、Autosar MCAL (Microcontroller Abstraction Layer)、組み込みシステムOS (Operating System)、そしてミドルウェアソフトウェアが挙げられます。

ISO 26262はSEooCのソフトウェアコンポーネントの開発に関するガイダンスを3つのステップ4で提供しています。

  • Step 1.    SEooCのソフトウェアコンポーネントのスコープと安全要求の想定を決定する。
  • Step 2.    その想定に基づいて、かつ対象のASIL (Automotive Safety Integrity Level) に関するISO 26262-6の要求事項に従ってソフトウェアコンポーネントを開発する。様々なコンテキストにおける統合のために必要な全ての作業成果物を準備します。作業成果物の例を下記に示します。
    • DIA/DIR5 (Development Interface Agreement/Report: 開発インタフェース協定/レポート)
    • S-SRS (Software Safety Requirement Specification: ソフトウェア安全要求仕様)
    • SAN/SM (Safety Application Note/Safety Manual: セーフティアプリケーションノート、セーフティマニュアル) - 想定、安全機能の実装、その他の安全関連の情報が記載されます。
    • ソースコード
    • コンフィグレーションマニュアル - ユーザが正しくコンフィグレーションを理解し、適用することを支援します。
    • FSA (Functional Safety Assessment: 機能安全アセスメント) レポート など
  • Step 3.    特定のコンテキストにおいてソフトウェアコンポーネントを統合する。このステップにおいて、SEooCに基づいて決定された全ての想定の妥当性がそのコンテキスト基づいてチェックされます。もし幾つかの想定がその新しいコンテキストに適合しない場合は影響分析が行われます。
画像
Example of how the SEooC software development process is managed
(本図はSEooCソフトウェアの開発プロセスを管理する方法の例を示します。)

ステップ1における課題の1つは適切に想定をまとめることです。想定の観点は広く設定することが可能です。以下に代表的な想定の例を示します。

  • ユースケースの想定: 想定されるユースケースを記載します。
  • システムレベルの保護の想定:幾つかの安全機構はハードウェアIP (Intellectual Property)を保護するためにシステムレベルで実装されます。例えば通信メッセージに関するエンドツーエンドの保護が該当します。
  • 部分的に実装される安全機構要求の想定:もし幾つかの安全機構がSEooCソフトウェアによって完全に実装されない場合、安全機構を完全に実装することが統合を行う担当者に求められます。ルネサスはこれらの要求をSAN (Safety Application Note)内のAoU (Assumption of Use)として文書化し、統合担当者がこれらの要求を満たすことを想定している旨を示します。
  • 統合要求の想定:SEooCソフトウェアはアプリケーションに統合されます。統合されたソフトウェアが対象のASILを達成できるように、統合要求の定義、およびそれらの要求が統合担当者によって満たされることを想定している旨の表現が求められます。

ルネサスのソフトウェア技術者と安全技術者は長年の機能安全ソフトウェアの開発経験をもっています。対象のソフトウェアと想定システムに対する注意深い分析に基づいて想定が決定され、文書化されます。ルネサスの開発プロセスはこれらの想定に基づいた安全要求がレビューされ、アセスメントされることを確実にします。

画像
SEooC Software Assumption Categories

ステップ2における主要な課題はソフトウェアのコンフィギュアビリティに起因します。多くのSEooCソフトウェア製品は “out of context” の特性のためにコンフィグレーションが可能です。ソフトウェアは異なったコンテキストに合わせられるようにすることが求められます。そのため、コンフィグレーションを考慮しなければなりません。最終製品に実装されるコンフィグレーションは検証され妥当性が確認されなければなりません。コンフィグレーションのためのパラメータ数が増えると、可能なコンフィグレーションの数が指数関数的に増加します。SEooCソフトウェアのサプライヤは全てのコンフィグレーションが十分にテストでカバーされている確信をどのように得れば良いのでしょうか?
2つのライフサイクルの選択肢がISO 26262に記載されています。1つ目の選択肢は、コンフィグレーションされたソフトウェアを検証する “Simplified Lifecycle I” を適用することです。これは、リリース後のお客様による検証活動、または、サプライヤが販売後の検証サービスとして提供可能なお客様のコンフィグレーションに基づいた検証活動を伴います。お客様とプロジェクトの数が増えたとき、どのようにすればサプライヤは今まで通りに信頼を得てかつ効率的にサービスを提供できるのでしょうか? この課題に対しては以下のソリューションが大きな価値を提供すると考えています。

  • 自動テストシステム。ルネサスは自動テストシステムを構築しました。このシステムは大量のテストを短期間で実行可能です。これらのテストシステムはリリース前のソフトウェア検証や、お客様のコンフィグレーションを対象としたリリース後のソフトウェア検証で利用可能です。
  • 十分に定義された要求。ルネサスチームは要求を十分にかつ正確に定義することを心掛けています。ルネサスはガイドライン、テンプレート、部門間の責任などを定義した洗練されたプロセスを構築しています。モダンな要求エンジニアリングツールを使用することで要求を確実に獲得し、トレーサビリティを容易に維持しています。お客様のコンフィグレーションをテストする際は、十分に定義された要求に対してより良いテストカバレッジを達成可能です。

2つ目の選択肢は、許容されるコンフィグレーションデータの範囲でコンフィグレーション可能なソフトウェアを検証し、お客様のコンフィグレーションが検証されたコンフィグレーションデータの範囲に含まれていることを示す “Simplified Lifecycle II” を適用することです。検証の対象はできるだけ多くの有効なコンフィグレーションをカバーします。ルネサスは多くの state-of-the-art のテスト手法を取り入れています。これらの手法には N-wise Testing6、機能組み合わせテスト、ランダムテストなどが含まれます。これらの手法はテストするコンフィグレーションの組み合わせを最適化し、より少ない数のテストでより多くのコンフィグレーションをカバーするために使用されます。これらのテスト手法による支援を得ることで検証されたコンフィグレーション範囲にお客様のコンフィグレーションを含めることができます。この方法によって追加のコストと労力が必要となるより多くの検証を回避することができます。
 

画像
Simplified Lifecycle Options for Configurable Software Defined by ISO 26262

ステップ3において、SEooCソフトウェアが最終的にお客様に提供されるとき、お客様は想定の妥当性を確認し、自身のシステムに統合する課題に直面します。お客様が全ての想定の妥当性確認を行うためには時間を費やすかもしれません。また、全ての想定を理解し、確認するためには多くのソフトウェアの知識も求められるかもしれません。想定が有効でないときは、SEooCコンポーネントの変更、またはシステム安全要求の変更が求められるかもしれません。これはサプライヤ、またはお客様、もしくは両者に対して追加の労力とコストを強いるかもしれません。ルネサスはルネサスの機能安全ソフトウェア製品の使用に関する全ての想定をSAN (Safety Application Note)の中で開示しています。この文書はユーザが最小の労力で想定を理解し、検証することを支援するために、綿密に記載され、レビューされています。もし何か質問があれば、自動車向けの機能安全サポートプログラムの一貫としてソフトウェアサポートがお客様に提供されます。

画像
Renesas Safety Support Program for Automotive

SEooCソフトウェアを開発・提供することの難しさを認識しながら、ルネサスはこれらの課題を受け入れてきました。ルネサスは全ての関係するISO 26262の要求事項に適合したソフトウェア製品を提供することはもちろん、ユーザが自身のシステムにSEooCソフトウェアを統合する際に必要となるISO 26262の要求事項に適合するための情報を提供することも目標としています。ルネサスは製品開発に適合した3つの柱となる組織を確立しました。それは、開発チーム、品質保証チーム、そして社内の独立した技術アセスメントチームです。ルネサスの開発チームは機能安全ソフトウェア開発の長い歴史を持っています。品質保証チームはソフトウェア開発における機能安全プロセスのアセスメントと監査の役割を担っています。社内の独立した技術アセスメントチームは技術的な観点から機能的な安全を確実にするためにルネサス機能安全ソフトウェア製品に対する技術アセスメントを実施します。また、ルネサスはソフトウェアに対する機能安全アセスメントにおいて社外のアセッサとも協調します。これらの確立したチームと強固な安全文化によってルネサスは下記のようなASILソフトウェアを提供します。

  • 経験を積んだ開発チームによって十分に開発されている
  • I3レベルの品質保証チームと社内の独立した技術アセスメントチームによって十分にアセスメントされている
  • お客様が容易に安全システムに統合できる

まとめとして、本稿では最初にSEooCソフトウェア開発に関するISO 26262のガイドラインを紹介しました。次に3つの課題について説明しました。ルネサスは下記取り組みによって3つの課題に対するソリューションを提供しています。

  • 経験を積んだエンジニアと十分に定義されたプロセスによるソフトウェア製品の開発と想定
  • state-of-the-artのテスト手法の導入と自動化されたテストシステムの活用
  • SEooC統合プロセスを促進するお客様サポート

ルネサスはSEooC ASILソフトウェア製品を幅広く取り扱ってきました。RH850 MCUs (Microcontroller Units) については、ルネサスはMCALとCST (Core Self Test) ソフトウェアライブラリをASIL品質において提供しています。R-CAR SoC (System on Chips) については、ルネサスはCPUランタイムテスト、コンピュータビジョンソフトウェア、セキュリティソフトウェアなどのASIL品質のソフトウェアを提供しています。また、ルネサスはシステムソリューションを完成させるためにOSベンダーやコンパイラプロバイダのようなサードパーティーとも協業しています。もし、ルネサスのソフトウェアソリューションに何か興味を持っていただけるようであれば、ルネサスのセールス担当者にお問い合わせください。

画像
R-Car Software Platform and ASIL SW Packages

 

1: Renesas Automotive Functional Safety Page
2: ISO 26262-1:2018 Road vehicles — Functional safety Part 1 Vocabulary
3: ISO 26262-6:2018 Road vehicles — Functional safety Part 6 Product development at the software level
4: ISO 26262-10:2018 Road vehicles — Functional safety Part 10 Guidelines on ISO 26262 Clause 9 Safety Element out of Context
5: DIR (Design Interface Report) is a Renesas specific document equivalent to DIA (Design Interface Agreement)
6: N-wise testing http://www.tmap.net/wiki/n-wise-testing

See also:
Renesas Functional Safety Support for Automotive (1) – An overview
Renesas Functional Safety Support for Automotive (2) – A Customizable Option for Precise Safety Analysis

この記事をシェアする

コメントを投稿するにはログインまたは登録をしてください

この記事をシェアする