A Third Route to Divide and Conquer


John MacGregor
 

Hi Gab,

Other than the two 26262 routes that you have identified, I think there's a third: developing the block from scratch, either under 26262 or 61508 (for wider applicability if not to reduce the effort). This may not be an alternative for the ELISA project, but at least for drivers, it might be interesting for hardware manufacturers and it might also be feasible for consortia of interested companies to develop modules or subsystems. The more that can be cleanly divided along existing interfaces, the higher the conquest for safety applications.

Certainly, the idea would be to upstream the result which would imply that it would be accepted and maintained by the Linux community.

Among the advantages for developing from scratch I see:
- The block / component would have a known pedigree - it would arguably be QM (or SIL 0) - both the SR and NSR parts.
- The safety requirements, the CoUs and the reasoning behind them could be documented which would ease future patch impact analysis.
- Coding requirements like MISRA compliance, use of pointers or single points of entry and exit, etc. could be addressed in the new code rather than having to justify violations in or patching existing code
- Special component / block versions could be developed with functionality tailored for safety or which would dispense with selected Linux features to reduce the complexity and ease verification.
- Having safety versions of the functionality upstream would have an explicit influence on the future evolution of internal Kernel interfaces and spread the maintenance effort over more companies.

Although there are advantages for the development side of the "V" don't see any particular advantages for the verification and validation side, or for the generation of requirements (traceability maybe). At least for the cases where tailored functionality is developed, the requirements process might be more explicit.

As I said, this is not an option for now, but it is something to keep in mind.

Cheers

John


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

Hi John

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of John MacGregor
Sent: Wednesday, April 14, 2021 10:28 AM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: [ELISA Safety Architecture WG] A Third Route to Divide and Conquer

Hi Gab,

Other than the two 26262 routes that you have identified, I think
there's a third: developing the block from scratch, either under 26262
or 61508 (for wider applicability if not to reduce the effort). This
may not be an alternative for the ELISA project, but at least for
drivers, it might be interesting for hardware manufacturers and it might
also be feasible for consortia of interested companies to develop
modules or subsystems. The more that can be cleanly divided along
existing interfaces, the higher the conquest for safety applications.

Certainly, the idea would be to upstream the result which would imply
that it would be accepted and maintained by the Linux community.

Among the advantages for developing from scratch I see:
- The block / component would have a known pedigree - it would arguably
be QM (or SIL 0) - both the SR and NSR parts.
- The safety requirements, the CoUs and the reasoning behind them could
be documented which would ease future patch impact analysis.
- Coding requirements like MISRA compliance, use of pointers or single
points of entry and exit, etc. could be addressed in the new code rather
than having to justify violations in or patching existing code
- Special component / block versions could be developed with
functionality tailored for safety or which would dispense with selected
Linux features to reduce the complexity and ease verification.
- Having safety versions of the functionality upstream would have an
explicit influence on the future evolution of internal Kernel interfaces
and spread the maintenance effort over more companies.

Although there are advantages for the development side of the "V" don't
see any particular advantages for the verification and validation side,
or for the generation of requirements (traceability maybe). At least
for the cases where tailored functionality is developed, the
requirements process might be more explicit.

As I said, this is not an option for now, but it is something to keep in
mind.
It may work WRT new drivers however I think that it is a bit early to
introduce this topic. I.e. I'd first prefer to consolidate the hybrid approach
to qualify the pre-existing Linux and then I would start to consider
how to maintain it, including the process to integrate new drivers.

So yes, let's keep this in mind and address this later on.

Thanks for the feedbacks!
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.


John MacGregor
 

Hi Gab,

um, OK...


But the point is that, if there should be some especially difficult, i.e. complex, part of the pre-existing Linux we might reach a dead-end. That would be the time to consider writing something tailored to replace the existing code. And it might not even be the ELISA project per se that would have to consider that.

So, yes, we should pursue the current method to its end, hopefully thereby achieving qualification for a complete Linux.

Cheers

John

On 14/04/2021 14:22, Paoloni, Gabriele wrote:
Hi John

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of John MacGregor
Sent: Wednesday, April 14, 2021 10:28 AM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: [ELISA Safety Architecture WG] A Third Route to Divide and Conquer

Hi Gab,

Other than the two 26262 routes that you have identified, I think
there's a third: developing the block from scratch, either under 26262
or 61508 (for wider applicability if not to reduce the effort). This
may not be an alternative for the ELISA project, but at least for
drivers, it might be interesting for hardware manufacturers and it might
also be feasible for consortia of interested companies to develop
modules or subsystems. The more that can be cleanly divided along
existing interfaces, the higher the conquest for safety applications.

Certainly, the idea would be to upstream the result which would imply
that it would be accepted and maintained by the Linux community.

Among the advantages for developing from scratch I see:
- The block / component would have a known pedigree - it would arguably
be QM (or SIL 0) - both the SR and NSR parts.
- The safety requirements, the CoUs and the reasoning behind them could
be documented which would ease future patch impact analysis.
- Coding requirements like MISRA compliance, use of pointers or single
points of entry and exit, etc. could be addressed in the new code rather
than having to justify violations in or patching existing code
- Special component / block versions could be developed with
functionality tailored for safety or which would dispense with selected
Linux features to reduce the complexity and ease verification.
- Having safety versions of the functionality upstream would have an
explicit influence on the future evolution of internal Kernel interfaces
and spread the maintenance effort over more companies.

Although there are advantages for the development side of the "V" don't
see any particular advantages for the verification and validation side,
or for the generation of requirements (traceability maybe). At least
for the cases where tailored functionality is developed, the
requirements process might be more explicit.

As I said, this is not an option for now, but it is something to keep in
mind.
It may work WRT new drivers however I think that it is a bit early to
introduce this topic. I.e. I'd first prefer to consolidate the hybrid approach
to qualify the pre-existing Linux and then I would start to consider
how to maintain it, including the process to integrate new drivers.
So yes, let's keep this in mind and address this later on.
Thanks for the feedbacks!
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@...>
 

Hi John

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of John MacGregor
Sent: Wednesday, April 14, 2021 3:28 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] A Third Route to Divide and
Conquer

Hi Gab,

um, OK...


But the point is that, if there should be some especially difficult,
i.e. complex, part of the pre-existing Linux we might reach a dead-end.
That would be the time to consider writing something tailored to
replace the existing code. And it might not even be the ELISA project
per se that would have to consider that.
I think that the power of such hybrid method is that, in case of complex
subsystems, it allows to reduce the granularity even down to the function
level if needed...so to be honest I cannot picture why we should take
an exception to re-write a piece of code according to part6...

BTW let's see how it goes

Thanks
Gab


So, yes, we should pursue the current method to its end, hopefully
thereby achieving qualification for a complete Linux.

Cheers

John

On 14/04/2021 14:22, Paoloni, Gabriele wrote:
Hi John

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of John MacGregor
Sent: Wednesday, April 14, 2021 10:28 AM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: [ELISA Safety Architecture WG] A Third Route to Divide and
Conquer

Hi Gab,

Other than the two 26262 routes that you have identified, I think
there's a third: developing the block from scratch, either under 26262
or 61508 (for wider applicability if not to reduce the effort). This
may not be an alternative for the ELISA project, but at least for
drivers, it might be interesting for hardware manufacturers and it might
also be feasible for consortia of interested companies to develop
modules or subsystems. The more that can be cleanly divided along
existing interfaces, the higher the conquest for safety applications.

Certainly, the idea would be to upstream the result which would imply
that it would be accepted and maintained by the Linux community.

Among the advantages for developing from scratch I see:
- The block / component would have a known pedigree - it would arguably
be QM (or SIL 0) - both the SR and NSR parts.
- The safety requirements, the CoUs and the reasoning behind them
could
be documented which would ease future patch impact analysis.
- Coding requirements like MISRA compliance, use of pointers or single
points of entry and exit, etc. could be addressed in the new code rather
than having to justify violations in or patching existing code
- Special component / block versions could be developed with
functionality tailored for safety or which would dispense with selected
Linux features to reduce the complexity and ease verification.
- Having safety versions of the functionality upstream would have an
explicit influence on the future evolution of internal Kernel interfaces
and spread the maintenance effort over more companies.

Although there are advantages for the development side of the "V" don't
see any particular advantages for the verification and validation side,
or for the generation of requirements (traceability maybe). At least
for the cases where tailored functionality is developed, the
requirements process might be more explicit.

As I said, this is not an option for now, but it is something to keep in
mind.
It may work WRT new drivers however I think that it is a bit early to
introduce this topic. I.e. I'd first prefer to consolidate the hybrid approach
to qualify the pre-existing Linux and then I would start to consider
how to maintain it, including the process to integrate new drivers.

So yes, let's keep this in mind and address this later on.

Thanks for the feedbacks!
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.


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