Safety Contracts

The concept of a software contract was first introduced in section 2.6.1. That section described various software contract notations which have been created to assist in the predictable integration of software components at the application level. A contract contains a series of constraints on properties of the components. The constraints must evaluate to true at a specified time during the applications execution if the system is to behave as desired.

The previous chapter discovered that many derived requirements to prevent failures depended on an implicit rely/guarantee relationship between the OS and application being upheld, i.e. a contract relationship. This section describes the expected content for a safety contract, using the software contract concepts but adapting them to express the required information in an OS/application contract.

5.2.1. Definition of a safety contract

The Oxford English Dictionary [110] definition of a contract is:

Contract: A mutual agreement between two or more parties that something shall be done or forborne by one or both

A contract typically contains the conditions applying to a transaction between a client (which requires a service) and a supplier (who provides that service). The supplier will guarantee the

specified service to the client only if the client meets the supplier’s conditions. The following working definition is given for a safety contract⁷:

Working Definition 4. Safety Contract – a set of one or more constraints which must be upheld by software and hardware components in order to meet a derived requirement

The purpose of defining a safety contract is to ensure that an OS and applications developed separately behave in the manner needed to prevent a failure once they are integrated.

The analysis in the last chapter presented derived requirements designed to protect against potential failures. Since the DRs describe functionality that will be required in the system, this chapter uses these as a basis upon which a safety contract can be created. A contract describes in detail how the DR functionality is provided and any conditions placed on other components in order to ensure that functionality is implemented. This is similar to the design by contract concept where a supplier offers guarantees (post-conditions), but only if a client meets a number of pre-conditions. However, in a safety contract there may be multiple suppliers, and the types of conditions relate to different properties than those typically found in software contracts.

The client using a software safety contract is the component which needs to be protected against the failures which the derived requirement prevents (typically an application). The suppliers will be the components which support the derived requirement. Note that the client may also be a supplier. For example, one failure identified during the MSL analysis was that data could be corrupted during copying if the MSL performed a context switch too early. In order to allow the application to detect this, a derived requirement was placed on the OSL to flag the copy as failed until the operation had completed. Therefore the application is the client (since they wish to know if the data they are receiving is valid) but is also a supplier since although the OSL supplies the mechanism, the application must check the flag.

Typically a software contract (e.g. in Eiffel or OCL (see sections 2.6.1.1 and 2.6.1.2)) only exists between two components at any one time. For example, software call A may be called by both component B and C, but the pre and post conditions surrounding A will apply to B and C only as they individually call A. However, a safety contract may contain a set of constraints on multiple software components, all of which must be upheld at the same time to ensure system safety. This would be similar to the synchronisation contracts described by Beugnard [88] (see section 2.6.1.3).

For example, the APEX analysis derived a possible strategy for arguing that common mode failures

7 Only the construction of contracts for single layer OSs has been examined in this thesis

were sufficiently unlikely by ensuring that none of the modules contained the same set of application partitions. This constrained the location of multiple different partitions executing at the same time, and the constraints should be true throughout their execution.

Another difference is that the contracts described in section 2.6 applied to components directly interacting via a function call, but no such link exists in a safety contract. For example, the APEX and MSL case studies suggested that memory partitioning should be used to protect one applications data from another misbehaving application. This feature will not be accessed via a function call but still must be enforced if the failure is to be prevented.

Derived Safety Requirement

Safety Contract

Constraints

Properties Supported By

Consists Of

Apply To Validation/

Subscribe Time Enforced At

Figure 26 Contract Definitions Relationships

5.2.2. Contract Structure

Figure 26 shows the content and relationships between items within a safety contract. This is an extension of the core contract concepts shown in Figure 10. At the bottom of the figure are properties. Properties belong to software components and include data (e.g. variables), the components behaviour (e.g. when actions occur) and also software architecture and configuration (e.g. where components are located). These properties will need to be constrained in some way if

the software is to behave in an acceptably safe way. A software safety contract contains a collection of constraints, all of which must be met by implemented software components in order to support a derived requirement and must hold at a designated validation time.

5.2.3. Constraints

This thesis uses the following working definition for a constraint within a safety contract:

Working Definition 5. Constraint – a limitation on the permitted value or manipulation of properties or components

The simplest form of constraint is one which can be upheld by a single component without reliance on another component. This is called an internal constraint within this thesis. For example, the HUD application will need to calculate data to a certain degree of accuracy for display to the pilot.

The calculation algorithm is local to the application (Figure 27).

A contract may need to be enforced by multiple internal constraints. For example, the configuration constraint derived on the APEX system uses dissimilar mixes of partitions on a module to reduce the risk of common mode failure. Assessing whether this constraint holds involves a check on all the applications locations, but there is no direct interaction between them (Figure 28)

DR – HUD application calculates data

to 5 decimal places

Hazardous state – pilot unable to accurately

determine height Value Failure

– low resolution

data

Prevents Can lead to

Supplied by

HUD Application HUD System

Req uired by

Affects

Figure 27 Simple Internal Constraint Example

ARG 1 –

Figure 28 Multiple Internal Constraints Example

However, typically a constraint will depend on more complex interactions between components.

This is called an interaction constraint within this thesis. For example, a late failure for an application executing can lead to incorrect data being displayed to the pilot. APEX provides a timing watchdog which allows a late failure to be detected, but the timing watchdog parameter is dependent on a specific configuration by the applications and also hardware support from the processor. This is shown in Figure 29.

DR – Timing displayed to pilot as no updated data available

Figure 29 Complex Interaction Constraint Example

The analyses in the previous chapter found no derived requirements which could be upheld purely by internal constraints applied to the OS as the OS was always dependent on either the hardware to support the constraint (e.g. the use of dual memory to prevent memory corruption) or an application

to provide parameters on how the constraint should hold (e.g. the length of time a process should be suspended before the timing watchdog was triggered).

A safety contract must contain all of the relevant constraints if it is to adequately describe how a derived requirement is upheld. However, some of the derived requirements identified in the previous chapter were from context free analyses and hence it was not possible to determine application parameters for constraints. Therefore a contract derived from context free analysis is only a template which will need to be refined and instantiated once specific application details are known. A series of development levels for safety contracts, described in section 5.4.1, reflect this.

5.2.4. Constraint Verification

Sections 2.1 and 2.2 noted that for safety critical systems there is no such thing as absolute safety.

Instead a level of “acceptable” safety in terms of tolerances to hazardous events needs to be argued and then verified. Typically, safety requirements are derived which, although often described using informal language, can be demonstrated by quantifiable methods (e.g. in terms of failure rates, or acceptable behaviour). This is essential as without means of verification there will be no evidence to support an argument that the system is acceptably safe. Therefore the constraints within a safety contract must be verifiable. Constraints are expressed using natural language within this thesis, nonetheless care is taken to ensure that the constraints are expressed as proposition statements which are either true or false. Hence, the adherence (or otherwise) to the constraint can be demonstrated.

5.2.5. Properties

The types of properties which are constrained within a contract will depend on the type of component the constraint is applied to (see section 2.6.1.4 for more discussion on properties in contracts). For a piece of software, a constraint will apply to properties such as values of variables or execution times. For physical components, constraints may apply to properties such as tolerances to pressure. This thesis applies constraints to three groups of properties, which have been found to be relevant to applications and OSs via case study. The property groups have been developed from Purwantoro’s adaptation of the ARP 4761 safety lifecycle [26] which was published in [111]⁸.

8 The thesis author co-authored the paper, which contained the first published version of the contract concept (as created by this author) as well as a description of Purwantoro’s work.

Purwantoro extended the lifecycle to support the development of an IMA Platform and Avionics Applications independently. He suggested that four levels of “consolidating interactions” would be required in order to integrate an IMA platform and an IMA application. These levels followed the same pattern used for the system development lifecycle, but at each level details pertinent to the control of applications and computer resource provision were examined and verified.

Table 10 List of Consolidating Interaction Activities from Purwantoro [111]

Level Name of Consolidating Activity

Data Direction of Flow

API requirements, IMA constraints,

IMA functions and services

API requirements Output of IMA FHA

List of IMA functions and services applications in terms of IMA functions needed to meet aircraft functions

Application to IMA

IMA architectural constraints Constraints or conditions related to IMA architecture services to be called) in order to meet the safety requirements of IMA

Application to IMA

3 IMA behavioural constraints Relates to predicted behaviour of IMA during operation, e.g.

configuration partition mapping fault handling or

provision for health monitoring

IMA to Application

IMA behavioural constraints

The first level of integration suggested is requirements consolidation. Essentially this is a process for ensuring the IMA platform requirements will be sufficient to support the applications requirements. The second level is architectural consolidation, ensuring that applications are developed to structural constraints such as partitions and processes. The third level is behavioural consolidation, which relates to how the platform is configured and fault handling i.e. how the architectural items are manipulated. The final level is performance constraint consolidation, such as ensuring a process’ required execution time could be met. A summary of the levels and consolidating activities is shown in Table 10.

The first level, requirements, matches the DRs which are produced from the failure analysis. This thesis uses the lower three levels as a basis both for the types of properties which are constrained within a safety contract, and also the method by which the contract is derived. The behavioural property set has been extended from Purwantoro’s original description to include constraints on variables (as used in design by contract). Identification of constraints at the performance level has been limited to syntactic constraints, such as the amount of memory available or the size of processes. In fact an exhaustive list of properties for every level is not provided in this thesis, however each of those listed has been determined to be relevant for safety contracts between the OS and an application. This is an avenue for further work, described in the final chapter.

5.2.6. Validation Time

The validation time for the different constraints depends on the nature of the constraint, and the length of time the DR should be upheld. This is discussed further in the next section following some findings from the case study.

5.2.7. Conclusions

This section has presented a conceptual framework for a safety contract. The contracts can be used to describe how a derived requirement (as identified using the analysis technique of the previous chapter) can be met. The next section describes a case study which was undertaken to develop a method for deriving contracts.