6.10.6 Safe integration measures

What this heading covers

Most products are part of a larger system, and the safety question changes at the boundary. Integration can add a failure path, hide a warning, or turn a local safe state into a system hazard. The measure should name the other systems, the interfaces and the shared safety functions, and it should test the combined behaviour, not only each product alone. The scenario set should include a failure in a neighbouring system and a delay in a shared signal.

Record position: family 40 of 40 in clause 6, under 6.10 Safety, which carries 5 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.10.6 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the integration scenarios that met the combined safety criteria as the numerator over the scenarios tested. Record the other systems and the interfaces, and the effect of a neighbouring failure. A combined hazard analysis is the population for the measure.

What to put in place before publication

1. Map the other systems and the shared safety functions first.
2. Inject a failure in a neighbouring system, not only in this one.

Evidence to keep

Two questions to ask

• Which other systems and shared safety functions are in the integration map?
• Was a neighbouring failure injected, or only a local one?

Where teams usually fall short

• Each product tested alone and the combination declared safe.

What the number cannot tell you

It cannot tell you whether the system is safe. It tells you whether the integration scenarios you defined stayed within their criteria.

What happens next

That completes the forty families. The annex pages explain how the measures are supported: use, elements, data types, lifecycle and uncertainty.