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

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

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

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

Hi Paul

Thanks ofr raising this

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

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

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

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

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.

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

Hi John

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

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

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

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

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

Hi Lukas