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

John MacGregor

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
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.
BTW, the _Name_ of the Rose is a vaastly different kettle of fish.
On 04/05/2021 18:19, Paul Albertella wrote:

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

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.




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.

Join to automatically receive all group messages.