Article #287

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.
posted by sakurai on August 7, 2020 #287

ASILデコンポジションについての言及

ASILデコンポジションでひっかかるネット上の文章で以下のようなものがありました。

ユーザーの安全確保を第一に考えれば、まずやるべきことはシステムを安全に関わる大事な部分とそうでない部分に分けて印を付けることだ。それが ASIL であり、コンポーネントも分解すれば危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ。

ASILデコンポジションの記事をご覧頂ければわかるように、これはほとんど誤りです。ほとんどと言うのは、条件を追加すれば正しくもなる、曖昧な表記であるためです。以下に誤りと正しい場合の2通りを検討してみます。

まず第1にASILデコンポジションの記事でも説明しているように、最初に考えるべきことは安全要求です。その目で見ると、この文章では安全要求への言及が抜けていますが、それを補ったとして素直に読むと、

コンポーネントも分解すれば危ない部分(=安全要求の厳しい部分)とそれほどでもない部分(=安全要求の緩い部分)にわけることができる

と読めます。それぞれの安全目標毎にHA&RA(ハザード分析とリスク評価)を実施し、初めてASILが決定されるわけですが、安全目標毎に安全要求及びASILも変わります。それを安全要求の厳しい部分と緩い部分に分けるのは、安全要求のエレメントへの割り当て(=安全コンセプト)であり、通常の設計ですから、ASILデコンポジションとは何の関係もありません。

素直に読むと以上のように誤りですが、なんとか正しくなるように補って読んでみます。すると、

(ひとつの厳しい安全要求を、冗長な要求に分解し、それを互いに独立したエレメントに割り当る。すると)コンポーネントも分解すれば、危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ

となり、かろうじて意味が通じることになりますが、重要な2点の条件を落としているので、ASILデコンポジションの説明になっていません。さらにその後を読んでいくと、

システムの中の大事な部分、安全を担っている部分をできるだけを機能ごとに凝集し、他のコンポーネントとの結合を疎にして、その大事なコンポーネントに関わる設計や検証に工数や費用を投入するのがよい。そのためにはシステム全体の安全に対する分析を最初に進める必要がある。

とあります。上記で重要な2点の条件を説明していないことを考慮すると、ASILデコンポジション共存の基準を混同しているようです。似たような概念なので混同するのもやむをえませんが、この2つをしっかり区別して理解することが必要です。


左矢前のブログ 次のブログ右矢

Leave a Comment

Your email address will not be published.

You may use Markdown syntax.

Please enter the letters as they are shown in the image above.
Letters are not case-sensitive.