|
27 |
ASILデコンポジション (2) |
前回は規格の条文に基づいて、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)とデコンポジションすることができます。マイコンのソフトウェアは従来開発を流用できるため、コストの高い機能安全開発から免れることができます。
前のブログ
4 comments to "ASILデコンポジション (2)"
Hi,
(I am from Taiwan, so please forgive me for asking a question in English.)
I have a question about the decomposition of ASIL X = QM(X) as intended functionality + X(X) as safety mechanism. When the original TSR as "意図せず走行中にECUからアクチュエータへ特定機能のON信号を出力しないこと" and then decomposed as two completely redundant requirements as TSR 1 = 走行中にマイコンから特定機能のON信号を出力しないこと QM(D) in MCU TSR 2 = 走行中にマイコンから特定機能のON信号を出力しないこと D(D) in ハード回路
For the QM(D) part, an QM(D) safety requirement of "no unintended ON signal shall be output during travel" is allocated to intended functionality MCU. What's the next to this safety requirement? Is is necessary to implement another safety mechanism in MCU to detect the potential failure?
Thanks.
最初に我々は安全要求を肯定形に変換する必要があります。 First, we need to convert the safety requirements into a positive form.
否定形の安全要求はエレメントの仕様とならないためです。 This is because negative safety requirements do not result in element specifications.
しかしながら、この場合、安全要求がデコンポジションにより特殊なので、HSRとSSRに分けて考えます。 However, in this case, safety requirements are special due to decomposition, so we will consider HSR and SSR separately.
安全要求のASILはMCUに対してQM(D)なので、安全要求のASILは、ランダムハードウェア故障についてはASIL-D、システマティック故障についてはQM(=安全要求無し)となります。 Since the ASIL of safety requirements is QM (D) for the MCU, the ASIL of safety requirements is ASIL-D for random hardware failures and QM (= no safety requirements) for systematic failures.
ゆえに、SSRが消えるので、MCUに対しては、ランダムハードウェア故障目標値のHSRしか残りません。 Therefore, since the SSR disappears, only the HSR of the random hardware failure target remains for the MCU.
あなたは回路を追加する必要はないかもしれませんが、アーキテクチャメトリクス及びPMHFの目標値をHSRとします。 You may not need to add any circuits, but let the target values of the architecture metrics and PMHF be HSR.
ISO 26262-9:2018, 5.4.5を参照してください。 See ISO 26262-9:2018, 5.4.5.
Dear Sakurai-san,
Thanks for your reply. I would like to ask two more questions to make myself more clear about this topic.
Combining clause 5.4.7 b) "a safety requirement shall be allocated to the intended functionality and implemented applying the corresponding decomposed ASIL" with your reply "since the ASIL of safety requirements is QM (D) for the MCU, the ASIL of safety requirements is ASIL-D for random hardware failures and QM (= no safety requirements) for systematic failures", I think a random hardware failure safety requirement should be allocated to the decomposed QM(X) IF part.
If I take the requirement deomposition I found in AUTOSAR document page 21 as example.
Original requirement:
decomposed into:
ECU06-09 are IF part of QM(B) requirements, and ECU10 is SM part of B(B). A recommended random hardware failures safety requirement, limiting the total number of PMHF and the metrics of SPFM and LFM, could be be allocated to the IF part to comply with clause 5.4.7 b). (I say "recommended" here because the parentheses is given for ASIL B in relevant metrics requirements in ISO 26262 part 5).
About the correct reading, configuration, transformation, and routing safety requirements specified in ECU06-09 allocated to IF part, they only need to be ensured by "complying the subsequent integration activities with original ASIL B" as specified in clause 9-5.4.12.
[Question 1] There is NO NEED to implement a redundant safety mechanism in IF part to detect the failures in IF part, am I right?
Additionally, in the domposed architecture we discussed as B = QM(B) IF + B(B) SM, only SM part can detect fault and switch to safety state. However, for the case of B = A(B) + A(B), both redundant element will come with an associated safety mechanism in it to detect the faults in the element, therefore, they the system is able to switch to safe state if a failure is detected in either of the decomposed A(B) element.
[Question 2] In the B=QM(B) + B(B) case, there will be no redundancy of detect failure and then switching system to safety sate in both decomposed elemets, is this acceptable for ISO 26262 functional safety?
Thanks.
Thank you for your question.
Though this is a very interesting question, analyzing external documentation arise a consulting fee. As I would like to reply within the scope of my blog without reading the Autosar documentation, I am afraid I might miss the point.
ISO 26262 never mandate the implementation of a redundant architecture. The standard only states that safety mechanisms, which can be another IF (whole redundancy) or monitor, need to be implemented, if necessary.
Leave a Comment