Hi John,

For this e-mail, I've enhanced the general V-Model with safety activities /
processes. This means that the diagramme covers the general development
lifecycle as well as the safety lifecycle. The standards are not so clear about
that. Rather than having a separate, parallel V for the safety lifecycle, I've
inserted orange "safety" boxes in the nodes representing each development
phase.

In the case of ISO 26262, there is the famous illustration of the 3 Vs
superimposed over the overview of the standards series (Figure 1 in every
standard) and Figures 2 & 3 in Part 4 which replace the hardware and software
Vs with boxes. The enclosed illustration seems generally compatible.

It's not generally included in the V-Model, but in the context of safety-critical
systems, there should be backwards traceability between the requirements
and the work products that implement them.

Two points are immediately noticeable:
1) The standards' requirements mostly only cover the tip of the iceberg
of system development activities. (Well, I have to admit I made the orange
boxes small so that they wouldn't interfere with the phase titles, however (-: ).
2) There is an overlap between safety functionality and operating
system functionality.

The picture does not tell me much and provides so many different ways of interpretation.
Everyone would agree with the top-level picture, but it is the details below that actually create the added knowledge and consensus.

Those turquoise boxes represent the development process all application,
middleware and, yes, operating system elements in the safety-critical system.
The system itself is composed of (using a somewhat arbitrary mixture of
terminology):
1) newly-developed safety elements
2) newly-developed non-safety elements
3) pre-existing safety elements that have been used in a similar
domain
4) pre-existing safety elements that have been used in another context
(at least from the 26262 perspective), i.e. another instance of the same
product class
5) pre-existing non-safety elements
6) pre-existing safety components (hardware and software)
7) pre-existing non-safety components (hardware and software) each
of which may have a different certification or qualification route as well as
different generic development processes. The difference between elements
and components seem nebulous to me and I'd rather call pre-existing things
"off-the-shelf", whereby one might have to differentiate whose shelf they
come from.

From the previous e-mail (which admittedly considered only non-safety-
critical systems), a Linux that is currently being selected for use in an
embedded system would belong to category 7 and that is the focus here. It
may soon be the case that safety-critical applications will use Linux. There
may come a time, where safety functionality has been brought upstream to
the Kernel, but these are now not quite the case.

The safety-critical system development process starts by defining the safety-
critical system and the environment (context) within which it operates. A
hazard and risk analysis is then performed to develop the safety requirements
on the system and a corresponding functional safety concept. A technical
safety concept is developed in the system architecture phase, which ultimately
results in safety requirements on the software architecture, and therefore on
the operating system.

At this point the requirements on the operating system should be functional
requirements, for safety mechanisms or safety functions, and / or
requirements on the qualities of those functions (response time, resource
consumption, etc.). Safety functionality, or mechanisms, include such things
as monitoring, periodic testing, diagnostic and logging functionalities,
tolerance mechanisms for residual design faults in the hardware,
environmental stresses, operator mistakes, residual software design faults,
data communication errors and overload situations; things that may already
exist in the operating system in some form. Refer to 61508-3 7.2.2.10 a) for a
better list.

In other words, the safety-related requirements on the operating system
should already be functional or quality requirements that should comparable
to other requirements on the operating system.

First, you introduce safety requirement, functional requirement and quality requirement as terms, and I not sure about your definition of a safety requirement.

I will try to give a definition of "two classes of requirements", requirement type A and requirement type B.

Requirement type A:
A statement about an observable functional behavior of software with evidences that support that this stated behavior holds under all circumstances.

Requirement type B:
A statement about the absence of an observable functional behavior of software with an explanation that the existence of the functional behavior would lead to an unintended system property.

Which of those two are safety requirements (or actually none of those two or both)? How would you name and classify those?

I try to avoid the word safety requirement, because it often mixes requirement type A and type B (in various flavors) and resolution always seems difficult... There are too many interpretations of the word safety requirement and it is used to often without proper definition or mismatching definitions in communication, especially when requirements and elements are considered without any reference to a clearly-defined system context.

The point here is that Linux has always (up to now) been developed as
functionality. It may be possible to isolate the safety-related parts of that
functionality and, as part of the systems engineering part of the development
process, attach quality requirements to them and validate that the
requirements have been achieved. For me, this would be the development
interface for the DIA.

John, In your understanding:

Is the development process group working on building blocks/basis/methods/basic information that can be used to attach and validate quality requirements to a subset of functionality that was previously developed?

The answer is just to ensure that I can map your explanation to other activities ongoing, or if you have something different in mind.

Enjoy your vacation, I will be busy for the rest of this week, and I need to catch up with writing down the previous insights of the thread...


Lukas