前回は規格の条文に基づいて、ISO 26262におけるASILデコンポジションの原則を説明しましたが、実際にどのように設計するかを説明します。

あるECUがあり、それに対するASILは最高ASILであるASIL-Dだとします。その理由は、このECUが走る、曲がる、止まるに関係しており、高速道路上で故障した場合に、人命に影響するためです。安全目標はそのように定められており「意図せず走行中にECUからアクチュエータへ特定機能のON信号を出力しないこと」となります。本機能はマイコンのソフトウェアで実装されています。

注意点として、ASILデコンポジションはシステマティック故障が対象なので、主にソフトウェア開発のASIL引き下げに有効です。従ってこのマイコンのASILを下げることを考えます。

マイコンはノイズ等で誤動作する可能性があることから、まず初期安全要求を冗長化します。マイコンへの初期安全要求は「意図せず走行中にマイコンから特定機能のON信号を出力しないこと」。ここで、「意図せず」というのは、「設計意図と異なり」という意味で、実際には「故障したとき」と読み替えると意味が通ります。「意図せず」という文言は省略されることがあります。

冗長化された安全要求はTSR1=「走行中にマイコンから特定機能のON信号を出力しないこと」、TSR2＝「走行中にマイコンから特定機能のON信号を出力しないこと」と同じ内容の安全要求となります。これをエレメント独立要求を満足するようにエレメント分割すると、メインマイコンとサブマイコン、ないしはメインマイコンとハード制御と分割できます。このRBD(Reliability Block Diagram)を書けば、言うまでもなく並列系となります。

ここではハード回路で制御する方法を考えると、走行中にマイコンからの特定機能のON信号のスイッチを切れば良いわけで、比較的簡単な回路で実装可能です。当然、メインマイコンとハード回路の間は独立性が必要であり、独立とは従属故障、すなわちカスケード故障と共通原因故障のいずれも無いことを意味します。

ここで、規格のPart9 5.4.7 a)にあるように、安全機構のASILを高くしてASIL-D(D)、マイコンをQM(D)とデコンポジションすることができます。マイコンのソフトウェアは従来開発を流用できるため、コストの高い機能安全開発から免れることができます。

前のブログ 次のブログ