Managing Interface Requirements

Interface management is like any other element of systems engineering. It is common sense applied to complexity through structured methods and a systematic approach. But, like all methods and processes, you have to know why you are doing it, where to apply it, and what level of effort to expend on it.

Using systems thinking and systems engineering methods for design, interfaces emerge from the iterative architecture definition processes used in the development of a system design. From the concept definition stage onwards, interfaces will be identified at lower levels as the system design evolves in response to the user and system requirements.

Some interfaces will relate to the obvious interactions between major system components, such as an aircraft and air traffic control. Some will be identified by the customer, who may mandate particular interface standards to ensure interoperability with existing systems. Some will emerge as the design solution evolves and sub-systems are identified, either for technical, organisational or procurement reasons.

No matter what the origin, interface design documentation and specifications will become part of a procurement specification and a contract before too long in the project lifecycle. They need to be managed under the project’s configuration management process and identified in its Configuration Management Plan.

Formal interface management regimes exist in all engineering domains. Interface Control Documentation (ICD) is used to record which interfaces exist, their types, ownership, customers, development status, configuration, and supporting detailed documentation; whether that may be Data Exchange Specifications for a data processing system or a set of Interface Drawings for a mechanical handling system or an engine mounting arrangement. This is a vital link between the systems engineering effort and the programme management effort.

Some of the major drivers in deciding where to concentrate effort and attention on interfaces are: the associated level of functional and performance interdependencies, the complexity of the interface, no matter which type, or the novelty. Even where standard interfaces are used, the system analysis must take into account the demands made on the interface by the operating conditions in which the system will be used. It may need to be high integrity under all circumstances, or available on demand for the few occasions when it is called into service.

By capturing interface requirements and linking them to the system design rules and using a set of interface attributes, this analysis can occur as part of the design integration effort and the results sorted to support the design authority’s decision making. Effort can be allocated to undertake functional, behavioural and performance modelling to support the detailed definition of the interface and to understand how it will work in the dynamic conditions of the operational environment using appropriate simulation techniques. These models can then be used to support system thread modelling, which helps to understand, assess and tune overall system performance.

Interfaces also play a vital part in devising the system integration plan and the resulting Test and Evaluation Management Plan (TEMP). The progressive integration of the whole system in the formal testing phase needs to be supported by risk-reducing development testing and type testing, in the areas identified as high risk by the system design analysis activity. This is particularly true where a project is adopting or developing new standards for common types of interfaces.