safety-architecture@lists.elisa.tech | Epilogue to today's telco

John MacGregor

#453

Hi Gab,

Two points that I wanted to make, but time ran out.  They could wait until later, but you're revising the document anyway.  And maybe somebody has an opinion.

- I've always thought that Linux would be qualified by using 8.12 but, instead of considering Linux to be a black-box component, Linux would be defined to have some white-box attributes that required some extra consideration under the 8.12 requirements: behaviour under failure, behaviour under overload, etc.  The idea would be to argue that Linux fulfils the intent of the clause and document the extenuating circumstances.  Would that be, at least partially, an alternative to switching directly to Part 6?
- 26262 seems to have a weird set of terms for, well, components.  But I sort of get the impression, that one of the differences between an element or an item and a component might be that a component is "off-the-shelf" and is permitted to contain extraneous functionality that is not relevant to the system at hand.  In other words, dead code may be allowed.  I see through that an advantage to looking at Linux as a (system) component.  Any opinions?

Cheers

John

Oscar Slotosch

#454

Hi John,
8-12 is accepted for smaller components, e.g. libraries, hence Linux is a counter example of it 😉
That's probably because we are analysing the architecture to break it down into smaller "components"
that do have a chance to be qualified according to 8-12.

Kind regards,
	Oscar

-----Ursprüngliche Nachricht-----
Von: safety-architecture@... <safety-architecture@...> Im Auftrag von John MacGregor
Gesendet: Dienstag, 30. März 2021 18:15
An: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Betreff: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi Gab,

Two points that I wanted to make, but time ran out.  They could wait until later, but you're revising the document anyway.  And maybe somebody has an opinion.

- I've always thought that Linux would be qualified by using 8.12 but, instead of considering Linux to be a black-box component, Linux would be defined to have some white-box attributes that required some extra consideration under the 8.12 requirements: behaviour under failure, behaviour under overload, etc.  The idea would be to argue that Linux fulfils the intent of the clause and document the extenuating circumstances.  Would that be, at least partially, an alternative to switching directly to Part 6?
- 26262 seems to have a weird set of terms for, well, components.  But I sort of get the impression, that one of the differences between an element or an item and a component might be that a component is "off-the-shelf" and is permitted to contain extraneous functionality that is not relevant to the system at hand.  In other words, dead code may be allowed.  I see through that an advantage to looking at Linux as a (system) component.  Any opinions?

Cheers

John

Paoloni, Gabriele <gabriele.paoloni@...>

#455

Hi john

Show quoted text

-----Original Message-----
From: John MacGregor <open.john.macgregor@...>
Sent: Tuesday, March 30, 2021 6:15 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Epilogue to today's telco

Hi Gab,

Two points that I wanted to make, but time ran out.  They could wait
until later, but you're revising the document anyway.  And maybe
somebody has an opinion.

- I've always thought that Linux would be qualified by using 8.12 but,
instead of considering Linux to be a black-box component, Linux would be
defined to have some white-box attributes that required some extra
consideration under the 8.12 requirements: behaviour under failure,
behaviour under overload, etc.  The idea would be to argue that Linux
fulfils the intent of the clause and document the extenuating
circumstances.  Would that be, at least partially, an alternative to
switching directly to Part 6?Well in part8 if we read through 12.4.2.1 we can see that the example
calling out on the requirement specification already mention the
behavior under failure condition and in overload situation.
In my opinion the problem with Linux is that it is too big to be able
to comprehensively describe such behavior from a top level entrypoints
point of view....hence my proposal to do a partitioning of Linux into
pre-existing blocks and to qualify each of them according to part8.12
and integrate them according to part6.
Basically with my approach I am trying to avoid the collaterals' explosion
of moving directly to part6, explosion that happens when we go at the
unit level where unit==function, while being able to safely build an
argumentation and deliver something that is scalable/portable/modular
(as different blocks/components come into the scope or as we change the
CONFIG params for some of the blocks/components we do not need to
re-do the whole qualification but probably just address a modular delta)

- 26262 seems to have a weird set of terms for, well, components.  But I
sort of get the impression, that one of the differences between an
element or an item and a component might be that a component is
"off-the-shelf" and is permitted to contain extraneous functionality
that is not relevant to the system at hand.  In other words, dead code
may be allowed.  I see through that an advantage to looking at Linux as
a (system) component.  Any opinions?Yes...I think that for a specific component/block the code can be dead/live
depending on the specific CONFIG or HW architecture that it runs on....as long
as the different behavior of the component due to either a different HW or different
CONFIG can be comprehensively described by the top level specs in my view
it is ok to have such configurability/variability of the code.

Thanks
Gab


Cheers

John---------------------------------------------------------------------
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.

Paoloni, Gabriele <gabriele.paoloni@...>

#456

Show quoted text

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Oscar Slotosch
Sent: Tuesday, March 30, 2021 7:59 PM
To: John MacGregor <open.john.macgregor@...>; Paoloni, Gabriele
<gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi John,
8-12 is accepted for smaller components, e.g. libraries, hence Linux is a
counter example of it 😉
That's probably because we are analysing the architecture to break it down
into smaller "components"
that do have a chance to be qualified according to 8-12.+1  and BTW the approach is hybrid since for the integration of 8.12 blocks part6 should be followed 😉

Thanks
Gab


Kind regards,
	Oscar

-----Ursprüngliche Nachricht-----
Von: safety-architecture@... <safety-
architecture@...> Im Auftrag von John MacGregor
Gesendet: Dienstag, 30. März 2021 18:15
An: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Betreff: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi Gab,

Two points that I wanted to make, but time ran out.  They could wait until
later, but you're revising the document anyway.  And maybe somebody has
an opinion.

- I've always thought that Linux would be qualified by using 8.12 but, instead
of considering Linux to be a black-box component, Linux would be defined to
have some white-box attributes that required some extra consideration
under the 8.12 requirements: behaviour under failure, behaviour under
overload, etc.  The idea would be to argue that Linux fulfils the intent of the
clause and document the extenuating circumstances.  Would that be, at least
partially, an alternative to switching directly to Part 6?
- 26262 seems to have a weird set of terms for, well, components.  But I sort
of get the impression, that one of the differences between an element or an
item and a component might be that a component is "off-the-shelf" and is
permitted to contain extraneous functionality that is not relevant to the
system at hand.  In other words, dead code may be allowed.  I see through
that an advantage to looking at Linux as a (system) component.  Any
opinions?

Cheers

John








---------------------------------------------------------------------
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.

John MacGregor

#461

Hi Gab,

Below

Cheers

John


On 30/03/2021 20:11, Paoloni, Gabriele wrote:
Hi john

-----Original Message-----
From: John MacGregor <open.john.macgregor@...>
Sent: Tuesday, March 30, 2021 6:15 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Epilogue to today's telco

Hi Gab,

Two points that I wanted to make, but time ran out.  They could wait
until later, but you're revising the document anyway.  And maybe
somebody has an opinion.

- I've always thought that Linux would be qualified by using 8.12 but,
instead of considering Linux to be a black-box component, Linux would be
defined to have some white-box attributes that required some extra
consideration under the 8.12 requirements: behaviour under failure,
behaviour under overload, etc.  The idea would be to argue that Linux
fulfils the intent of the clause and document the extenuating
circumstances.  Would that be, at least partially, an alternative to
switching directly to Part 6?Well in part8 if we read through 12.4.2.1 we can see that the example
calling out on the requirement specification already mention the
behavior under failure condition and in overload situation.
In my opinion the problem with Linux is that it is too big to be able
to comprehensively describe such behavior from a top level entrypoints
point of view....hence my proposal to do a partitioning of Linux into
pre-existing blocks and to qualify each of them according to part8.12
and integrate them according to part6.
Basically with my approach I am trying to avoid the collaterals' explosion
of moving directly to part6, explosion that happens when we go at the
unit level where unit==function, while being able to safely build an
argumentation and deliver something that is scalable/portable/modular
(as different blocks/components come into the scope or as we change the
CONFIG params for some of the blocks/components we do not need to
re-do the whole qualification but probably just address a modular delta)
(from me)
Would that be, at least partially, an alternative to switching directly to Part 6?

Just for the record, I meant that white box testing of the blocks/components might be considered an alternative to treating them as black boxes and when that didn't work switching immediately to Part 6.

Sorry for the confusion.

- 26262 seems to have a weird set of terms for, well, components.  But I
sort of get the impression, that one of the differences between an
element or an item and a component might be that a component is
"off-the-shelf" and is permitted to contain extraneous functionality
that is not relevant to the system at hand.  In other words, dead code
may be allowed.  I see through that an advantage to looking at Linux as
a (system) component.  Any opinions?Yes...I think that for a specific component/block the code can be dead/live
depending on the specific CONFIG or HW architecture that it runs on....as long
as the different behavior of the component due to either a different HW or different
CONFIG can be comprehensively described by the top level specs in my view
it is ok to have such configurability/variability of the code.
Thanks
Gab


Cheers

John---------------------------------------------------------------------
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.

Paoloni, Gabriele <gabriele.paoloni@...>

#462

Hi John

[snip]

(from me)
 >> Would that be, at least partially, an alternative to switching
directly to Part 6?

Just for the record, I meant that white box testing of the
blocks/components might be considered an alternative to treating them as
black boxes and when that didn't work switching immediately to Part 6.

Sorry for the confusion.I am not sure to be honest as I see two issues here:
- a practical issue: " white box testing of the blocks/components " implies
in practice to provide unit testing, code coverage, detailed architecture of
the such blocks/components. And here we would fall again into the explosive
effort of part6;
- a safety standard issue: an enhanced part8.12 with some white box testing
as of today is not formalized anywhere in the ISO26262 and if we wanted to
write an ISO-PAS to cover this gap it would be more difficult to propose
white-box testing without the rest of part6 collaterals. Instead the hybrid
approach I proposed could work already with the current ISO26262 although
I reckon that, as of today, we are still missing criteria to define what is the
acceptable complexity of a component to apply 8.12 (i.e. the criteria for
the granularity); such gap could be covered by an ISO-PAS.

Thanks
Gab

[snip]
---------------------------------------------------------------------
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.

Christopher Temple

#463

Do we agree that part 8-12 (Qualified element) and part 6 (Safety element) are not equivalent in the result achieved?

Best regards
Chris

Show quoted text

-----Original Message-----
From: safety-architecture@... <safety-architecture@...> On Behalf Of Paoloni, Gabriele via lists.elisa.tech
Sent: Mittwoch, 7. April 2021 13:20
To: John MacGregor <open.john.macgregor@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi John

[snip]

(from me)
 >> Would that be, at least partially, an alternative to switching
directly to Part 6?

Just for the record, I meant that white box testing of the
blocks/components might be considered an alternative to treating them
as black boxes and when that didn't work switching immediately to Part 6.

Sorry for the confusion.I am not sure to be honest as I see two issues here:
- a practical issue: " white box testing of the blocks/components " implies in practice to provide unit testing, code coverage, detailed architecture of the such blocks/components. And here we would fall again into the explosive effort of part6;
- a safety standard issue: an enhanced part8.12 with some white box testing as of today is not formalized anywhere in the ISO26262 and if we wanted to write an ISO-PAS to cover this gap it would be more difficult to propose white-box testing without the rest of part6 collaterals. Instead the hybrid approach I proposed could work already with the current ISO26262 although I reckon that, as of today, we are still missing criteria to define what is the acceptable complexity of a component to apply 8.12 (i.e. the criteria for the granularity); such gap could be covered by an ISO-PAS.

Thanks
Gab

[snip]
---------------------------------------------------------------------
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.

Paoloni, Gabriele <gabriele.paoloni@...>

#464

Hi Chris

Part6 sets the process requirements to be followed for newly developed SW,
whereas part8.12 focuses on the qualification of pre-existing SW components
to be re-used together with items developed according to the ISO26262.
If we deal with a pre-existing SW element we can either assess it according
to part6 or qualify according to part8.12; however part8.12 is commonly
recognized to not be suitable for complex SW elements (e.g. operating systems).

The proposal I discussed last week is about a hybrid approach where
we partition Linux in components that would be qualified according to
part8.12 whereas the integration between such components and their
interaction can be assessed following part6 (and gaps shall be filled accordingly).

You can look at the ppt here: https://drive.google.com/file/d/1rAa3yIOBIwJ_DD2YxgOaPSnMSlL6sWr3/view?usp=sharing

Thanks
Gab

Show quoted text

-----Original Message-----
From: Christopher Temple <Christopher.Temple@...>
Sent: Wednesday, April 7, 2021 2:08 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor
<open.john.macgregor@...>
Cc: safety-architecture@...
Subject: RE: [ELISA Safety Architecture WG] Epilogue to today's telco

Do we agree that part 8-12 (Qualified element) and part 6 (Safety element)
are not equivalent in the result achieved?

Best regards
Chris

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Paoloni, Gabriele via
lists.elisa.tech
Sent: Mittwoch, 7. April 2021 13:20
To: John MacGregor <open.john.macgregor@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi John

[snip]

(from me)
 >> Would that be, at least partially, an alternative to switching
directly to Part 6?

Just for the record, I meant that white box testing of the
blocks/components might be considered an alternative to treating them
as black boxes and when that didn't work switching immediately to Part 6.

Sorry for the confusion.I am not sure to be honest as I see two issues here:
- a practical issue: " white box testing of the blocks/components " implies in
practice to provide unit testing, code coverage, detailed architecture of the
such blocks/components. And here we would fall again into the explosive
effort of part6;
- a safety standard issue: an enhanced part8.12 with some white box testing
as of today is not formalized anywhere in the ISO26262 and if we wanted to
write an ISO-PAS to cover this gap it would be more difficult to propose
white-box testing without the rest of part6 collaterals. Instead the hybrid
approach I proposed could work already with the current ISO26262 although I
reckon that, as of today, we are still missing criteria to define what is the
acceptable complexity of a component to apply 8.12 (i.e. the criteria for the
granularity); such gap could be covered by an ISO-PAS.

Thanks
Gab

[snip]
---------------------------------------------------------------------
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.---------------------------------------------------------------------
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.

Oscar Slotosch

#465

Hi Gab,
Thanks for sharing the slides with me. I like them.
It's in the same direction of what Validas is proposing since a year: Follow-Part 6 and define the architecture
Fitting to the concrete requirements for your system.
We also have a (complete) ISO 26262 compliance argumentation for that.
Maybe we can demonstrate this in next month using some case studies.

Regarding the qualification of the components according to 8-12.
There is one additional (important) argument: The components are "unchanged" and not modified.
So this will apply for some components (e.g. stable libraries/drivers), but not to newly developed drivers or kernel-patches.

Kind regards,
	Oscar

-----Ursprüngliche Nachricht-----
Von: safety-architecture@... <safety-architecture@...> Im Auftrag von Paoloni, Gabriele
Gesendet: Mittwoch, 7. April 2021 15:07
An: Christopher Temple <Christopher.Temple@...>; John MacGregor <open.john.macgregor@...>
Cc: safety-architecture@...
Betreff: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi Chris

Part6 sets the process requirements to be followed for newly developed SW, whereas part8.12 focuses on the qualification of pre-existing SW components to be re-used together with items developed according to the ISO26262.
If we deal with a pre-existing SW element we can either assess it according to part6 or qualify according to part8.12; however part8.12 is commonly recognized to not be suitable for complex SW elements (e.g. operating systems).

The proposal I discussed last week is about a hybrid approach where we partition Linux in components that would be qualified according to
part8.12 whereas the integration between such components and their interaction can be assessed following part6 (and gaps shall be filled accordingly).

You can look at the ppt here: https://drive.google.com/file/d/1rAa3yIOBIwJ_DD2YxgOaPSnMSlL6sWr3/view?usp=sharing

Thanks
Gab

Show quoted text

-----Original Message-----
From: Christopher Temple <Christopher.Temple@...>
Sent: Wednesday, April 7, 2021 2:08 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor 
<open.john.macgregor@...>
Cc: safety-architecture@...
Subject: RE: [ELISA Safety Architecture WG] Epilogue to today's telco

Do we agree that part 8-12 (Qualified element) and part 6 (Safety 
element) are not equivalent in the result achieved?

Best regards
Chris

-----Original Message-----
From: safety-architecture@... <safety- 
architecture@...> On Behalf Of Paoloni, Gabriele via 
lists.elisa.tech
Sent: Mittwoch, 7. April 2021 13:20
To: John MacGregor <open.john.macgregor@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi John

[snip]

(from me)
 >> Would that be, at least partially, an alternative to switching 
directly to Part 6?

Just for the record, I meant that white box testing of the 
blocks/components might be considered an alternative to treating 
them as black boxes and when that didn't work switching immediately to Part 6.

Sorry for the confusion.I am not sure to be honest as I see two issues here:
- a practical issue: " white box testing of the blocks/components " 
implies in practice to provide unit testing, code coverage, detailed 
architecture of the such blocks/components. And here we would fall 
again into the explosive effort of part6;
- a safety standard issue: an enhanced part8.12 with some white box 
testing as of today is not formalized anywhere in the ISO26262 and if 
we wanted to write an ISO-PAS to cover this gap it would be more 
difficult to propose white-box testing without the rest of part6 
collaterals. Instead the hybrid approach I proposed could work already 
with the current ISO26262 although I reckon that, as of today, we are 
still missing criteria to define what is the acceptable complexity of 
a component to apply 8.12 (i.e. the criteria for the granularity); such gap could be covered by an ISO-PAS.

Thanks
Gab

[snip]
---------------------------------------------------------------------
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.---------------------------------------------------------------------
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.

Paoloni, Gabriele <gabriele.paoloni@...>

#466

Hi Oscar

Show quoted text

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Oscar Slotosch
Sent: Wednesday, April 7, 2021 10:05 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>; Christopher Temple
<Christopher.Temple@...>; John MacGregor
<open.john.macgregor@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi Gab,
Thanks for sharing the slides with me. I like them.
It's in the same direction of what Validas is proposing since a year: Follow-
Part 6 and define the architecture
Fitting to the concrete requirements for your system.
We also have a (complete) ISO 26262 compliance argumentation for that.
Maybe we can demonstrate this in next month using some case studies. I am not familiar with the Validas approach however, if we want to take the hybrid
approach direction, we have gaps in Linux that we need to fill;
e.g, WRT the design phase :
a) find the right level of granularity and define the elementary components/items
accordingly
b) develop the architectural models and diagrams describing the interactions between
the above mentioned elementary components/items
c) for each component/item identify the input API and write kernel-doc headers describing
the requirements allocated to  such component/item (to allow qualification according to
part8.12).
My hope is that, if we come to a consensus and we prove the feasibility of such approach,
we start working first on the design gaps and then on the rest of the collaterals that will be
required for the functional safety qualification/assessment

Regarding the qualification of the components according to 8-12.
There is one additional (important) argument: The components are
"unchanged" and not modified.
So this will apply for some components (e.g. stable libraries/drivers), but not
to newly developed drivers or kernel-patches.Well this is a bit of grey area. Part8.12 does not mention the maintenance of a pre-existing
SW component and the NOTE in 8.12.4.1 leaves a certain degree of interpretation.
In my view if we reckon this approach to be valid for Linux and more in general for complex
SW components we could revisit the standard to make clear consideration also about this
point 

Thanks
Gab

Kind regards,
	Oscar

-----Ursprüngliche Nachricht-----
Von: safety-architecture@... <safety-
architecture@...> Im Auftrag von Paoloni, Gabriele
Gesendet: Mittwoch, 7. April 2021 15:07
An: Christopher Temple <Christopher.Temple@...>; John MacGregor
<open.john.macgregor@...>
Cc: safety-architecture@...
Betreff: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi Chris

Part6 sets the process requirements to be followed for newly developed SW,
whereas part8.12 focuses on the qualification of pre-existing SW
components to be re-used together with items developed according to the
ISO26262.
If we deal with a pre-existing SW element we can either assess it according to
part6 or qualify according to part8.12; however part8.12 is commonly
recognized to not be suitable for complex SW elements (e.g. operating
systems).

The proposal I discussed last week is about a hybrid approach where we
partition Linux in components that would be qualified according to
part8.12 whereas the integration between such components and their
interaction can be assessed following part6 (and gaps shall be filled
accordingly).

You can look at the ppt here:
https://drive.google.com/file/d/1rAa3yIOBIwJ_DD2YxgOaPSnMSlL6sWr3/vie
w?usp=sharing

Thanks
Gab

-----Original Message-----
From: Christopher Temple <Christopher.Temple@...>
Sent: Wednesday, April 7, 2021 2:08 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor
<open.john.macgregor@...>
Cc: safety-architecture@...
Subject: RE: [ELISA Safety Architecture WG] Epilogue to today's telco

Do we agree that part 8-12 (Qualified element) and part 6 (Safety
element) are not equivalent in the result achieved?

Best regards
Chris

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Paoloni, Gabriele via
lists.elisa.tech
Sent: Mittwoch, 7. April 2021 13:20
To: John MacGregor <open.john.macgregor@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] Epilogue to today's telco

Hi John

[snip]

(from me)
 >> Would that be, at least partially, an alternative to switching
directly to Part 6?

Just for the record, I meant that white box testing of the
blocks/components might be considered an alternative to treating
them as black boxes and when that didn't work switching immediately toPart 6.

Sorry for the confusion.I am not sure to be honest as I see two issues here:
- a practical issue: " white box testing of the blocks/components "
implies in practice to provide unit testing, code coverage, detailed
architecture of the such blocks/components. And here we would fall
again into the explosive effort of part6;
- a safety standard issue: an enhanced part8.12 with some white box
testing as of today is not formalized anywhere in the ISO26262 and if
we wanted to write an ISO-PAS to cover this gap it would be more
difficult to propose white-box testing without the rest of part6
collaterals. Instead the hybrid approach I proposed could work already
with the current ISO26262 although I reckon that, as of today, we are
still missing criteria to define what is the acceptable complexity of
a component to apply 8.12 (i.e. the criteria for the granularity); such gapcould be covered by an ISO-PAS.

Thanks
Gab

[snip]
---------------------------------------------------------------------
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.---------------------------------------------------------------------
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.

---------------------------------------------------------------------
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.