19 |
ASIL分解 |
同じ技術者の解説動画です。こちらには基本的に誤りはありません。2分間の動画で重要な事を3項目押さえているのでご紹介します。
英語のトランスクリプトを入手したので、画面と合わせて見てみましょう。以下はDeepLによるその翻訳です。
今回は、分解についてよく見られる誤解について少しお話ししたい。まず第一に、ISO26262で分解について話す場合、安全要件の分解について話している。ハードウェアを分解するわけでもなく、ソフトウェアを分解するわけでもなく、安全目標そのものを分解するわけでもない。分解するのは、ハードウェア安全要求事項、ソフトウェア安全要求事項、技術安全要求事項、FSRである。安全要件を分解することで、ハードウェアの独立した並列パスやソフトウェアの独立した並列パスが生まれる。これがよく見られる誤解のひとつだ。
ややはっきりしないところがありますが、好意的に解釈すれば最初に2つの重要な事項を述べています。
- ASIL分解は本当はASILを分解するのではなく、安全要求を分解し、その結果としてASILが分解「される」
- ASIL分解の原則である冗長性と独立性
引用の最後の部分、
安全要件を分解することで、ハードウェアの独立した並列パスやソフトウェアの独立した並列パスが生まれる。これがよく見られる誤解のひとつだ。
これがどう誤解なのかははっきりしません。ただ、ASIL分解の原則はさらっと述べていますが、以下の2つが重要です。これは規格の必須要求事項です。
- 冗長な安全要求に分解(動画では並列と表現)
- 安全要求が割り当てられたエレメントの独立性(動画では独立と表現)
次に、
もうひとつは命名法についてだ。命名法の重要な側面のひとつは、例えばASIL Dの安全要件まで構築する場合、ASIL Bのハードウエアを2つ使用するのであれば、それらのハードウエアにはASIL B of Dという命名法を使用しなければならないということだ。
いわゆるASIL-B(D)のような記法については、命名法が大事というよりは以下が重要です。これが3項目めです。
ハードウェアメトリクスの目標値は、分解したからといって変わるものではない。多くの人はこのことを理解していない。
Leave a Comment