1. Safety-Architecture
  2. Topics

The "quick and easy" approach as alternative to the hybrid approach

Lukas Bulwahn
 

Dear all,


I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be replaced by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a
safety-critical software.
(2) Every software once implemented has by definition an architecture.

Conclusion: A software once implemented fulfils the demand of the
safety standard X.

As far as I see, this argumentation is completely valid. Hence to
comply with the clause of a safety standard X, there is really nothing
more to do then to simply apply this completely logical argument here.


The remaining questions are:

Is there a valid and valuable interpretation of some safety standard X
that would meet the assumption (1)?

Would this safety standard X be considered suitable to be applied to
pre-existing (already implemented) software?



Due to the discussion on the hybrid approach, I finally discovered
this very quick and easy approach to claim compliance with the
"architecture clause of the safety standard X". This will help me a
lot. Thanks for all the support.


Best regards,

Lukas
Oscar Slotosch
 

HI Lukas,
This was a real fun to read this proposal.
If we continue like this, we could even argue that every software is safe, since it has an architecture (including the unsafe ones that
demonstrated to fail), and all safety standards can be abolished (at least the architecture parts).

The problem in your argumentation is that point (1) is a weakening of the safety standards, since they not only require
"the existence" as you claimed wrongly in your argumentation but much more. Namely
1) Documentation
2) Analysis (and reduction) for risks
3) Appropriateness for the requirements
4) Tests

Basic principle in safety is the "redundancy". While this is quite clear for Systems & HW, in SW this could either mean a second SW,
or a second person/team understanding and confirming the SW and documenting that (for responsibility sake).

Kind regards,
Oscar
-----Ursprüngliche Nachricht-----
Von: safety-architecture@... <safety-architecture@...> Im Auftrag von Lukas Bulwahn
Gesendet: Donnerstag, 27. Mai 2021 07:27
An: safety-architecture@...
Betreff: [ELISA Safety Architecture WG] The "quick and easy" approach as alternative to the hybrid approach

Dear all,


I would propose a very simple "quick and easy" approach to architecture to comply with "safety standard X". (X may be replaced by any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a safety-critical software.
(2) Every software once implemented has by definition an architecture.

Conclusion: A software once implemented fulfils the demand of the safety standard X.

As far as I see, this argumentation is completely valid. Hence to comply with the clause of a safety standard X, there is really nothing more to do then to simply apply this completely logical argument here.


The remaining questions are:

Is there a valid and valuable interpretation of some safety standard X that would meet the assumption (1)?

Would this safety standard X be considered suitable to be applied to pre-existing (already implemented) software?



Due to the discussion on the hybrid approach, I finally discovered this very quick and easy approach to claim compliance with the "architecture clause of the safety standard X". This will help me a lot. Thanks for all the support.


Best regards,

Lukas
Lukas Bulwahn
 

On Thu, May 27, 2021 at 10:56 AM Oscar Slotosch <slotosch@...> wrote:
This was a real fun to read this proposal.
If we continue like this, we could even argue that every software is safe, since it has an architecture (including the unsafe ones that
demonstrated to fail), and all safety standards can be abolished (at least the architecture parts).

The problem in your argumentation is that point (1) is a weakening of the safety standards, since they not only require
"the existence" as you claimed wrongly in your argumentation but much more. Namely
1) Documentation
2) Analysis (and reduction) for risks
3) Appropriateness for the requirements
4) Tests

Basic principle in safety is the "redundancy". While this is quite clear for Systems & HW, in SW this could either mean a second SW,
or a second person/team understanding and confirming the SW and documenting that (for responsibility sake).
Oscar, thanks for this hint. So, the core criteria of any work for
increasing confidence is:
- to show that there an increase of understanding of the software
and the system and the software's contribution to/interaction within
that system,
- and document the activity in a suitable way for others to confirm
that this understanding has increased.

I assume that any work would need to argue that it meets those core criteria.

Now, I understand that the "quick and easy" approach does not meet
those core criteria. Maybe we need to check if a suggested approach
meets those criteria, and contributes to 2) Analysis (and reduction)
for risks, checking "3) Appropriateness for the requirements", and
useful for applying "Test" methods.

Also, what are really the important aspects to show an increase of
understanding of a second person/team? Does this not include being
able to understand and observe some non-trivial property of the
involved software beyond the fact that "some C functions call other C
functions", i.e., that is correct but a very basic property of any
program, right?

Thanks again, Oscar, for pointing out what any analysis and
documentation of software architecture should contribute.

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

Hi Lukas

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Lukas Bulwahn
Sent: Thursday, May 27, 2021 7:27 AM
To: safety-architecture@...
Subject: [ELISA Safety Architecture WG] The "quick and easy" approach as
alternative to the hybrid approach

Dear all,


I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be replaced by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a
safety-critical software.
(2) Every software once implemented has by definition an architecture.

Conclusion: A software once implemented fulfils the demand of the
safety standard X.
The conclusion in my view is wrong, as you can derive and describe a
SW architectural design from a pre-existing, hence implemented, SW
but you need to do a safety analysis on it against the allocated safety
requirements to show that the SW architectural design is able to meet
such safety requirements


As far as I see, this argumentation is completely valid. Hence to
comply with the clause of a safety standard X, there is really nothing
more to do then to simply apply this completely logical argument here.


The remaining questions are:

Is there a valid and valuable interpretation of some safety standard X
that would meet the assumption (1)?

Would this safety standard X be considered suitable to be applied to
pre-existing (already implemented) software?



Due to the discussion on the hybrid approach, I finally discovered
this very quick and easy approach to claim compliance with the
"architecture clause of the safety standard X". This will help me a
lot. Thanks for all the support.
I do not see how this 'quick and easy' approach can be related to
the hybrid approach since the latter implies a safety analysis on the
derived architecture.

Gab

p.s. I assume that this proposal only focuses on the SW architecture
part of the standard (i.e. indeed we also need all the verification and
validation part of the standard and I assume that this is implicit in this
proposal)



Best regards,

Lukas



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

Hi Lukas,
You are welcome. Always when things seam to easy to be true, it's worth discussing them😉

Indeed we need to document properties like X calls Y within the architecture, even if this is "obvious" from the code
and can be generated automatically from appropriate tools.
I think the biggest help of that different representation is that this allows us to re-think the SW/Architecture with a different perspective.
If X calls Y and we document X calls Y using an arrow between two axes. Where is the benefit?
if Y is something critical, than we might think if really X should be able to call Y and check the conditions,...
If all is OK that's OK, otherwise we found a bug and can improves safety.
So only "having" the sequence diagrams is no value, but having re-thought/analyzed them ("redundancy")
and documenting that is what increases safety and standards require us to do.

One we have established this method, we can start to argue the compliance with the safety standards and see what exactly
they require. Maybe we derive a checklist of things that need to be done & verified for every architecture we model.

Kind regards,
Oscar


-----Ursprüngliche Nachricht-----
Von: Lukas Bulwahn <lukas.bulwahn@...>
Gesendet: Donnerstag, 27. Mai 2021 13:31
An: Oscar Slotosch <slotosch@...>
Cc: safety-architecture@...
Betreff: Re: [ELISA Safety Architecture WG] The "quick and easy" approach as alternative to the hybrid approach

On Thu, May 27, 2021 at 10:56 AM Oscar Slotosch <slotosch@...> wrote:
This was a real fun to read this proposal.
If we continue like this, we could even argue that every software is
safe, since it has an architecture (including the unsafe ones that demonstrated to fail), and all safety standards can be abolished (at least the architecture parts).

The problem in your argumentation is that point (1) is a weakening of
the safety standards, since they not only require "the existence" as
you claimed wrongly in your argumentation but much more. Namely
1) Documentation
2) Analysis (and reduction) for risks
3) Appropriateness for the requirements
4) Tests

Basic principle in safety is the "redundancy". While this is quite
clear for Systems & HW, in SW this could either mean a second SW, or a second person/team understanding and confirming the SW and documenting that (for responsibility sake).
Oscar, thanks for this hint. So, the core criteria of any work for increasing confidence is:
- to show that there an increase of understanding of the software and the system and the software's contribution to/interaction within that system,
- and document the activity in a suitable way for others to confirm that this understanding has increased.

I assume that any work would need to argue that it meets those core criteria.

Now, I understand that the "quick and easy" approach does not meet those core criteria. Maybe we need to check if a suggested approach meets those criteria, and contributes to 2) Analysis (and reduction) for risks, checking "3) Appropriateness for the requirements", and useful for applying "Test" methods.

Also, what are really the important aspects to show an increase of understanding of a second person/team? Does this not include being able to understand and observe some non-trivial property of the involved software beyond the fact that "some C functions call other C functions", i.e., that is correct but a very basic property of any program, right?

Thanks again, Oscar, for pointing out what any analysis and documentation of software architecture should contribute.

Lukas
Sanjay Trivedi
 

+1 to the thoughts of Lukas.

-----Original Message-----
From: safety-architecture@... <safety-architecture@...> On Behalf Of Oscar Slotosch via lists.elisa.tech
Sent: Thursday, May 27, 2021 5:32 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] The "quick and easy" approach as alternative to the hybrid approach

External email: Use caution opening links or attachments


Hi Lukas,
You are welcome. Always when things seam to easy to be true, it's worth discussing them😉

Indeed we need to document properties like X calls Y within the architecture, even if this is "obvious" from the code and can be generated automatically from appropriate tools.
I think the biggest help of that different representation is that this allows us to re-think the SW/Architecture with a different perspective.
If X calls Y and we document X calls Y using an arrow between two axes. Where is the benefit?
if Y is something critical, than we might think if really X should be able to call Y and check the conditions,...
If all is OK that's OK, otherwise we found a bug and can improves safety.
So only "having" the sequence diagrams is no value, but having re-thought/analyzed them ("redundancy") and documenting that is what increases safety and standards require us to do.

One we have established this method, we can start to argue the compliance with the safety standards and see what exactly they require. Maybe we derive a checklist of things that need to be done & verified for every architecture we model.

Kind regards,
Oscar


-----Ursprüngliche Nachricht-----
Von: Lukas Bulwahn <lukas.bulwahn@...>
Gesendet: Donnerstag, 27. Mai 2021 13:31
An: Oscar Slotosch <slotosch@...>
Cc: safety-architecture@...
Betreff: Re: [ELISA Safety Architecture WG] The "quick and easy" approach as alternative to the hybrid approach

On Thu, May 27, 2021 at 10:56 AM Oscar Slotosch <slotosch@...> wrote:
This was a real fun to read this proposal.
If we continue like this, we could even argue that every software is
safe, since it has an architecture (including the unsafe ones that demonstrated to fail), and all safety standards can be abolished (at least the architecture parts).

The problem in your argumentation is that point (1) is a weakening of
the safety standards, since they not only require "the existence" as
you claimed wrongly in your argumentation but much more. Namely
1) Documentation
2) Analysis (and reduction) for risks
3) Appropriateness for the requirements
4) Tests

Basic principle in safety is the "redundancy". While this is quite
clear for Systems & HW, in SW this could either mean a second SW, or a second person/team understanding and confirming the SW and documenting that (for responsibility sake).
Oscar, thanks for this hint. So, the core criteria of any work for increasing confidence is:
- to show that there an increase of understanding of the software and the system and the software's contribution to/interaction within that system,
- and document the activity in a suitable way for others to confirm that this understanding has increased.

I assume that any work would need to argue that it meets those core criteria.

Now, I understand that the "quick and easy" approach does not meet those core criteria. Maybe we need to check if a suggested approach meets those criteria, and contributes to 2) Analysis (and reduction) for risks, checking "3) Appropriateness for the requirements", and useful for applying "Test" methods.

Also, what are really the important aspects to show an increase of understanding of a second person/team? Does this not include being able to understand and observe some non-trivial property of the involved software beyond the fact that "some C functions call other C functions", i.e., that is correct but a very basic property of any program, right?

Thanks again, Oscar, for pointing out what any analysis and documentation of software architecture should contribute.

Lukas
Lukas Bulwahn
 

On Thu, May 27, 2021 at 1:42 PM Paoloni, Gabriele
<gabriele.paoloni@...> wrote:

Hi Lukas

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Lukas Bulwahn
Sent: Thursday, May 27, 2021 7:27 AM
To: safety-architecture@...
Subject: [ELISA Safety Architecture WG] The "quick and easy" approach as
alternative to the hybrid approach

Dear all,


I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be replaced by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a
safety-critical software.
(2) Every software once implemented has by definition an architecture.

Conclusion: A software once implemented fulfils the demand of the
safety standard X.
The conclusion in my view is wrong, as you can derive and describe a
SW architectural design from a pre-existing, hence implemented, SW
but you need to do a safety analysis on it against the allocated safety
requirements to show that the SW architectural design is able to meet
such safety requirements
Thanks, Gab, so we need to show that any description of the software
supports the safety analysis (risk assessment or risk mitigation) for
a specific safety requirement.

Now that I think about it, I did not yet understand how the
description of the software in the hybrid approach supports the risk
assessment or risk mitigation for a specific safety requirement.


As far as I see, this argumentation is completely valid. Hence to
comply with the clause of a safety standard X, there is really nothing
more to do then to simply apply this completely logical argument here.


The remaining questions are:

Is there a valid and valuable interpretation of some safety standard X
that would meet the assumption (1)?

Would this safety standard X be considered suitable to be applied to
pre-existing (already implemented) software?



Due to the discussion on the hybrid approach, I finally discovered
this very quick and easy approach to claim compliance with the
"architecture clause of the safety standard X". This will help me a
lot. Thanks for all the support.
I do not see how this 'quick and easy' approach can be related to
the hybrid approach since the latter implies a safety analysis on the
derived architecture.
Thanks, I think that I now understand that the safety analysis is the
core; so given a reasonable understanding of the functionality and a
bit of kernel expertise, the safety analysis could potentially be done
without any artefacts that the hybrid approach currently foresees to
"generate" as preparational step to the safety analysis. So, the
quality of the analysis boils down to: who executes the safety
analysis and which competence does this person have? And only then:
which artefacts does that person require? and why? And potentially:
does the request of that information indicate a crucial gap of
knowledge and competence of that person?

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

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Lukas Bulwahn
Sent: Thursday, May 27, 2021 3:59 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] The "quick and easy" approach
as alternative to the hybrid approach

On Thu, May 27, 2021 at 1:42 PM Paoloni, Gabriele
<gabriele.paoloni@...> wrote:

Hi Lukas

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of Lukas Bulwahn
Sent: Thursday, May 27, 2021 7:27 AM
To: safety-architecture@...
Subject: [ELISA Safety Architecture WG] The "quick and easy" approach
as
alternative to the hybrid approach

Dear all,


I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be replaced by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a
safety-critical software.
(2) Every software once implemented has by definition an architecture.

Conclusion: A software once implemented fulfils the demand of the
safety standard X.
The conclusion in my view is wrong, as you can derive and describe a
SW architectural design from a pre-existing, hence implemented, SW
but you need to do a safety analysis on it against the allocated safety
requirements to show that the SW architectural design is able to meet
such safety requirements
Thanks, Gab, so we need to show that any description of the software
supports the safety analysis (risk assessment or risk mitigation) for
a specific safety requirement.

Now that I think about it, I did not yet understand how the
description of the software in the hybrid approach supports the risk
assessment or risk mitigation for a specific safety requirement.
Once safety requirements are allocated to SW Units/Blocks the
safety analysis is done evaluating the SW Architectural design
(describing the interactions of a target block/unit with the others)
and evaluating the specs allocated to the single block.
You can find examples here:
- iotcl(): https://drive.google.com/file/d/1-qfyfWJasfXc3IES7RUtfnnxkVsKkOkl/view?usp=sharing
- watchdog_ioctl(): https://docs.google.com/spreadsheets/d/1LSPSdo16TU4uut2shDvhaWuMnEKPBqlS/edit#gid=459221992




As far as I see, this argumentation is completely valid. Hence to
comply with the clause of a safety standard X, there is really nothing
more to do then to simply apply this completely logical argument here.


The remaining questions are:

Is there a valid and valuable interpretation of some safety standard X
that would meet the assumption (1)?

Would this safety standard X be considered suitable to be applied to
pre-existing (already implemented) software?



Due to the discussion on the hybrid approach, I finally discovered
this very quick and easy approach to claim compliance with the
"architecture clause of the safety standard X". This will help me a
lot. Thanks for all the support.
I do not see how this 'quick and easy' approach can be related to
the hybrid approach since the latter implies a safety analysis on the
derived architecture.
Thanks, I think that I now understand that the safety analysis is the
core; so given a reasonable understanding of the functionality and a
bit of kernel expertise, the safety analysis could potentially be done
without any artefacts that the hybrid approach currently foresees to
"generate" as preparational step to the safety analysis. So, the
From my experience a safety analysis based exclusively on expert
judgement (hence without a supporting arch design doc) is hardly
acceptable

Gab

quality of the analysis boils down to: who executes the safety
analysis and which competence does this person have? And only then:
which artefacts does that person require? and why? And potentially:
does the request of that information indicate a crucial gap of
knowledge and competence of that person?

Lukas



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

On Fri, May 28, 2021 at 3:29 PM Paoloni, Gabriele
<gabriele.paoloni@...> wrote:

I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be replaced by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a
safety-critical software.
(2) Every software once implemented has by definition an architecture.

Conclusion: A software once implemented fulfils the demand of the
safety standard X.

Due to the discussion on the hybrid approach, I finally discovered
this very quick and easy approach to claim compliance with the
"architecture clause of the safety standard X". This will help me a
lot. Thanks for all the support.
I do not see how this 'quick and easy' approach can be related to
the hybrid approach since the latter implies a safety analysis on the
derived architecture.
Thanks, I think that I now understand that the safety analysis is the
core; so given a reasonable understanding of the functionality and a
bit of kernel expertise, the safety analysis could potentially be done
without any artefacts that the hybrid approach currently foresees to
"generate" as preparational step to the safety analysis. So, the
From my experience a safety analysis based exclusively on expert
judgement (hence without a supporting arch design doc) is hardly
acceptable
Well, from my experience, the only key criteria for a safety analysis
is expert knowledge and expert judgement; all criteria on formality
can be met independently of the behaviour, risks and complexity of the
actual system by any stringent organizational support, without
affecting the content of the technical claims derived, i.e., the
conclusions of the safety analysis.
So, all supporting material is only to show evidence for the experts'
knowledge of the system and to serve as communication means among them
to show and ensure equal expert knowledge. Hence, a supporting arch
design document is useless if it has not been manually created by the
involved experts in alignment and with the goal to be used as evidence
that the involved experts during the execution of the safety analysis
have deeper knowledge about the system.

If I understand the approach right, you envision the supporting arch
design document to be created pretty automatically and hence show that
the expertise of the involved experts for the safety analysis is
on-par to what a basic (knowingly incomplete) source code analysis can
derive; I think that can serve as a good basis for the proof of
competence of the involved experts. With that at hand, then you can
quickly also just execute the safety analysis and you are done. This
sounds like a good plan to quickly and easily achieve compliance. I
propose you continue that approach with precisely that goal in mind.


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

Hi Lukas

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Friday, May 28, 2021 4:14 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] The "quick and easy" approach
as alternative to the hybrid approach

On Fri, May 28, 2021 at 3:29 PM Paoloni, Gabriele
<gabriele.paoloni@...> wrote:

I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be replaced
by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a
safety-critical software.
(2) Every software once implemented has by definition an
architecture.

Conclusion: A software once implemented fulfils the demand of the
safety standard X.

Due to the discussion on the hybrid approach, I finally discovered
this very quick and easy approach to claim compliance with the
"architecture clause of the safety standard X". This will help me a
lot. Thanks for all the support.
I do not see how this 'quick and easy' approach can be related to
the hybrid approach since the latter implies a safety analysis on the
derived architecture.
Thanks, I think that I now understand that the safety analysis is the
core; so given a reasonable understanding of the functionality and a
bit of kernel expertise, the safety analysis could potentially be done
without any artefacts that the hybrid approach currently foresees to
"generate" as preparational step to the safety analysis. So, the
From my experience a safety analysis based exclusively on expert
judgement (hence without a supporting arch design doc) is hardly
acceptable
Well, from my experience, the only key criteria for a safety analysis
is expert knowledge and expert judgement; all criteria on formality
can be met independently of the behaviour, risks and complexity of the
actual system by any stringent organizational support, without
affecting the content of the technical claims derived, i.e., the
conclusions of the safety analysis.
So, all supporting material is only to show evidence for the experts'
knowledge of the system and to serve as communication means among
them
to show and ensure equal expert knowledge. Hence, a supporting arch
design document is useless if it has not been manually created by the
involved experts in alignment and with the goal to be used as evidence
that the involved experts during the execution of the safety analysis
have deeper knowledge about the system.

If I understand the approach right, you envision the supporting arch
design document to be created pretty automatically and hence show that
the expertise of the involved experts for the safety analysis is
on-par to what a basic (knowingly incomplete) source code analysis can
derive; I think that can serve as a good basis for the proof of
competence of the involved experts. With that at hand, then you can
quickly also just execute the safety analysis and you are done. This
sounds like a good plan to quickly and easily achieve compliance. I
propose you continue that approach with precisely that goal in mind.
Nope, arch design doc is not created automatically. It is computer aided
but not automatic.
More specifically the communication diagrams (static views of SW units blocks
communicating with each other) is automatic, however the dynamic behavior
(described by the sequence diagram or automata diagram and kernel-doc
headers) is based on manual creation with some computer aided design.

Once we have the design doc, this is used to evaluate the current design against
the allocated safety reqs, possible failure modes, the effects and existing or
possible mitigations.

Finally the design doc can be used to derive and assess a test campaign and
runtime verification monitors are used to spot defects either in the code or in
the model (that as I said are done manually).

So I don’t think that this approach is so 'quick and easy'...

Thanks
Gab



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

Gab,
I completely agree.
It was not easy to build Linux and re-thinking and documenting cannot be quick & easy.
* Redundancy => Safety
* Quick & Easy => Danger

Of course we can reduce the pain, e.g. by using document generators as we do at Validas, but that's just one part of the approach we propose

Kind regards,
Oscar


-----Ursprüngliche Nachricht-----
Von: safety-architecture@... <safety-architecture@...> Im Auftrag von Paoloni, Gabriele
Gesendet: Freitag, 28. Mai 2021 16:51
An: Lukas Bulwahn <lukas.bulwahn@...>
Cc: safety-architecture@...
Betreff: Re: [ELISA Safety Architecture WG] The "quick and easy" approach as alternative to the hybrid approach

Hi Lukas

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Friday, May 28, 2021 4:14 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] The "quick and easy"
approach as alternative to the hybrid approach

On Fri, May 28, 2021 at 3:29 PM Paoloni, Gabriele
<gabriele.paoloni@...> wrote:

I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be
replaced
by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture
for a safety-critical software.
(2) Every software once implemented has by definition an
architecture.

Conclusion: A software once implemented fulfils the demand of
the safety standard X.

Due to the discussion on the hybrid approach, I finally
discovered this very quick and easy approach to claim
compliance with the "architecture clause of the safety
standard X". This will help me a lot. Thanks for all the support.
I do not see how this 'quick and easy' approach can be related
to the hybrid approach since the latter implies a safety
analysis on the derived architecture.
Thanks, I think that I now understand that the safety analysis is
the core; so given a reasonable understanding of the functionality
and a bit of kernel expertise, the safety analysis could
potentially be done without any artefacts that the hybrid approach
currently foresees to "generate" as preparational step to the
safety analysis. So, the
From my experience a safety analysis based exclusively on expert
judgement (hence without a supporting arch design doc) is hardly
acceptable
Well, from my experience, the only key criteria for a safety analysis
is expert knowledge and expert judgement; all criteria on formality
can be met independently of the behaviour, risks and complexity of the
actual system by any stringent organizational support, without
affecting the content of the technical claims derived, i.e., the
conclusions of the safety analysis.
So, all supporting material is only to show evidence for the experts'
knowledge of the system and to serve as communication means among them
to show and ensure equal expert knowledge. Hence, a supporting arch
design document is useless if it has not been manually created by the
involved experts in alignment and with the goal to be used as evidence
that the involved experts during the execution of the safety analysis
have deeper knowledge about the system.

If I understand the approach right, you envision the supporting arch
design document to be created pretty automatically and hence show that
the expertise of the involved experts for the safety analysis is
on-par to what a basic (knowingly incomplete) source code analysis can
derive; I think that can serve as a good basis for the proof of
competence of the involved experts. With that at hand, then you can
quickly also just execute the safety analysis and you are done. This
sounds like a good plan to quickly and easily achieve compliance. I
propose you continue that approach with precisely that goal in mind.
Nope, arch design doc is not created automatically. It is computer aided but not automatic.
More specifically the communication diagrams (static views of SW units blocks communicating with each other) is automatic, however the dynamic behavior (described by the sequence diagram or automata diagram and kernel-doc
headers) is based on manual creation with some computer aided design.

Once we have the design doc, this is used to evaluate the current design against the allocated safety reqs, possible failure modes, the effects and existing or possible mitigations.

Finally the design doc can be used to derive and assess a test campaign and runtime verification monitors are used to spot defects either in the code or in the model (that as I said are done manually).

So I don’t think that this approach is so 'quick and easy'...

Thanks
Gab



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

On Fri, May 28, 2021 at 4:51 PM Paoloni, Gabriele
<gabriele.paoloni@...> wrote:

Hi Lukas

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Friday, May 28, 2021 4:14 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>
Cc: safety-architecture@...
Subject: Re: [ELISA Safety Architecture WG] The "quick and easy" approach
as alternative to the hybrid approach

On Fri, May 28, 2021 at 3:29 PM Paoloni, Gabriele
<gabriele.paoloni@...> wrote:

I would propose a very simple "quick and easy" approach to
architecture to comply with "safety standard X". (X may be replaced
by
any standard that meets assumption (1) below.)

Assumptions:
(1) Safety standard X demands the existence of an architecture for a
safety-critical software.
(2) Every software once implemented has by definition an
architecture.

Conclusion: A software once implemented fulfils the demand of the
safety standard X.

Due to the discussion on the hybrid approach, I finally discovered
this very quick and easy approach to claim compliance with the
"architecture clause of the safety standard X". This will help me a
lot. Thanks for all the support.
I do not see how this 'quick and easy' approach can be related to
the hybrid approach since the latter implies a safety analysis on the
derived architecture.
Thanks, I think that I now understand that the safety analysis is the
core; so given a reasonable understanding of the functionality and a
bit of kernel expertise, the safety analysis could potentially be done
without any artefacts that the hybrid approach currently foresees to
"generate" as preparational step to the safety analysis. So, the
From my experience a safety analysis based exclusively on expert
judgement (hence without a supporting arch design doc) is hardly
acceptable
Well, from my experience, the only key criteria for a safety analysis
is expert knowledge and expert judgement; all criteria on formality
can be met independently of the behaviour, risks and complexity of the
actual system by any stringent organizational support, without
affecting the content of the technical claims derived, i.e., the
conclusions of the safety analysis.
So, all supporting material is only to show evidence for the experts'
knowledge of the system and to serve as communication means among
them
to show and ensure equal expert knowledge. Hence, a supporting arch
design document is useless if it has not been manually created by the
involved experts in alignment and with the goal to be used as evidence
that the involved experts during the execution of the safety analysis
have deeper knowledge about the system.

If I understand the approach right, you envision the supporting arch
design document to be created pretty automatically and hence show that
the expertise of the involved experts for the safety analysis is
on-par to what a basic (knowingly incomplete) source code analysis can
derive; I think that can serve as a good basis for the proof of
competence of the involved experts. With that at hand, then you can
quickly also just execute the safety analysis and you are done. This
sounds like a good plan to quickly and easily achieve compliance. I
propose you continue that approach with precisely that goal in mind.
Nope, arch design doc is not created automatically. It is computer aided
but not automatic.
More specifically the communication diagrams (static views of SW units blocks
communicating with each other) is automatic, however the dynamic behavior
(described by the sequence diagram or automata diagram and kernel-doc
headers) is based on manual creation with some computer aided design.
I like your approach of visualizing the existing call-tree structure.
That is nice and we did that, too, back in 2019 and 2020 and shared
that with the group; just as Constantine did that as well many years
ago, and shared it with everyone back then; there was also a reason
for us to develop the call graph tool, although in the various
contexts, we applied it, it was clearly used for other means that
claim any completeness or meaningful interpretation by itself, e.g.,
only to visualize other information, e.g., information in test
coverage reports, we could simply not grasp otherwise in a meaningful
way (and we always acknowledged the incompleteness of our call graph
analysis).

Once we have the design doc, this is used to evaluate the current design against
the allocated safety reqs, possible failure modes, the effects and existing or
possible mitigations.
Don't you need to know the specific allocated safety requirement to
determine if this one kind of breakdown/decomposition you propose is
meaningful at all for the specific allocated safety requirement?

Hint: A safety requirement is very often not a requirement to a single
isolated function, nor may it be necessarily linked to a synchronous
behaviour of the system; remember the ECC example and its handling
through HW and SW.

E.g., define sources of interference and explain how the call graph is
related to those sources of interference.

As I already said, for the identification of interference patterns,
and other alternative approaches, we best start new working groups
(e.g., the "Identification of interference in a complex HW-SW system
and its impact" WG) with a fresh start without being driven by any
previous limits of conception.

I think the architecture working group (and anyone that believes in
the value of the approach) should continue to look at the call graphs,
try to land some patches with kernel-doc comments (let us see what the
maintainers' feedback is here; as far as remember, the patches from
linux.intel.com with the safety-critical/safety-related keyword have
been well and properly handled so far from a quality perspective), and
then continue to understand where the added value of hybrid approach
finally kicks in contributing to the objectives beyond achieving
compliance to some interpretation of some historically scoped
standards.

You just got here some food for thought from me, let us keep it with
that. I propose you continue your approach and we let others make the
other valuable alternative approaches evolve as well. Gab, I wish you
good luck :)


Best regards,

Lukas

1 - 12 of 12