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://www.computer.org/education/bodies-of-knowledge/software-engineering
[2] https://archive.org/details/gov.in.is.iec.61508.4.1998
[3] https://www.iso.org/obp/ui/#iso:std:iso:26262:-1:ed-2:v1:en

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://journals.ashs.org/hortsci/view/journals/hortsci/54/2/article-p236.xml