Dear all,

As stated during yesterday’s safety architecture WG I have some observations around the hybrid approach being proposed for ELISA.

Here are two observations:

• The terms “safety related” and non-safety related” are used differently in ISO 26262 and in the hybrid approach.
• ISO 26262 defines “safety related function” as “function that has the potential to contribute to the violation of or achievement of a safety goal”
• Hence, according to ISO 26262 the tell-tale rendering and its related functionality is “safety related”.
• In the hybrid approach the tell-tale rendering is designated as “non-safety related”, while the safety function is treated as “safety related”
• This difference has consequences on the safety argumentation down-stream.
  
  
• To my understanding safety analysis is conducted over the safety related functionality to understand what failure modes can contribute to the violation of or achievement of a safety goal
• The output of the safety analysis then serves as means to define the safety mechanisms (ISO26262) or safety function (IEC61508)
• In the hybrid approach safety analysis is performed on the safety function, but not on the tell-tale rendering and its related functionality (since this is designated as non-safety related, see first bullet).
• Again this difference has consequences on the complete safety argumentation.
• The IOCTL problem that is being discussed, for example, is not single-point fault related, as even in the event that the presented IOCTL scenario would occur it would not cause corruption or loss of a critical tell-tale.

Unless there is a simple explanation I’m not sure if I can manage lengthy email threads – maybe we can discuss this in the call next Tuesday.

Best regards

Chris

----------------------------------------

Hi,

The answer to the first point can be as follows. The whole tell-tale system is ASIL B. It can be decomposed into ASIL QM (tell-tale rendering) and ASIL B (safety function). Therefore, only  the safety function is considered SR for the purpose of the analysis.

Thanks,

Eli

Dear all,

As stated during yesterday’s safety architecture WG I have some observations around the hybrid approach being proposed for ELISA.

Here are two observations:

• The terms “safety related” and non-safety related” are used differently in ISO 26262 and in the hybrid approach.
• ISO 26262 defines “safety related function” as “function that has the potential to contribute to the violation of or achievement of a safety goal”
• Hence, according to ISO 26262 the tell-tale rendering and its related functionality is “safety related”.
• In the hybrid approach the tell-tale rendering is designated as “non-safety related”, while the safety function is treated as “safety related”
• This difference has consequences on the safety argumentation down-stream.
• To my understanding safety analysis is conducted over the safety related functionality to understand what failure modes can contribute to the violation of or achievement of a safety goal
• The output of the safety analysis then serves as means to define the safety mechanisms (ISO26262) or safety function (IEC61508)
• In the hybrid approach safety analysis is performed on the safety function, but not on the tell-tale rendering and its related functionality (since this is designated as non-safety related, see first bullet).
• Again this difference has consequences on the complete safety argumentation.
• The IOCTL problem that is being discussed, for example, is not single-point fault related, as even in the event that the presented IOCTL scenario would occur it would not cause corruption or loss of a critical tell-tale.

Unless there is a simple explanation I’m not sure if I can manage lengthy email threads – maybe we can discuss this in the call next Tuesday.

Best regards

Chris

----------------------------------------

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hi Eli,

I don’t see that this is a case of ASIL decomposition, but let’s put this aside.

So the explanation would be that the non-safety related function emerges through decomposition.

This leads to another observation:

• ISO 26262-9:5.4.4 states "Each decomposed safety requirement shall comply with the initial safety requirement by itself.” which implies that all functionality resulting from decomposition is safety related.
• In the hybrid approach
• ASIL decomposition delivers functionality that is safety related and functionality that is non-safety related, and
• the complete functionality that can deliver single point faults is designated as non-safety related.

Best regards

Chris

Hi,

The answer to the first point can be as follows. The whole tell-tale system is ASIL B. It can be decomposed into ASIL QM (tell-tale rendering) and ASIL B (safety function). Therefore, only  the safety function is considered SR for the purpose of the analysis.

Thanks,

Eli

Dear all,

As stated during yesterday’s safety architecture WG I have some observations around the hybrid approach being proposed for ELISA.

Here are two observations:

• The terms “safety related” and non-safety related” are used differently in ISO 26262 and in the hybrid approach.
• ISO 26262 defines “safety related function” as “function that has the potential to contribute to the violation of or achievement of a safety goal”
• Hence, according to ISO 26262 the tell-tale rendering and its related functionality is “safety related”.
• In the hybrid approach the tell-tale rendering is designated as “non-safety related”, while the safety function is treated as “safety related”
• This difference has consequences on the safety argumentation down-stream.
• To my understanding safety analysis is conducted over the safety related functionality to understand what failure modes can contribute to the violation of or achievement of a safety goal
• The output of the safety analysis then serves as means to define the safety mechanisms (ISO26262) or safety function (IEC61508)
• In the hybrid approach safety analysis is performed on the safety function, but not on the tell-tale rendering and its related functionality (since this is designated as non-safety related, see first bullet).
• Again this difference has consequences on the complete safety argumentation.
• The IOCTL problem that is being discussed, for example, is not single-point fault related, as even in the event that the presented IOCTL scenario would occur it would not cause corruption or loss of a critical tell-tale.

Unless there is a simple explanation I’m not sure if I can manage lengthy email threads – maybe we can discuss this in the call next Tuesday.

Best regards

Chris

----------------------------------------

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Hi Chris,

I remember that we have already discussed about the Telltale use case scenario and the assumptions:

https://docs.google.com/presentation/d/1Tiz5IT5tVi4QynXMYrChLZm8KLeH14Vz/

OK, by comparison with https://docs.google.com/presentation/d/1L1Q8jDltic4ZgKED_rHTz9_8TolAMjnq/

I think there is an error in the slide shown by Gab: all blocks in the picture should be safety related.

And I guess it is just an editorial error, otherwise why highlighting an NSR as QM?? 😊

Now, clarified (Gab?) that probably we are speaking about the same type of ASIL Decomposition already discussed in the other meetings, my doubts is about the conceptual correlation that you have identified between Gab/Daniel's “hybrid” approach and the assumptions.

According to my understanding, the assumptions are derived from Automotive Use case (i.e. from a Technical Safety Concept) and they are used “just” as input to derive the allocation of (safety) requirements on Linux. Then, this hybrid approach analyzes the Linux design against the requirements in order to provide a certain list of argumentations, including the FFI (or at least it seems to do that by looking the material shared during the workshop https://drive.google.com/drive/u/0/folders/1BoK0PC1yYWuVtT4AuK_VW1T2U2WwQZTF).

About the required analysis, I agree with you that something should be done at the level of the claims done.

Then, if we claim ASILx we need a dedicated analysis; If we claim a partitioning like NSR and SR, QM and ASIL or ASILx and ASILy etc. etc. we need to produce an FFI rationale.

Anyway, I have another doubt: why are you using “Single Point” Fault terminology here?

This term is intended to be used for HW random failure, but, according to my understanding, the intent of this work is to justify the usability of Kernel as classic SW design, then by using the natural systematic (architectural) point of view. What am I missing?

Thanks,

Hi Eli,

I don’t see that this is a case of ASIL decomposition, but let’s put this aside.

So the explanation would be that the non-safety related function emerges through decomposition.

This leads to another observation:

• ISO 26262-9:5.4.4 states "Each decomposed safety requirement shall comply with the initial safety requirement by itself.” which implies that all functionality resulting from decomposition is safety related.
• In the hybrid approach
• ASIL decomposition delivers functionality that is safety related and functionality that is non-safety related, and
• the complete functionality that can deliver single point faults is designated as non-safety related.

Best regards

Chris

Hi,

The answer to the first point can be as follows. The whole tell-tale system is ASIL B. It can be decomposed into ASIL QM (tell-tale rendering) and ASIL B (safety function). Therefore, only  the safety function is considered SR for the purpose of the analysis.

Thanks,

Eli

Dear all,

As stated during yesterday’s safety architecture WG I have some observations around the hybrid approach being proposed for ELISA.

Here are two observations:

• The terms “safety related” and non-safety related” are used differently in ISO 26262 and in the hybrid approach.
• ISO 26262 defines “safety related function” as “function that has the potential to contribute to the violation of or achievement of a safety goal”
• Hence, according to ISO 26262 the tell-tale rendering and its related functionality is “safety related”.
• In the hybrid approach the tell-tale rendering is designated as “non-safety related”, while the safety function is treated as “safety related”
• This difference has consequences on the safety argumentation down-stream.
• To my understanding safety analysis is conducted over the safety related functionality to understand what failure modes can contribute to the violation of or achievement of a safety goal
• The output of the safety analysis then serves as means to define the safety mechanisms (ISO26262) or safety function (IEC61508)
• In the hybrid approach safety analysis is performed on the safety function, but not on the tell-tale rendering and its related functionality (since this is designated as non-safety related, see first bullet).
• Again this difference has consequences on the complete safety argumentation.
• The IOCTL problem that is being discussed, for example, is not single-point fault related, as even in the event that the presented IOCTL scenario would occur it would not cause corruption or loss of a critical tell-tale.

Unless there is a simple explanation I’m not sure if I can manage lengthy email threads – maybe we can discuss this in the call next Tuesday.

Best regards

Chris

----------------------------------------

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hi Roberto,

Ok, if it’s an (editorial) error then we should wait with further discussions until the document is updated.

I understand that the update will lead to the functionality involved with rendering being denoted as safety related, which sounds sensible.

To understand the argument about decomposition, which safety requirement is decomposed?

Regarding your last comment – you are correct the term “single-point fault” is defined in ISO26262 in the context of HW only – thanks for spotting it.

The statement should read

“The IOCTL problem that is being discussed, for example, cannot lead directly to the loss of a critical tell-tale, irrespective of whether it performs correctly or not.”

Best regards

Chris

Hi Chris,

I remember that we have already discussed about the Telltale use case scenario and the assumptions:

https://docs.google.com/presentation/d/1Tiz5IT5tVi4QynXMYrChLZm8KLeH14Vz/

OK, by comparison with https://docs.google.com/presentation/d/1L1Q8jDltic4ZgKED_rHTz9_8TolAMjnq/

I think there is an error in the slide shown by Gab: all blocks in the picture should be safety related.

And I guess it is just an editorial error, otherwise why highlighting an NSR as QM?? 😊

Now, clarified (Gab?) that probably we are speaking about the same type of ASIL Decomposition already discussed in the other meetings, my doubts is about the conceptual correlation that you have identified between Gab/Daniel's “hybrid” approach and the assumptions.

According to my understanding, the assumptions are derived from Automotive Use case (i.e. from a Technical Safety Concept) and they are used “just” as input to derive the allocation of (safety) requirements on Linux. Then, this hybrid approach analyzes the Linux design against the requirements in order to provide a certain list of argumentations, including the FFI (or at least it seems to do that by looking the material shared during the workshop https://drive.google.com/drive/u/0/folders/1BoK0PC1yYWuVtT4AuK_VW1T2U2WwQZTF).

About the required analysis, I agree with you that something should be done at the level of the claims done.

Then, if we claim ASILx we need a dedicated analysis; If we claim a partitioning like NSR and SR, QM and ASIL or ASILx and ASILy etc. etc. we need to produce an FFI rationale.

Anyway, I have another doubt: why are you using “Single Point” Fault terminology here?

This term is intended to be used for HW random failure, but, according to my understanding, the intent of this work is to justify the usability of Kernel as classic SW design, then by using the natural systematic (architectural) point of view. What am I missing?

Thanks,

Hi Eli,

I don’t see that this is a case of ASIL decomposition, but let’s put this aside.

So the explanation would be that the non-safety related function emerges through decomposition.

This leads to another observation:

• ISO 26262-9:5.4.4 states "Each decomposed safety requirement shall comply with the initial safety requirement by itself.” which implies that all functionality resulting from decomposition is safety related.
• In the hybrid approach
• ASIL decomposition delivers functionality that is safety related and functionality that is non-safety related, and
• the complete functionality that can deliver single point faults is designated as non-safety related.

Best regards

Chris

Hi,

The answer to the first point can be as follows. The whole tell-tale system is ASIL B. It can be decomposed into ASIL QM (tell-tale rendering) and ASIL B (safety function). Therefore, only  the safety function is considered SR for the purpose of the analysis.

Thanks,

Eli

Dear all,

As stated during yesterday’s safety architecture WG I have some observations around the hybrid approach being proposed for ELISA.

Here are two observations:

• The terms “safety related” and non-safety related” are used differently in ISO 26262 and in the hybrid approach.
• ISO 26262 defines “safety related function” as “function that has the potential to contribute to the violation of or achievement of a safety goal”
• Hence, according to ISO 26262 the tell-tale rendering and its related functionality is “safety related”.
• In the hybrid approach the tell-tale rendering is designated as “non-safety related”, while the safety function is treated as “safety related”
• This difference has consequences on the safety argumentation down-stream.
• To my understanding safety analysis is conducted over the safety related functionality to understand what failure modes can contribute to the violation of or achievement of a safety goal
• The output of the safety analysis then serves as means to define the safety mechanisms (ISO26262) or safety function (IEC61508)
• In the hybrid approach safety analysis is performed on the safety function, but not on the tell-tale rendering and its related functionality (since this is designated as non-safety related, see first bullet).
• Again this difference has consequences on the complete safety argumentation.
• The IOCTL problem that is being discussed, for example, is not single-point fault related, as even in the event that the presented IOCTL scenario would occur it would not cause corruption or loss of a critical tell-tale.

Unless there is a simple explanation I’m not sure if I can manage lengthy email threads – maybe we can discuss this in the call next Tuesday.

Best regards

Chris

----------------------------------------

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale  04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.