Date   

Event: ELISA Safety-Architecture Weekly Meeting - 08/03/2021 #cal-reminder

safety-architecture@lists.elisa.tech Calendar <noreply@...>
 

Reminder: ELISA Safety-Architecture Weekly Meeting

When:
08/03/2021
12:00pm to 1:00pm
(UTC+00:00) UTC

Where:
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Organizer: myu@... myu@...

View Event

Description:
──────────

ELISA Project is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Meeting ID: 957 7511 4472
Passcode: 289297
One tap mobile
+16465588656,,95775114472#,,,,,,0#,,289297# US (New York)
+13017158592,,95775114472#,,,,,,0#,,289297# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
855 703 8985 Canada Toll-free
Meeting ID: 957 7511 4472
Passcode: 289297
Find your local number: https://zoom.us/u/aQIrrAQlD


ww31 Agenda

Gabriele Paoloni
 

Hi All

Tomorrow we'll continue the FFI analysis in the context of the telltale use case.

Thanks
Gab


ww30 Agenda

Gabriele Paoloni
 

Hi All

Tomorrow we'll continue the Telltale FFI discussion with a special focus on the communication interference between SR and NSR code in the Kernel (presented by Eli Gurvitz using the Mobileye approach).

Thanks
Gab



Event: ELISA Safety-Architecture Weekly Meeting - 07/27/2021 #cal-reminder

safety-architecture@lists.elisa.tech Calendar <noreply@...>
 

Reminder: ELISA Safety-Architecture Weekly Meeting

When:
07/27/2021
12:00pm to 1:00pm
(UTC+00:00) UTC

Where:
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Organizer: myu@... myu@...

View Event

Description:
──────────

ELISA Project is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Meeting ID: 957 7511 4472
Passcode: 289297
One tap mobile
+16465588656,,95775114472#,,,,,,0#,,289297# US (New York)
+13017158592,,95775114472#,,,,,,0#,,289297# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
855 703 8985 Canada Toll-free
Meeting ID: 957 7511 4472
Passcode: 289297
Find your local number: https://zoom.us/u/aQIrrAQlD


Telltale FFI Analysis: some questions...

Gabriele Paoloni
 

Hi Jochen, all

In the arch wg we are kicking off the FFI analysis for the Telltale Use case (https://docs.google.com/presentation/d/1FgvptS6eMNnNcDkhbINHH0_ItJOMQREB/edit#slide=id.p1). 
So there is some support that we would require from your side guys:
1) Active communication channels between the safety app and the QM(B) or NSR Apps. Right now I see that there is a FIFO between the safety app and the msg generator:
https://github.com/elisa-tech/wg-automotive-safety-app/blob/main/safety-app.c#L61.
However this is a make-up for the communication between the external safety monitor and the safety app, right? If so we should neglect this....
Apart from that is there any inter-process communication mechanisms between the Safety App and any other process that we should consider?

2) Do we assume the safety app WTD to be dedicated to it or shared with other processes?

3) Is there a way to identify syscalls and other entrypoints (e.g. exception/interrupt handlers) invoked by QM(B) as well as NSR applications running concurrently with the safety app?

Thanks
Gab



ww29 Agenda

Gabriele Paoloni
 

Hi All

For today we'll continue the discussion about the Telltale Kernel FMEA and we'll kick-off the Telltale Kernel FFI discussion.

Thanks
Gab 


Event: ELISA Safety-Architecture Weekly Meeting - 07/20/2021 #cal-reminder

safety-architecture@lists.elisa.tech Calendar <noreply@...>
 

Reminder: ELISA Safety-Architecture Weekly Meeting

When:
07/20/2021
12:00pm to 1:00pm
(UTC+00:00) UTC

Where:
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Organizer: myu@... myu@...

View Event

Description:
──────────

ELISA Project is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Meeting ID: 957 7511 4472
Passcode: 289297
One tap mobile
+16465588656,,95775114472#,,,,,,0#,,289297# US (New York)
+13017158592,,95775114472#,,,,,,0#,,289297# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
855 703 8985 Canada Toll-free
Meeting ID: 957 7511 4472
Passcode: 289297
Find your local number: https://zoom.us/u/aQIrrAQlD


ww28 agenda

Gabriele Paoloni
 

Hi All

Today I would like to: 
- continue last week discussion on the Telltale Safety focusing on the follow-up mailing list comments
- start drafting the FFI analysis for the telltale

Thanks
Gab


Event: ELISA Safety-Architecture Weekly Meeting - 07/13/2021 #cal-reminder

safety-architecture@lists.elisa.tech Calendar <noreply@...>
 

Reminder: ELISA Safety-Architecture Weekly Meeting

When:
07/13/2021
12:00pm to 1:00pm
(UTC+00:00) UTC

Where:
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Organizer: myu@... myu@...

View Event

Description:
──────────

ELISA Project is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Meeting ID: 957 7511 4472
Passcode: 289297
One tap mobile
+16465588656,,95775114472#,,,,,,0#,,289297# US (New York)
+13017158592,,95775114472#,,,,,,0#,,289297# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
855 703 8985 Canada Toll-free
Meeting ID: 957 7511 4472
Passcode: 289297
Find your local number: https://zoom.us/u/aQIrrAQlD


Re: Two hybrid approach observations

Christopher Temple
 

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

 

 

 

From: Paccapeli, Roberto <roberto.paccapeli@...>
Sent: Donnerstag, 8. Juli 2021 16:32
To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; safety-architecture@...
Subject: RE: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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,

 

A close up of a sign

Description automatically generated

 

Roberto Paccapeli

Functional Safety Manager  |  IOTG PMCE FSS

 

D +39 050.782.0014  |  M +39 339.589.2630

Via Lenin 132/p  |  S. Giuliano Terme, Italy, 56017

Intel Corporation  |  intel.com

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Christopher Temple
Sent: Thursday, July 8, 2021 1:11 PM
To: Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

 

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech
Sent: Mittwoch, 7. Juli 2021 16:00
To: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Christopher Temple
Sent: Wednesday, July 07, 2021 16:17
To: safety-architecture@...
Subject: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

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

Dr. Christopher Temple

Lead Safety & Reliability Architect

Architecture & Technology Group

 

ARM Germany GmbH

Bretonischer Ring 16

D-85630 Grasbrunn bei München

 

Phone: +49 89 26204 2525

eMail: Christopher.Temple@...

 

 

Sitz der Gesellschaft: Grasbrunn, Geschäftsführer: Joachim Krech, Reinhard Keil

Handelsregister: München (HRB 175362),  USt-IdNr.: DE187925309

www.arm.de

 

 

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.

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.


Re: Two hybrid approach observations

Gabriele Paoloni
 

Hi All

On 08/07/2021 16:32, Paccapeli, Roberto wrote:
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/ <https://docs.google.com/presentation/d/1Tiz5IT5tVi4QynXMYrChLZm8KLeH14Vz/edit#slide=id.p4>

OK, by comparison with
https://docs.google.com/presentation/d/1L1Q8jDltic4ZgKED_rHTz9_8TolAMjnq/ <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?? 😊
Yes, probably the correct way would be to have a decomposition as in
QM(B) for the telltale rendering and ASILB(B) for the safety function +
the external monitor. This is also pretty clear from the safety concept:
https://github.com/Jochen-Kall/wg-automotive/blob/master/AGL_cluster_demo_use_case/Concept.md
where we have QM(B) reqs

 

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
<https://drive.google.com/drive/u/0/folders/1BoK0PC1yYWuVtT4AuK_VW1T2U2WwQZTF>).
Yes correct. the analysis we did is agnostic of the decomposition and we
assume to be able to prove FFI between SR and NSR Kernel components
(however this point is OPEN and must be still discussed).
WRT FFI between QM(B) and ASILB(B) user space apps this is required
according to KSR_0015 and KSR_0016 as in
https://docs.google.com/spreadsheets/d/1EbuVvhXo-xZc2aPTfMgQtPNPDQYtcozs/edit#gid=584539121
However we still need to elaborate on these reqs, so this is a TODO.

Thank you
Gab


 

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,

 

*A close up of a sign Description automatically generated*

* *

*Roberto Paccapeli*

Functional Safety Manager  |  IOTG PMCE FSS

 

D +39 050.782.0014  |  M +39 339.589.2630

Via Lenin 132/p  |  S. Giuliano Terme, Italy, 56017

*Intel Corporation*  |  *intel.com*

 

*From:*safety-architecture@...
<safety-architecture@...> *On Behalf Of *Christopher Temple
*Sent:* Thursday, July 8, 2021 1:11 PM
*To:* Gurvitz, Eli (Mobileye) <eli.gurvitz@...>;
safety-architecture@...
*Subject:* Re: [ELISA Safety Architecture WG] Two hybrid approach
observations

 

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
o ASIL decomposition delivers functionality that is safety related
and functionality that is non-safety related, and
o the complete functionality that can deliver single point faults
is designated as non-safety related.

 

Best regards

Chris

 

 

*From:*safety-architecture@...
<mailto:safety-architecture@...>
<safety-architecture@...
<mailto:safety-architecture@...>> *On Behalf Of *Gurvitz,
Eli (Mobileye) via lists.elisa.tech
*Sent:* Mittwoch, 7. Juli 2021 16:00
*To:* safety-architecture@...
<mailto:safety-architecture@...>
*Subject:* Re: [ELISA Safety Architecture WG] Two hybrid approach
observations

 

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

 

*From:*safety-architecture@...
<mailto:safety-architecture@...>
<safety-architecture@...
<mailto:safety-architecture@...>> *On Behalf Of
*Christopher Temple
*Sent:* Wednesday, July 07, 2021 16:17
*To:* safety-architecture@...
<mailto:safety-architecture@...>
*Subject:* [ELISA Safety Architecture WG] Two hybrid approach observations

 

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.
o ISO 26262 defines “safety related function” as “function that
has the potential to contribute to the violation of or
achievement of a safety goal”
o Hence, according to ISO 26262 the tell-tale rendering and its
related functionality is “safety related”.
o In the hybrid approach the tell-tale rendering is designated as
“non-safety related”, while the safety function is treated as
“safety related”
o 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
o The output of the safety analysis then serves as means to define
the safety mechanisms (ISO26262) or safety function (IEC61508)
o 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).
o 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

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

<http://www.arm.com/>



Dr. Christopher Temple

Lead Safety & Reliability Architect

Architecture & Technology Group

 

*ARM Germany GmbH*

Bretonischer Ring 16

D-85630 Grasbrunn bei München

 

Phone: +49 89 26204 2525

eMail: Christopher.Temple@... <mailto:Christopher.Temple@...>

 

 



Sitz der Gesellschaft: Grasbrunn, Geschäftsführer: Joachim Krech,
Reinhard Keil

Handelsregister: München (HRB 175362),  USt-IdNr.: DE187925309

www.arm.de <http://www.arm.de/>

 

 

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.


Re: Two hybrid approach observations

Paccapeli, Roberto
 

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,

 

A close up of a sign

Description automatically generated

 

Roberto Paccapeli

Functional Safety Manager  |  IOTG PMCE FSS

 

D +39 050.782.0014  |  M +39 339.589.2630

Via Lenin 132/p  |  S. Giuliano Terme, Italy, 56017

Intel Corporation  |  intel.com

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Christopher Temple
Sent: Thursday, July 8, 2021 1:11 PM
To: Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

 

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech
Sent: Mittwoch, 7. Juli 2021 16:00
To: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Christopher Temple
Sent: Wednesday, July 07, 2021 16:17
To: safety-architecture@...
Subject: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

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

Dr. Christopher Temple

Lead Safety & Reliability Architect

Architecture & Technology Group

 

ARM Germany GmbH

Bretonischer Ring 16

D-85630 Grasbrunn bei München

 

Phone: +49 89 26204 2525

eMail: Christopher.Temple@...

 

 

Sitz der Gesellschaft: Grasbrunn, Geschäftsführer: Joachim Krech, Reinhard Keil

Handelsregister: München (HRB 175362),  USt-IdNr.: DE187925309

www.arm.de

 

 

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.


Re: Two hybrid approach observations

Christopher Temple
 

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

 

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech
Sent: Mittwoch, 7. Juli 2021 16:00
To: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Christopher Temple
Sent: Wednesday, July 07, 2021 16:17
To: safety-architecture@...
Subject: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

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

Dr. Christopher Temple

Lead Safety & Reliability Architect

Architecture & Technology Group

 

ARM Germany GmbH

Bretonischer Ring 16

D-85630 Grasbrunn bei München

 

Phone: +49 89 26204 2525

eMail: Christopher.Temple@...

 

 

Sitz der Gesellschaft: Grasbrunn, Geschäftsführer: Joachim Krech, Reinhard Keil

Handelsregister: München (HRB 175362),  USt-IdNr.: DE187925309

www.arm.de

 

 

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.


Re: Agenda - Weekly call, 7.7.2021

Elana C
 

Adding others, who may be interested in this invited talk.

 

From: development-process@... <development-process@...> On Behalf Of Elana Copperman
Sent: Wednesday, July 7, 2021 2:43 PM
To: development-process@...; Burylov, Ilya <ilya.burylov@...>; Katranov, Alexei <alexei.katranov@...>
Subject: [ELISA Development Process WG] Agenda - Weekly call, 7.7.2021

 

In this week's call, Alexei and Ilya will join us to speak about their experience in using dyanmic analysis tools (TSAN, in particular) for safety testing of a complex open source library.  Adding other WGs, in case anyone is interested in joining tomorrow's weekly call.

Agenda:

 

Please be sure to come prepared for a good open discussion on what we can learn from this for safety testing of complex multi-threaded embedded systems.

Regards

Elana

 


Re: Two hybrid approach observations

Gurvitz, Eli (Mobileye)
 

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

 

From: safety-architecture@... <safety-architecture@...> On Behalf Of Christopher Temple
Sent: Wednesday, July 07, 2021 16:17
To: safety-architecture@...
Subject: [ELISA Safety Architecture WG] Two hybrid approach observations

 

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

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

Dr. Christopher Temple

Lead Safety & Reliability Architect

Architecture & Technology Group

 

ARM Germany GmbH

Bretonischer Ring 16

D-85630 Grasbrunn bei München

 

Phone: +49 89 26204 2525

eMail: Christopher.Temple@...

 

 

Sitz der Gesellschaft: Grasbrunn, Geschäftsführer: Joachim Krech, Reinhard Keil

Handelsregister: München (HRB 175362),  USt-IdNr.: DE187925309

www.arm.de

 

 

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.


Two hybrid approach observations

Christopher Temple
 

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

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

Dr. Christopher Temple

Lead Safety & Reliability Architect

Architecture & Technology Group

 

ARM Germany GmbH

Bretonischer Ring 16

D-85630 Grasbrunn bei München

 

Phone: +49 89 26204 2525

eMail: Christopher.Temple@...

 

 

Sitz der Gesellschaft: Grasbrunn, Geschäftsführer: Joachim Krech, Reinhard Keil

Handelsregister: München (HRB 175362),  USt-IdNr.: DE187925309

www.arm.de

 

 

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.


ww27 Agenda

Gabriele Paoloni
 

Hi All

Following the last TSC meeting I had a sync-up with Paul and he is not
ready yet to start applying the Codethink methodology in the Arch WG.
So for today we'll continue the discussion about the in-context
countermeasure following the telltale FMEA analyses

Gab


Event: ELISA Safety-Architecture Weekly Meeting - 07/06/2021 #cal-reminder

safety-architecture@lists.elisa.tech Calendar <noreply@...>
 

Reminder: ELISA Safety-Architecture Weekly Meeting

When:
07/06/2021
12:00pm to 1:00pm
(UTC+00:00) UTC

Where:
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Organizer: myu@... myu@...

View Event

Description:
──────────

ELISA Project is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Meeting ID: 957 7511 4472
Passcode: 289297
One tap mobile
+16465588656,,95775114472#,,,,,,0#,,289297# US (New York)
+13017158592,,95775114472#,,,,,,0#,,289297# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
855 703 8985 Canada Toll-free
Meeting ID: 957 7511 4472
Passcode: 289297
Find your local number: https://zoom.us/u/aQIrrAQlD


Cancelled Event: ELISA Safety-Architecture Weekly Meeting - Tuesday, June 29, 2021 #cal-cancelled

safety-architecture@lists.elisa.tech Calendar <noreply@...>
 

Cancelled: ELISA Safety-Architecture Weekly Meeting

This event has been cancelled.

When:
Tuesday, June 29, 2021
12:00pm to 1:00pm
(UTC+00:00) UTC

Where:
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Organizer: myu@... myu@...

Description:
──────────

ELISA Project is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Meeting ID: 957 7511 4472
Passcode: 289297
One tap mobile
+16465588656,,95775114472#,,,,,,0#,,289297# US (New York)
+13017158592,,95775114472#,,,,,,0#,,289297# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
855 703 8985 Canada Toll-free
Meeting ID: 957 7511 4472
Passcode: 289297
Find your local number: https://zoom.us/u/aQIrrAQlD


Event: ELISA Safety-Architecture Weekly Meeting - 06/29/2021 #cal-reminder

safety-architecture@lists.elisa.tech Calendar <noreply@...>
 

Reminder: ELISA Safety-Architecture Weekly Meeting

When:
06/29/2021
12:00pm to 1:00pm
(UTC+00:00) UTC

Where:
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Organizer: myu@... myu@...

View Event

Description:
──────────

ELISA Project is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/95775114472?pwd=VDFzTjRjNW8yd3ZOQWVLS1ZpWFlEUT09

Meeting ID: 957 7511 4472
Passcode: 289297
One tap mobile
+16465588656,,95775114472#,,,,,,0#,,289297# US (New York)
+13017158592,,95775114472#,,,,,,0#,,289297# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
855 703 8985 Canada Toll-free
Meeting ID: 957 7511 4472
Passcode: 289297
Find your local number: https://zoom.us/u/aQIrrAQlD

141 - 160 of 719