Specifications

The primary focus of the arguments in a safety case is to demonstrate that the behaviour (including other properties/attributes) of the functional system in the operational environment has been predicted, and that this behaviour is acceptable according to the applicable safety risk criteria. This has implications for the expected content of specifications that exceed general engineering practice. The format in the book therefore is structured as if these 'perfect' specifications exist, and then guidance is provided on how the normal shortfalls might be addressed at the points where they arise. 

The rest of this page discusses this in more detail.

For any part of the functional system (which the book terms a POSS - see Glossary), a specification should be a declaration of all its behaviour and properties exhibited in all operational and fall-back modes, in its predicted local environment. This includes all potential behaviour, including; all behaviour induced by failures, all behaviour identified as potentially unsafe by safety analysis, and all behaviour potentially induced by cyber security threats.

Specifications contain individual specification elements that each define an individual behaviour/‌property, which was determined from test evidence or analysis, not the behaviour that may have been originally intended or specified as a requirement. The elements together address all behaviour/‌properties of the part, including those which match the safety requirements assigned to the POSS.

To provide suitable evidence of behaviour to support the safety case, each element in a specification that represents a safety-related behaviour (i.e. a safety requirement assigned to the POSS) is required to be stated with its associated verified integrity and confidence. Specific verification activities to support the safety case may have been needed to generate the necessary integrity and confidence information, if it did not initially exist.

Common practice would create a context-free specification for a POSS, rather than one that is specific to its predicted operational environment.  

Consequently, the following shortfalls are to be expected:

a)   non-normal behaviours/‌properties may be identified as the result of specific analyses or tests (e.g. FMEA, safety requirement identification/‌apportionment), and not subsequently consolidated into a single specification for the POSS

b)   the specification may not be instantiated for the predicted operational environment, but stated for a generic environment, leaving safety analysts to instantiate the behaviour/‌properties

c)   the behavioural or property elements may not have (individually or even collectively) associated statements of the integrity (probability that the behaviour is delivered), leaving this aspect to be addressed in some other way. This is a complex subject where practice and theory are slowly advancing.

d)   similarly, to c), the confidence to which the statement of integrity is known is commonly not addressed.  This is an even more complex subject that is poorly developed, along with the related problem of defining how much confidence is required.

Many industry sectors use the concept of Safety Integrity Levels (SILs) or Design Assurance Levels (DALs) to address integrity and confidence.

It is also uncommon for the behaviours/‌properties in specifications to be composed all the way up the functional system hierarchy to create the service level specifications. Composition of behaviour in specifications, if done at all, usually terminates at an intermediate level (e.g. that of major subsystems), so leaving it to the safety analysis models to represent the behaviour at upper-levels.

Additionally, some projects take the requirements specification to represent the specification of the behaviour of the finalised system. In these cases requirement specifications have been decomposed until implementable components were identified and then tested to ensure that they satisfy and do not violate the requirements. However, any additional, unrequired behaviour exhibited was not added into the specifications i.e. they are incomplete specifications of behaviour. Consequently, the Safety Case Report would need to explain the project's approach to addressing additional unrequired behaviour.

The format provides a section for the project’s approach to these issues to be described. The book also indicates where other sections need to address these issues, primarily in the areas of safety criteria, safety requirements, POSS specifications and predicted safety performance to meet safety criteria.