Date   

Re: unable to host next week

Min Yu
 

Will someone host the ELISA Architecture meeting on Tuesday June 29th, 8-9am ET / 2-3pm CET? If I don't hear any volunteers by EOD Monday, I will cancel the meeting.

Thanks!
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


On Thu, Jun 24, 2021 at 9:37 AM Paoloni, Gabriele <gabriele.paoloni@...> wrote:

Hi guys

 

Due to my job transition (and other private tasks) I am not able to host next week meeting. If anybody wants to do so please let me know.

 

Thanks

Gab

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


unable to host next week

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

Hi guys

 

Due to my job transition (and other private tasks) I am not able to host next week meeting. If anybody wants to do so please let me know.

 

Thanks

Gab

---------------------------------------------------------------------
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] change of WG material links

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

Hi All

 

Since I am leaving Intel soon I had to do remove the current directories and do a new upload of all the WG material (I could not change ownership of the files).

The material itself and the directories structure has not change however you will possibly find a lot of broken links
in your Browser history.

 

The link of the top level dir is unchanged: https://drive.google.com/drive/u/1/folders/137-9__2BUFZbu--N3jZM418ILetC971s

The new meeting minutes link is: https://drive.google.com/file/d/1wxPKJMiUP7RHU7GMEtsHL0DwMZukBf4q/view?usp=sharing

 

Sorry for the inconvenience but it is the only workaround that I found.

 

Thanks

Gab

 

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


ww26 - Agenda

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

Hi all

 

For today  I have the following topic:

  • Modifying CallTree to resolve Macros (StefanoD)
  • Cotinuation of the re-evaluation of the FS and watchdog subsystem FMEAs in the context of the Telltale use case

 

Thanks

Gab

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


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

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

Reminder: ELISA Safety-Architecture Weekly Meeting

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

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

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

View Event

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

ELISA Project is inviting you to a scheduled Zoom meeting.

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

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

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


Gab's leaving Intel

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

Dear participants of the safety architecture WG

 

I am writing to inform you that I am leaving Intel to join a new adventure with Red Hat.

Following my transition I expect no changes in the Safety Architecture WG activities; so
I will continue to lead the WG as usual and to contribute to ELISA as usual.

 

Note that my last day at Intel will be Jun 25th whereas I will join Red Hat from Jul 1st.
I will let you know if I am able to join the WG session on Jun 29th.

 

Kind Regards

Gab

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

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


Re: [ELISA Development Process WG] Linux architecture

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

Hi Paul

Thanks ofr raising this

-----Original Message-----
From: development-process@... <development-
process@...> On Behalf Of Paul Albertella
Sent: Friday, June 18, 2021 11:24 AM
To: development-process@...; safety-
architecture@...
Subject: [ELISA Development Process WG] Linux architecture

Hi,

A term that is frequently referenced in both the Development Process and
Safety Architecture working groups is 'architecture'.

This occasionally leads to misunderstandings because the term
'architecture' is used to refer to a number of different things in
different contexts: system architecture, component architecture, etc

John MacGregor has written a really useful document proposing a
definition of what we mean by the 'Linux architecture':

https://openjohnmacgregor.github.io/ElisaPages/LinuxArchitecture.html

I think it would be useful to discuss this document, to work out whether
John's proposal requires further refinement, and how it can inform our
various approaches and studies. For example, does this architecture need
to be extended to include other elements that are required to provide a
complete embedded OS based on the Linux kernel?

Would one of the working groups like to 'host' this in a regular
session, or should we schedule a separate Zoom call?
Yes I think we need to go over this document and more specifically we need to
follow up on this email thread
https://lists.elisa.tech/g/safety-architecture/topic/elisa_technical_community/82583176?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,82583176
to come to a common understanding.
Maybe the development process wg is a better forum to discuss this
but I don't mind to host this in the arch wg eventually.
@Elana what is your view on this?

Thanks
Gab


Regards,

Paul



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


Linux architecture

Paul Albertella
 

Hi,

A term that is frequently referenced in both the Development Process and Safety Architecture working groups is 'architecture'.

This occasionally leads to misunderstandings because the term 'architecture' is used to refer to a number of different things in different contexts: system architecture, component architecture, etc

John MacGregor has written a really useful document proposing a definition of what we mean by the 'Linux architecture':

https://openjohnmacgregor.github.io/ElisaPages/LinuxArchitecture.html

I think it would be useful to discuss this document, to work out whether John's proposal requires further refinement, and how it can inform our various approaches and studies. For example, does this architecture need to be extended to include other elements that are required to provide a complete embedded OS based on the Linux kernel?

Would one of the working groups like to 'host' this in a regular session, or should we schedule a separate Zoom call?

Regards,

Paul


ww25 Agenda

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

Hi All

 

For today I’d continue with the in-context safety measures to control the failure modes deriving from the Telltale Kernel Safety Analysis

 

Thanks

Gab

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


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

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

Reminder: ELISA Safety-Architecture Weekly Meeting

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

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

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

View Event

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

ELISA Project is inviting you to a scheduled Zoom meeting.

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

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

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


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

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

Reminder: ELISA Safety-Architecture Weekly Meeting

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

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

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

View Event

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

ELISA Project is inviting you to a scheduled Zoom meeting.

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

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

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


Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name?

John MacGregor
 

Hi Gab,

all in all, this thread is getting long and complicated. There's a lot of good thoughts here and it's hard to pick them out.

As much as I hate to say it, it's probably about time to wrap this up and continue based on some document where we can have an overview.

Comments below.

Cheers

John

On 04/06/2021 11:40, Paoloni, Gabriele wrote:
Hi John
Sorry to come back late on this...for some reason I missed it

-----Original Message-----
From: John MacGregor <open.john.macgregor@...>
Sent: Tuesday, May 25, 2021 1:09 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>; Christopher Temple
<Christopher.Temple@...>; Gurvitz, Eli (Mobileye)
<eli.gurvitz@...>; Peter.Brink@...; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG]
What’s in a name?

Hi Gab,

I dunno. I just published my definition of Linux' architecture. It's a
long way from what's being looked at in the hybrid mode. Even looking
at the ioctl stuff, for me libc (as part of the system environment) and
the system call interface are missing.

For me, "software architectural design" is a bit of an oxymoron, like
"bureaucratic efficiency" or "military intelligence". There's
architecture and then there's design. But, that's probably just my problem.

In an e-mail subsequent to this[1] (and the subsequent correction [2]),
I established that 26262 doesn't really address where software
architecture is defined.

I have to admit, much to my chagrin, that I've been looking at the 2011
version of 26262 rather than the 2018 version, out of habit actually.
In some points, ISO has been clearer in the later version.

Note that that software architecture (in Part 6) is the software
architecture of the _system_, i.e. the item, not necessarily the
software architecture of an element (except, perhaps, an SEooC), or a
component. I'd say that Linux is a component, although some might want
to view it as an element.
In my view the question is "would you consider Linux as a SW Unit (as defined
in ISO26262-1-3.159) ? "
If we look at the term 3.159 above we read:
<<3.159
software unit
atomic level software component (3.157) of the software architecture (3.1)
that can be subjected to stand-alone testing (3.169)>>
In my personal opinion Linux cannot be,usually, seen as an atomic level SW
component, given its complexity and the amount of nominal and safety
requirements allocated to it.
Instead I think that there are multiple levels of SW Archictural design (part6.7)
(starting from a high level system view) where also Linux needs to be
decomposed.
Agree, although, as I said below, at the highest level of System SW Architectural Design, I'd say that the operating system functionality should be expressed in terms of the resources (processes, memory, files, etc.) it manages, as I defined for the Linux architecture:

https://openjohnmacgregor.github.io/ElisaPages/LinuxArchitecture.html

BTW, I ran across this Linux "Map" recently, although I have the vague feeling I've seen it a number of times before. I wouldn't call it an architectural design, but I don't know what I'd call it. At any rate, it gives a "big picture" (or at least an idea of one) of what might be involved in decomposing Linux into separately testable units. At least it might be worth a glance in the WG meeting (p.s. you can also click on the "svg" or "pdf" links).

https://makelinux.github.io/kernel/map/

It's funny how things that go round come round. In the Pseudo-DIA discussion I made the point that the role in the development process played by an off-the-shelf component, and the corresponding development steps, are different from the role of software being developed for use in the system (see the diagramme). The standards only directly address the latter type.

https://openjohnmacgregor.github.io/ElisaPages/PseudoDIA.html#veil-2-were-talking-about-an-operating-system-here


The point here is that there are probably a number of slightly different views on the architecture, design etc. of a software component, the system software and maybe even the system as a whole:
- first of all, there is the view during construction, where the upper levels of the elements to be developed are kept abstract and the lower levels consider more semantic and deployment constraints.
- second, there is the verification view where the upper levels focus on integration aspects. Note that, in the case of an OTS component, some integration testing occurs during the development phase rather than the verification phase.
- third, for components, there is the selection view where the emphasis is on identifying variability in an existing component and refining the view of whether a variant is (still) acceptable as the vision of the system becomes more complete. Also, the component exists already. What's there exists in very explicit detail and must be abstracted rather than being refined. For example, in the Linux map above, the interfaces are expressed in terms of implemented functions. What benefit is there in abstracting them?

This sounds quite academic at the moment, but it might be relevant when we broaden the scope of the hybrid approach.


In the latest hybrid qualification approach presentation[3], you've
discussed the unit design level of the process. Note that according to
7.4.4, the software architectural design stops where the units are
merely identified. 8.4.4, on the other hand, says that the unit design
should specify the units' functional behaviour and design down to the
level necessary for their implementation.

I'd say that, considering that in the item's context, an operating
system function (superficially) is to allow access to and to manage
hardware and software resources , the operating system is a unit and
it's a unit at the system software architecture level.
From my previous experience usually a SW unit is identified as a single
function (in C)


I'd also say that 8.4.4 also comprises all of the operating system's
architecture, design and implementation considerations. That being
said, there's probably no good reason not to apply the software
architecture design requirements (7.*) to a unit's architecture.
From this statement it seems to me that we are aligned from a "common
sense" point of view; i.e. Linux is complex and must be decomposed, hence
7.* applies.


The disambiguation would therefore be "software unit design".

What do you think?
Personally I don’t like it as, as said above, I am used to think of a SW unit
as a single function and plus in the hybrid approach a SW Unit would be
exactly a component qualified following part8.12 (plus additional design
measures as needed and to be discussed); however let's discuss it, I am open
to revisit the terminology if other people think that "SW Unit Design" is the
right terminology to describe what I have called "SW Architectural Design"
previously....
The DIA diagramme that I cited was derived from IEC 61508. In 61508, there's module design and unit testing... and software system design and no software architectural design. And there are other standards...

I can see that for the hybrid approach, decomposing the OS is advantageous. For the approach Paul Albertella is proposing, it's not so clear.

What got me, and probably Paul, started on this thread, is the ambiguity caused by the standards specifying the steps in the development process and naming their work products, but not saying exactly what constitutes the work product.

I've defined the Linux Architecture and I don't think that's what anybody in the Architecture WG would have expected. That being said, I did it independently and was surprised to find similar definitions from other sources after the fact.

Like you said, we probably agree on practical terms. I think that the whole project should have the same vision of both the activities and the work products involved in the various phases of the development process. I might think that this is a subject best addressed by the Ontology... Subgroup? Task Force?, but progress seems a little slow.


Thanks
Gab


To an extent, that resolves the abstraction / granularity conundrum.

But... [4] uses the classification: requirements viewpoint, functional
viewpoint, logical viewpoint and technical viewpoint, which I find to be
intuitive. As I said in [2], I'd have equated them with different
phases in the development process. This doesn't seem to be the case in
26262.

I think that my next exercise will be to find some synthesis between
part 3 and part 6 as well as the viewpoints I've outlined above. I
think it should include an example based on the telltale use case.
Again, it should also avoid 26262 terminology.

Cheers

John


[1] https://lists.elisa.tech/g/safety-architecture/message/499
[2] https://lists.elisa.tech/g/safety-architecture/message/502
[3]
https://drive.google.com/drive/folders/1BoK0PC1yYWuVtT4AuK_VW1T2U2
WwQZTF
[4] https://link.springer.com/book/10.1007/978-3-642-34614-9


On 05/05/2021 11:32, Paoloni, Gabriele wrote:
Hi guys

WRT the discussions that we are having right now about the hybrid
mode I think that the best nomenclature would be "SW Architecture"
or "SW Architecture Design" and to disambiguate we could clearly
refer to:
ISO26262-6.7 - " Software architectural design".

What do you think?

Thanks
Gab

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of John MacGregor
Sent: Wednesday, May 5, 2021 10:30 AM
To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli
(Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG]
What’s in a name?

Hi Chris

The referenced definition is great - in-depth, with a discussion of the
different perceptions of the term "architecture" and then again not too
long. It addresses my concern that the definition must be more than
just nomenclature.

Note the link at the top of the page to the conceptual model. While
it's more or less what I would have expected, I liked the emphasis on
the facts that the model is abstract and that it should focus on
documenting the concerns and decisions driving the architecture.

I hope we can find more such good descriptions for other problematic
terms in the realm of safety and embedded systems.

Cheers

John

On 04/05/2021 23:11, Christopher Temple wrote:
It could be a long discussion.

Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso-
architecture.org/ieee-1471/defining-architecture.html ?

It's quite close to the understandings shared below.

Best regards
Chris



-----Original Message-----
From: devel@... <devel@...> On Behalf Of
Gurvitz,
Eli (Mobileye) via lists.elisa.tech
Sent: Dienstag, 4. Mai 2021 23:01
To: Peter.Brink@...; open.john.macgregor@...; Paul
Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

And I'd like to add that the first 3 types of "architecture"s that Paul lists
below are one and the same, phrased in different forms of technical
English.
So I'd like to suggest that we think of "architecture" as a set of
components,
their properties and the interfaces between them. Together they
comprise a
"system" whose purpose is to implement some specific requirements.

Thanks,
Eli

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Brink,
Peter via lists.elisa.tech
Sent: Tuesday, May 04, 2021 20:16
To: open.john.macgregor@...; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

Which is kind of the point of an architecture 😊

-----Original Message-----
From: devel@... <devel@...> On Behalf Of John
MacGregor via lists.elisa.tech
Sent: Tuesday, May 4, 2021 10:14 AM
To: Brink, Peter <Peter.Brink@...>; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

Mea Culpa,

I've always been guilty of seeing the forest and forgetting a couple of
trees...

On 04/05/2021 19:12, Brink, Peter wrote:
Not a botanist indeed, John. You left off the calyx and the corolla in
your
flower description.

-----Original Message-----
From: devel@... <devel@...> On Behalf Of
John MacGregor via lists.elisa.tech
Sent: Tuesday, May 4, 2021 9:54 AM
To: Paul Albertella <paul.albertella@...>;
devel@...; safety-architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

Hi Paul

Great start. I'd have started with Shakespeare too!

The point for me, as I said in the last Sync Telco, was the issue is not just
the nomenclature. It's understanding what comprises each of the
concepts
and what role in the development process they serve. An architecture
differs from a design which differs from an implementation at least in the
level of abstraction and granularity.

I'll probably have to expand on the idea in the future (and I don't have
time now). But for now, I'll give a small example:

The architecture of a rose is probably aligned with the attributes that
make it recognisable:
- a stem with thorns, branches and leaves
- a flower with a certain distinctive petal form
- a distinctive smell that may or may not repel enemies

The design of a rose could
- refine the shape and effects of the thorns, branches, leaves, petals,
to support structural stability, environmental robustness, etc.
- address nourishment and reproduction issues, adding roots, pistils
and stamen

The implementation of a rose might detail the different breeds of
roses.... Hey, even botanists get it :-) [1]

I'm not a botanist, and off the top of my head, I'm not sure whether
the
non-functional aspects (nourishment and reproduction) aren't
architectural
concerns, but I'm using the example as a light-hearted example of the
differences in abstraction and granularity.

Cheers

John

BTW, the _Name_ of the Rose is a vaastly different kettle of fish.

[1]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour
nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl
e
-
p236.xml&amp;data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4
93608
0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755
74529
14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
V2luMzIiL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=twe4Zl9o6LJSxw5r
MdDA3wv
ionay%2BhN%2Fs7zGnrSK0dc%3D&amp;reserved=0


On 04/05/2021 18:19, Paul Albertella wrote:
Hi,

What’s in a name? that which we call a rose By any other name would
smell as sweet
--- W Shakespeare "Romeo and Juliet"

As John MacGregor commented on today's Safety Architecture call,
our
discussions are occasionally marred by misunderstandings arising from
the use of terminology that *seems* to be unambiguous, but actually
means different things to different people, or in different contexts.

I believe that we can help to address this by compiling a common
'lexicon' of terms and definitions that we can use in ELISA
discussions and publications, relating these to specific domains or
contexts where necessary.

The term 'architecture', which John picked on today, for example, has
at least four distinct meanings in the context of ELISA. Here are are
some definitions that may be helpful:

1) Software architecture

The Software Engineering Body of Knowledge [1] includes
architecture
under the general heading of design, noting that "Architectural
design describes how software is organized into components", while
"Detailed design describes the desired behavior of these
components."

It adds that a software architecture can be strictly defined as "the
set of structures needed to reason about the system, which comprise
software elements, relations among them, and properties of both”,
but
notes that it can be further subdivided into 'views' (physical,
logical, process, development), focusing on different aspects of the
system (distribution, functionality, concurrency, implementation).

2) System architecture

This has a very similar meaning to the term in the software context,
but extends the scope to include the hardware components of a
system.

IEC 61508 defines architecture as a "specific configuration of
hardware and software elements in a system". ISO 26262 [3] applies
the term to both hardware/software combinations and pure software
elements, defining it as a "representation of the structure of the
item or element that allows identification of building blocks, their
boundaries and interfaces, and includes the allocation of
requirements to these building blocks".

3) Safety architecture

This is more or less the same as a system architecture, but focussing
only on safety.

ISO 26262 [3] defines it as the "set of elements and their
interaction to fulfil the safety requirements", where an element may
be a system, component (hardware or software), hardware part, or
software unit.

4) CPU architecture

The term 'architecture' in discussions about the Linux kernel
frequently has a different meaning again, referring to the underlying
architecture of the processor (x86, ARM, MIPs, etc) in a target
system, and the associated 'architecture-specific' components of the
kernel.

Regards,

Paul


[1]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w
.computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware-
engineerin
g&amp;data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802
08d90
f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914
3488
79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTi
I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NpmQyjx9wYhQDEzy8z5
s98f4p7i
nt%2Fr5DqGlDlkTWAQ%3D&amp;reserved=0
[2]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc
hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&amp;data=04%7C01%7CPe
ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc
d4
5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C
TWFpbGZs
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3
D%7C1000&amp;sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180%
3D&amp
;reserved=0 [3]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w
.iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-
1%3Aed-
2%3Av1%3Ae
n&amp;data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802
08d90
f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914
3488
79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTi
I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=4XCPMIOfGI1ZLwmLRU
wVf4fjET7
FtlQZYxGd%2FESASoU%3D&amp;reserved=0














This e-mail may contain privileged or confidential information. If you
are
not the intended recipient: (1) you may not disclose, use, distribute, copy
or
rely upon this message or attachment(s); and (2) please notify the sender
by
reply e-mail, and then delete this message and its attachment(s).
Underwriters Laboratories Inc. and its affiliates disclaim all liability for any
errors, omissions, corruption or virus in this message or any attachments.





This e-mail may contain privileged or confidential information. If you are
not the intended recipient: (1) you may not disclose, use, distribute, copy
or
rely upon this message or attachment(s); and (2) please notify the sender
by
reply e-mail, and then delete this message and its attachment(s).
Underwriters Laboratories Inc. and its affiliates disclaim all liability for any
errors, omissions, corruption or virus in this message or any attachments.





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

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





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





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

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


ww25 Agenda

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

Hi All

 

Tomorrow we’ll revisit the telltale safety analysis (https://docs.google.com/spreadsheets/d/1-qfyfWJasfXc3IES7RUtfnnxkVsKkOkl/edit#gid=459221992)

tailored to the telltale context. I have added CoUs and application level safety mechanisms to mitigate the dangerous failure modes that have been
elicited so far.

 

Thanks

Gab

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

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


Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name?

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

Hi John

Sorry to come back late on this...for some reason I missed it

-----Original Message-----
From: John MacGregor <open.john.macgregor@...>
Sent: Tuesday, May 25, 2021 1:09 PM
To: Paoloni, Gabriele <gabriele.paoloni@...>; Christopher Temple
<Christopher.Temple@...>; Gurvitz, Eli (Mobileye)
<eli.gurvitz@...>; Peter.Brink@...; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG]
What’s in a name?

Hi Gab,

I dunno. I just published my definition of Linux' architecture. It's a
long way from what's being looked at in the hybrid mode. Even looking
at the ioctl stuff, for me libc (as part of the system environment) and
the system call interface are missing.

For me, "software architectural design" is a bit of an oxymoron, like
"bureaucratic efficiency" or "military intelligence". There's
architecture and then there's design. But, that's probably just my problem.

In an e-mail subsequent to this[1] (and the subsequent correction [2]),
I established that 26262 doesn't really address where software
architecture is defined.

I have to admit, much to my chagrin, that I've been looking at the 2011
version of 26262 rather than the 2018 version, out of habit actually.
In some points, ISO has been clearer in the later version.

Note that that software architecture (in Part 6) is the software
architecture of the _system_, i.e. the item, not necessarily the
software architecture of an element (except, perhaps, an SEooC), or a
component. I'd say that Linux is a component, although some might want
to view it as an element.
In my view the question is "would you consider Linux as a SW Unit (as defined
in ISO26262-1-3.159) ? "

If we look at the term 3.159 above we read:
<<3.159
software unit
atomic level software component (3.157) of the software architecture (3.1)
that can be subjected to stand-alone testing (3.169)>>

In my personal opinion Linux cannot be,usually, seen as an atomic level SW
component, given its complexity and the amount of nominal and safety
requirements allocated to it.
Instead I think that there are multiple levels of SW Archictural design (part6.7)
(starting from a high level system view) where also Linux needs to be
decomposed.


In the latest hybrid qualification approach presentation[3], you've
discussed the unit design level of the process. Note that according to
7.4.4, the software architectural design stops where the units are
merely identified. 8.4.4, on the other hand, says that the unit design
should specify the units' functional behaviour and design down to the
level necessary for their implementation.

I'd say that, considering that in the item's context, an operating
system function (superficially) is to allow access to and to manage
hardware and software resources , the operating system is a unit and
it's a unit at the system software architecture level.
From my previous experience usually a SW unit is identified as a single
function (in C)


I'd also say that 8.4.4 also comprises all of the operating system's
architecture, design and implementation considerations. That being
said, there's probably no good reason not to apply the software
architecture design requirements (7.*) to a unit's architecture.
From this statement it seems to me that we are aligned from a "common
sense" point of view; i.e. Linux is complex and must be decomposed, hence
7.* applies.


The disambiguation would therefore be "software unit design".

What do you think?
Personally I don’t like it as, as said above, I am used to think of a SW unit
as a single function and plus in the hybrid approach a SW Unit would be
exactly a component qualified following part8.12 (plus additional design
measures as needed and to be discussed); however let's discuss it, I am open
to revisit the terminology if other people think that "SW Unit Design" is the
right terminology to describe what I have called "SW Architectural Design"
previously....

Thanks
Gab


To an extent, that resolves the abstraction / granularity conundrum.

But... [4] uses the classification: requirements viewpoint, functional
viewpoint, logical viewpoint and technical viewpoint, which I find to be
intuitive. As I said in [2], I'd have equated them with different
phases in the development process. This doesn't seem to be the case in
26262.

I think that my next exercise will be to find some synthesis between
part 3 and part 6 as well as the viewpoints I've outlined above. I
think it should include an example based on the telltale use case.
Again, it should also avoid 26262 terminology.

Cheers

John


[1] https://lists.elisa.tech/g/safety-architecture/message/499
[2] https://lists.elisa.tech/g/safety-architecture/message/502
[3]
https://drive.google.com/drive/folders/1BoK0PC1yYWuVtT4AuK_VW1T2U2
WwQZTF
[4] https://link.springer.com/book/10.1007/978-3-642-34614-9


On 05/05/2021 11:32, Paoloni, Gabriele wrote:
Hi guys

WRT the discussions that we are having right now about the hybrid
mode I think that the best nomenclature would be "SW Architecture"
or "SW Architecture Design" and to disambiguate we could clearly
refer to:
ISO26262-6.7 - " Software architectural design".

What do you think?

Thanks
Gab

-----Original Message-----
From: safety-architecture@... <safety-
architecture@...> On Behalf Of John MacGregor
Sent: Wednesday, May 5, 2021 10:30 AM
To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli
(Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG]
What’s in a name?

Hi Chris

The referenced definition is great - in-depth, with a discussion of the
different perceptions of the term "architecture" and then again not too
long. It addresses my concern that the definition must be more than
just nomenclature.

Note the link at the top of the page to the conceptual model. While
it's more or less what I would have expected, I liked the emphasis on
the facts that the model is abstract and that it should focus on
documenting the concerns and decisions driving the architecture.

I hope we can find more such good descriptions for other problematic
terms in the realm of safety and embedded systems.

Cheers

John

On 04/05/2021 23:11, Christopher Temple wrote:
It could be a long discussion.

Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso-
architecture.org/ieee-1471/defining-architecture.html ?

It's quite close to the understandings shared below.

Best regards
Chris



-----Original Message-----
From: devel@... <devel@...> On Behalf Of
Gurvitz,
Eli (Mobileye) via lists.elisa.tech
Sent: Dienstag, 4. Mai 2021 23:01
To: Peter.Brink@...; open.john.macgregor@...; Paul
Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

And I'd like to add that the first 3 types of "architecture"s that Paul lists
below are one and the same, phrased in different forms of technical
English.
So I'd like to suggest that we think of "architecture" as a set of
components,
their properties and the interfaces between them. Together they
comprise a
"system" whose purpose is to implement some specific requirements.

Thanks,
Eli

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Brink,
Peter via lists.elisa.tech
Sent: Tuesday, May 04, 2021 20:16
To: open.john.macgregor@...; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

Which is kind of the point of an architecture 😊

-----Original Message-----
From: devel@... <devel@...> On Behalf Of John
MacGregor via lists.elisa.tech
Sent: Tuesday, May 4, 2021 10:14 AM
To: Brink, Peter <Peter.Brink@...>; Paul Albertella
<paul.albertella@...>; devel@...; safety-
architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

Mea Culpa,

I've always been guilty of seeing the forest and forgetting a couple of
trees...

On 04/05/2021 19:12, Brink, Peter wrote:
Not a botanist indeed, John. You left off the calyx and the corolla in
your
flower description.

-----Original Message-----
From: devel@... <devel@...> On Behalf Of
John MacGregor via lists.elisa.tech
Sent: Tuesday, May 4, 2021 9:54 AM
To: Paul Albertella <paul.albertella@...>;
devel@...; safety-architecture@...
Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture
WG]
What’s in a name?

Hi Paul

Great start. I'd have started with Shakespeare too!

The point for me, as I said in the last Sync Telco, was the issue is not just
the nomenclature. It's understanding what comprises each of the
concepts
and what role in the development process they serve. An architecture
differs from a design which differs from an implementation at least in the
level of abstraction and granularity.

I'll probably have to expand on the idea in the future (and I don't have
time now). But for now, I'll give a small example:

The architecture of a rose is probably aligned with the attributes that
make it recognisable:
- a stem with thorns, branches and leaves
- a flower with a certain distinctive petal form
- a distinctive smell that may or may not repel enemies

The design of a rose could
- refine the shape and effects of the thorns, branches, leaves, petals,
to support structural stability, environmental robustness, etc.
- address nourishment and reproduction issues, adding roots, pistils
and stamen

The implementation of a rose might detail the different breeds of
roses.... Hey, even botanists get it :-) [1]

I'm not a botanist, and off the top of my head, I'm not sure whether
the
non-functional aspects (nourishment and reproduction) aren't
architectural
concerns, but I'm using the example as a light-hearted example of the
differences in abstraction and granularity.

Cheers

John

BTW, the _Name_ of the Rose is a vaastly different kettle of fish.

[1]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour
nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl
e
-
p236.xml&amp;data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4
93608
0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755
74529
14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
V2luMzIiL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=twe4Zl9o6LJSxw5r
MdDA3wv
ionay%2BhN%2Fs7zGnrSK0dc%3D&amp;reserved=0


On 04/05/2021 18:19, Paul Albertella wrote:
Hi,

What’s in a name? that which we call a rose By any other name would
smell as sweet
--- W Shakespeare "Romeo and Juliet"

As John MacGregor commented on today's Safety Architecture call,
our
discussions are occasionally marred by misunderstandings arising from
the use of terminology that *seems* to be unambiguous, but actually
means different things to different people, or in different contexts.

I believe that we can help to address this by compiling a common
'lexicon' of terms and definitions that we can use in ELISA
discussions and publications, relating these to specific domains or
contexts where necessary.

The term 'architecture', which John picked on today, for example, has
at least four distinct meanings in the context of ELISA. Here are are
some definitions that may be helpful:

1) Software architecture

The Software Engineering Body of Knowledge [1] includes
architecture
under the general heading of design, noting that "Architectural
design describes how software is organized into components", while
"Detailed design describes the desired behavior of these
components."

It adds that a software architecture can be strictly defined as "the
set of structures needed to reason about the system, which comprise
software elements, relations among them, and properties of both”,
but
notes that it can be further subdivided into 'views' (physical,
logical, process, development), focusing on different aspects of the
system (distribution, functionality, concurrency, implementation).

2) System architecture

This has a very similar meaning to the term in the software context,
but extends the scope to include the hardware components of a
system.

IEC 61508 defines architecture as a "specific configuration of
hardware and software elements in a system". ISO 26262 [3] applies
the term to both hardware/software combinations and pure software
elements, defining it as a "representation of the structure of the
item or element that allows identification of building blocks, their
boundaries and interfaces, and includes the allocation of
requirements to these building blocks".

3) Safety architecture

This is more or less the same as a system architecture, but focussing
only on safety.

ISO 26262 [3] defines it as the "set of elements and their
interaction to fulfil the safety requirements", where an element may
be a system, component (hardware or software), hardware part, or
software unit.

4) CPU architecture

The term 'architecture' in discussions about the Linux kernel
frequently has a different meaning again, referring to the underlying
architecture of the processor (x86, ARM, MIPs, etc) in a target
system, and the associated 'architecture-specific' components of the
kernel.

Regards,

Paul


[1]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w
.computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware-
engineerin
g&amp;data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802
08d90
f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914
3488
79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTi
I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NpmQyjx9wYhQDEzy8z5
s98f4p7i
nt%2Fr5DqGlDlkTWAQ%3D&amp;reserved=0
[2]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc
hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&amp;data=04%7C01%7CPe
ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc
d4
5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C
TWFpbGZs
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3
D%7C1000&amp;sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180%
3D&amp
;reserved=0 [3]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w
.iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-
1%3Aed-
2%3Av1%3Ae
n&amp;data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802
08d90
f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914
3488
79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTi
I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=4XCPMIOfGI1ZLwmLRU
wVf4fjET7
FtlQZYxGd%2FESASoU%3D&amp;reserved=0














This e-mail may contain privileged or confidential information. If you
are
not the intended recipient: (1) you may not disclose, use, distribute, copy
or
rely upon this message or attachment(s); and (2) please notify the sender
by
reply e-mail, and then delete this message and its attachment(s).
Underwriters Laboratories Inc. and its affiliates disclaim all liability for any
errors, omissions, corruption or virus in this message or any attachments.





This e-mail may contain privileged or confidential information. If you are
not the intended recipient: (1) you may not disclose, use, distribute, copy
or
rely upon this message or attachment(s); and (2) please notify the sender
by
reply e-mail, and then delete this message and its attachment(s).
Underwriters Laboratories Inc. and its affiliates disclaim all liability for any
errors, omissions, corruption or virus in this message or any attachments.





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

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





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






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

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


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

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

Cancelled: ELISA Safety-Architecture Weekly Meeting

This event has been cancelled.

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

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

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

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

ELISA Project is inviting you to a scheduled Zoom meeting.

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

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

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


Re: anybody wishing to chair next week?

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

Hi All

 

Following the email below I didn’t get any volunteer to chair, so the meeting for today is cancelled.

 

Regards

Gab

 

From: Paoloni, Gabriele
Sent: Friday, May 28, 2021 2:20 PM
To: safety-architecture@...
Subject: anybody wishing to chair next week?

 

Hi All

 

I just realized that I have booked vacation for next week from Mon to Wed inclusive. So I will not be able to chair the Safety Arch WG meeting.

 

Please let me know if anybody want to chair, otherwise we’ll cancel the meeting.

 

Thanks

Gab

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


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

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

Reminder: ELISA Safety-Architecture Weekly Meeting

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

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

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

View Event

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

ELISA Project is inviting you to a scheduled Zoom meeting.

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

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

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


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

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


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

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.


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

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.

161 - 180 of 719