Comments
Description
Transcript
プレスアーティクル
Technical Article E/Eシステム開発におけるモデルベースの機能安全 車載用電気/電子システムの機能安全に関する国際標準、ISO 26262の導入により、この分野に対する自動車業界の 意識が大きく高まっています。そのため、この標準の要求を満たす一方で、安全関連機能の複雑化にも適切に対処で きる現実解を多くの自動車メーカーやサプライヤーが求めています。セーフティークリティカルシステムの開発には、 従来のシステムよりも多くの労力が必要です。制約条件は変わらないものの、スケジュール、リソース、コストなどに 関連した作業の追加は避けられません。既存の開発、分析、テスト方法とそれらの関連ツールは概して断片的であり、 1つのプロセスに統合するには相当の手間が掛かります。 したがって、E/Eシステム開発の一環として機能安全を実現する には新しいアプローチが必要であり、システム設計のすべてのレ 装されているかを、レビュー、分析、テストの適切な組み合わせに よって確認する必要があるのです。 ベル （図1）を念頭に置いたうえ、標準に沿って検証できる形でシス テムの安全目標を実装することが大切です。 システム安全目標の達成は多様な因子によって左右されます。 ソフトウェア機能のプログラム上の欠陥や、重要コンポーネントで システムアーキテクチャーの包括的な把握 のランダムハードウェア故障などがその例です。ISO 26262でも推 奨されていますが、こういった単独の障害は現在の開発方法でも 現行の自動車/非自動車業界向けの安全標準（プロセス産業分 比較的簡単に回避したり、少なくともそれらを検出して対処するこ 野IEC 61511、原子力分野IEC61513、鉄道分野EN 50128）ではい とができます。しかし、異なるアーキテクチャー階層の多様なシス ずれも、開発するシステムのコンセプトがシステム安全目標を満た テム因子が混在して安全目標に関与するようなケースでは、事態 すかの検証が主要要求として挙げられています。安全目標は一般 は容易ではありません。複雑なシステムでは、このような相互依存 に、機能システムレベルでのハザードおよびリスク分析から割り出 性は従来型のドキュメントベースの設計方法ではほとんど解明で され、そこから得られる機能安全要求、技術安全要求が、システム きず、たとえば次の2つのような設計上のミスは珍しくありません。 のコンポーネントに割り振られます。これらの安全要求が正しく実 April 2012 1 Technical Article ないか」などの問題を定式化し、半自動的な分析によりその答えを 求めることもできます。 モデルベースの安全分析 ISO 26262では、システム、ソフトウェア、ハードウェアのレベル で安全分析を実施することが求められており、それによって設計 上の問題を検出し、改善策が取れるようになっています。そういっ た分析方法の1つがFMEA（Failure Modes and Effects Analysis/ 故障モード影響解析）です。これは個別のコンポーネントの潜在的 な故障を特定し、それがシステム目標に及ぼす影響と、故障が発 生する確率を分析するのに用いられます。このタイプの分析は、 安全目標の観点から特に重要なコンポーネントを割り出すのに非 常に適してはいるものの、その結果は分析の基になるシステム設 計モデルの品質とスコープに大きく依存します。システムの依存 関係を記述したドキュメントに不備があれば、結果は技術者個人の 経験や知識に左右されることが多くなり、それが上述のような問題 図1：モデルベースのシステム設計 システムアーキテクチャーのすべての要素とそれらの依存 関係を包括的に把握 に発展することも少なくありません。 システムの包括的なモデル化は、安全分析の実施にとって最上 の前提条件の1つです。分析時には安全の専門家がモデルの情報 に直接アクセスします。依存関係、特にアーキテクチャーレベル間 の依存関係は自動的に分析され、システム安全に与える影響が評 > ソフトウェア開発の際、2つの機能を結ぶ通信媒体の整合性に ついての前提に誤りがあり、通信障害への対策が不足しました。 価されます。分析の結果必要とされる対策はモデルに直接実装さ れ、関連する分析にリンクされます。このようにして設計、分析、 この場合、たとえば後からソフトウェア機能を別のバスセグメン そしてそれらに影響される安全目標の間のトレーサビリティーが確 ト上にある別のECUに再配布すると、元の前提が誤っているこ 保されます。要求される安全検証を行い、システムの変更に伴う とから、システム整合性に違反する恐れがあります。しかも、ソ 影響分析を実行するには、これは絶対に欠かせません。システム フトウェア開発者はそれに気づきません。 設計、安全分析、安全コンセプト設計の密接な連携によって、モデ > あるハードウェアコンポーネントで故障率が異常に上昇しまし ルの変更の速やかな分析とその効果の評価が可能になり、設計と た。車両内の設置場所が温度、機械的振動、電磁妨害といった 安全分析とを切り離して行う場合は避けることのできない、時間の 厳しい環境条件に曝露されていることが原因でしたが、故障率 かかる再設計が不要になります。さらに、複数のシステムの実装バ の上昇は安全コンセプトで考慮されていませんでした。 リアントを比較および評価できるため、システム開発の初期フェー ズで、安全/技術的な視点を取り入れたシステム最適化の実施が 設計フェーズでこのような複雑な相互関係を充分考慮するに 可能になります （図2）。 は、システムをモデル化するための包括的なアプローチが必要で す。このようなアプローチでは、1つのデータモデルにすべての機 プロダクトラインのアプローチで効率を向上 能要求と非機能要求を組み込むだけでなく、論理的なシステム設 計、ネットワークアーキテクチャー、ソフトウェアおよびハードウェ システム的な観点でいえば、個人の嗜好に合わせた車のさまざ アアーキテクチャーも合わせて管理すべきです。同様に、ワイヤー まなオプションの提供、すなわち多様なバリアントやコンフィギュ ハーネスと、車内でのコンポーネントおよびワイヤーハーネスの レーションの提供は、管理を極めて難しくします。そして、安全技 配置のトポロジーも考慮しなければなりません （図1）。また、異な 術者は、要求される安全検証を個々のシステムのバリアントに実 るアーキテクチャー階層間での相互依存関係に加え、モデル化さ 行するという難題に向き合わねばなりません。この問題への対応 れるアイテムのドメイン固有属性（バス遅延時間、ハードウェア故 策の1つが「プロダクトライン」で、これは共通部分と可変部分に注 障率、設置場所の温度範囲など）も記述できることが大切です。こ 目しつつ、バリアントベースのシステム （プロダクトライン／製品系 れが可能であれば、たとえば「安全コンセプトに関連する信号を伝 列）を分析（ドメイン分析）するアプローチです。特定された共通部 送するケーブルが、衝突時に損傷する恐れのあるエリアを通過し 分は、複数の製品（車種）でそれらを再利用するための基盤となり April 2012 2 Technical Article 図2：機能安全開発におけるラウンドトリップエンジニアリング 安全分析、安全コンセプトのモデル化、安全設計を1つのモデ ルで実行。これにより変更の依存関係とその影響を即座に把握 し、以後の分析にそれらを組み入れることが可能 ます。さらに、この作業が必要になるのは要求分析、実装、テスト 図3：再利用 安全アーキテクチャーの共通要素を異なる車種に再利用 まとめ などを作成する際の1回のみです。 システム開発者は、モデルベースの方法と包括的なアプローチ セーフティークリティカルシステムの開発において再利用を現 （システムズエンジニアリング）を通じて、複雑なシステムの理解 実的に可能とするには、プロダクトラインのアプローチをハザード/ と活用のための手段を得て、そこから安全なシステムを構築する リスク分析や安全コンセプトにまで拡張しなければなりません。こ ことができます。また、モデルベースのアプローチによって効率が れらの分析とコンセプトは、共通のフィーチャー群に関連付けられ 向上するため、その分の労力を安全関連のアクティビティー（分 ていれば再利用が可能です。特定車種の開発プロジェクトにおけ 析、分析の結果必要とされる対策の実装、安全検証）に投入するこ る技術安全要求は、機能安全コンセプトから生成されます。たとえ とができます。安全アーキテクチャーのすべての部分を再利用す ば、車種はそれぞれ特定の動作状態やシステムアーキテクチャー れば、作業を繰り返さなくても済むため、一層の効率向上が可能 などによって特徴付けられます （図3）。技術安全要求にドメイン分 になります。 析を適用すれば、それらの要求の一部を再利用できます。 これが成功するかは、いずれもここで述べたパラダイムシフト、 ドメイン分析をシステムのコンポーネント （ソフトウェアコンポー すなわちドキュメントベースからモデルベースへの変革を日常業 ネント、ハードウェアコンポーネント）にまで拡張すれば、再利用の 務で実現してくれる、実績あるツールの支援が得られるかに掛かっ 付加価値が非常に大きくなります。安全ケースの一部を再利用す ています。ツールへの重要な要求の1つは、関連する意味データ ることで、安全検証がサポートされます。また特定の車両環境に モデルを使って複雑なシステムを適切に記述できることですが、 関する前提を要求として定式化することで、その実装や妥当性に 自動車ドメインに特化したグラフィカルな表記法および分析のサ ついて、特定のコンテキストで分析できます。 ポートと、安全検証の実行も不可欠です。大規模なチームでコラ ボレーションを行う場合は、他の要求も発生します。それは、プロ モデルベースのアプローチは、バリアント固有の分析と整合性 ジェクトの全参加者とのデータ交換とデータの一元管理を目的と チェックを行うための前提条件です。このアプローチにより、たと する、コラボレーション用プラットフォームの供給です。プロジェク えば安全検証でリストアップされているすべての対策と、安全コ ト参加者の能力と責任の違いに対処するため、役割と権限のモデ ンセプトの再利用から得られる技術安全要求が、特定の車種で実 ル化も必要です。また経時的なトレーサビリティー（バージョン履 現されることが保証できます。もし安全コンセプトにある冗長エレ 歴） には、統合済みのバージョンと構成管理が必要です。 メントが欠落するなどした場合、それがバリアント固有の整合性 チェックで未充足の要求として検出されます。 ベクター・インフォマティック社（Vector Informatik GmbH） は、発売から5年を迎えたPREEvision製品を通じて、モデルベー April 2012 3 Technical Article スのシステム設計のための実績あるツールを提供しています。 PREEvisionはテスト（テストデータ管理）、プロジェクト管理（製品 およびリリース管理） 、変更管理などの分野もサポートします。そ の最新バージョンは、ISO 26262に対応したアプローチで、機能安 全コンセプトのモデル化、分析、テストをサポートします。 提供元： 執筆者： Dr. Simon Burton イギリスのYork大学でコンピューターサ イエンスを学び、セーフティークリティ カルシステムの 仕 様とテストに関する 博士号を取得。システムズエンジニアリ ングとモデルベース手法を組込のセー フティークリティカルシステムの開発に 導入することを中心にキャリアを積み、 2006年にベクターグループに入社。 自動車ソリューションの安全コンサルティ ング、製品管理、ビジネス管理に従事。 見出し画像/図1 ∼ 3：Vector Informatik GmbH リンク： ベクター・ジャパン http://www.vector-japan.co.jp PREEvision http://www.vector.com/vj_preevision_jp.html Albert Habermann ミュンヘンのLudwig-Maximilians大 学 で物理を学び、モデルベース手法をソフ トウェア開発とテストに導入することを 中心にキャリアを積み、2006年にシュツッ ト ガ ルト のVector Informatik GmbHに 入社。現在はアーキテクチャーおよびシ ステム設計ツールであるPREEvisionの カスタマーサービス分野でプロジェクト マネージャーとして勤務。 April 2012 ■ 本件に関するお問い合わせ先 ベクター・ジャパン株式会社 営業部 （東京） TEL：03-5769-6980 FAX：03-5769-6975 （名古屋）TEL：052-238-5020 FAX：052-238-5077 E-Mail：[email protected] 4