Annex F
(informative)
Techniques for achieving non-interferencebetween software elements on a single computer

F.1Introduction
Independence of execution between software elements which are hosted on a single computer system (consisting of one or more processors together with memory and other hardware devices shared between those processors) can be achieved and demonstrated by means of a number of different methods. This annex sets out some techniques which can be used to achieve non-interference (between elements of differing systematic capability, between elements which are designed to achieve or contribute to the same safety function, or between software contributing to a safety function and non-safety related software on the same computer).

NOTE The term “independence of execution” means that elements will not adversely interfere with each other’s execution behaviour such that a dangerous failure would occur. It is used to distinguish other aspects of independence which may be required between elements, in particular diversity, to meet other requirements of the standard.

F.2 Domains of behaviour
Independence of execution should be achieved and demonstrated both in the spatial and temporal domains.
Spatial: the data used by a one element shall not be changed by a another element. In particular, it shall not be changed by a non-safety related element.

Temporal: one element shall not cause another element to function incorrectly by taking too high a share of the available processor execution time, or by blocking execution of the other element by locking a shared resource of some kind.

F.3 Causal factor analysis
To demonstrate independence of execution, an analysis of the proposed design should be undertaken to identify all possible causes of execution interference between the notionally independent (non-interfering) elements in the spatial and temporal domains. The analysis should consider both normal operation and operation under failure conditions, and should include (but need not be limited to) the following:
a) shared use of random access memory;
b) shared use of peripheral devices;
c) shared use of processor time (where two or more elements are executed by a single processor);
d) communications between the elements necessary to achieve the overall design;
e) the possibility that a failure in one element (such as an overflow, or divide by zero
exception, or an incorrect pointer calculation) may cause a consequent failure in other elements.

The achievement and justification of independence of execution will then have to address all these identified sources of interference.

F.4 Achieving spatial independence
Techniques for achieving and demonstrating spatial independence include the following:

a) Use of hardware memory protection between different elements, including elements of differing systematic capability.

b) Use of an operating system which permits each element to execute in its own process with its own virtual memory space, supported by hardware memory protection.

c) Use of rigorous design, source code and possibly object code analysis to demonstrate that no explicit or implicit memory references are made from between software elements which can result in data belonging to another element being overwritten (for the case where hardware memory protection is not available).

d) Software protection of the data of a higher integrity element from illegal modification by a lower integrity element.

Data should not be passed from a lower to a higher integrity element unless the higher integrity element can verify that the data is of sufficient integrity.
Where data has to be passed between elements which are required to be independent, uni-directional interfaces such as messages or pipes should be used in preference to shared memory.

NOTE Ideally the independent elements would not communicate with each other. However, where the design of the system requires that one element should send data to another element, the design of the communication mechanism should be such that neither the sending nor the receiving elements should fail or be blocked in
execution if data transmission ceases or is delayed.

Any data resident on permanent storage devices such as magnetic discs shall be taken into account for spatial partitioning, in addition to transient data in random access memory. For example, file access protection implemented by an operating system could be used to prevent one element writing to data areas belonging to another element.

F.5 Achieving temporal independence
Techniques for ensuring temporal independence include
a) Deterministic scheduling methods. For example,
• a cyclic scheduling algorithm which gives each element a defined time slice supported by worst case execution time analysis of each element to demonstrate statically that the timing requirements for each element are met;
• time triggered architectures.
b) Strict priority based scheduling implemented by a real-time executive with a means of avoiding priority inversion.
c) Time fences which will terminate the execution of an element if it over-runs its allotted execution time or deadline (in such a case, hazard analysis shall be undertaken to show that termination of an element will not result in a dangerous failure, so this technique may be best employed for a non-safety related element).
d) An operating system which guarantees that no process can be starved of processor time, for example by means of time slicing. Such an approach may only be applicable where there are no hard real time requirements to be met by the safety related elements, and it is shown that the scheduling algorithm will not result in undue delays to any element.

Where a resource (such as a peripheral device) is shared between elements, the design shall ensure that the elements will not function incorrectly because the shared resource is locked by another element. The time required to access a shared resource shall be taken into account in determining temporal non-interference.

F.6 Requirements for supporting software
If an operating system, a real-time executive, memory management, timer management or any other such software is to be used to provide spatial or temporal independence, or both, then such software shall be of the highest systematic capability of any of the elements which are required to be independent.
NOTE It is clear that any such software represents a potential common cause of failure of the independent elements.

F.7 Independence of software modules – programming language aspects
The following Table F.1is an informal definition of relevant terms.

As a general rule, module independence is enhanced if there is loose coupling between modules and high cohesion within modules. High cohesion encourages the situation where identifiable units of functionality correspond clearly with identifiable units of implementing code, while loose module coupling promotes low interaction and thus high independence between functionally unrelated modules. Loose module coupling usually results from achieving high cohesion within modules by putting
the code and data together that are used to perform one particular function. Low cohesion results, if code and data are assembled in modules only arbitrarily, or because of some timing sequence or due to some sequence in the control flow.
Several aspects of module coupling can be distinguished, see Table F.2 below.

Code reading or code review (see 7.9.2.12) should verify whether or not the program modules are loosely coupled. This analysis normally requires some sort of understanding of the modules’ purpose and their way of working. Proper coupling can therefore be assessed only by reading the code and its documentation.
Content coupling should be avoided. Global coupling may be used only exceptionally. Control coupling and procedural coupling should be avoided. If ever possible, modules should be connected by interface coupling (encapsulation) and/or data coupling.