Why thorough interface control should help you avoid nasty surprises.

There is a tendency for some systems engineers to think that interface control can wait until you are down in the detail of design, capturing the parameters that are exchanged between sub-systems. I’d argue that ICDs capture the context in which a system operates and provide important drivers into the design and consequences of design choices upon the opposite side of the interface. Ensuring that all interactions are captured and that the boundary conditions are shared between sub-systems should help anticipate the emergent properties of a complex system.

Misunderstanding of context and relationships between elements of a system will tend to emerge as unexpected behaviour during integration testing if you are lucky, or when operating it if you are not. We must make sure we spot them in a complex, safety critical system because missing them can be expensive or hazardous or both.

Let me demonstrate with an example: at the start of the first day of extra-vehicular activity (EVA) of the second Hubble Servicing Mission, the astronauts were preparing to leave the Shuttle and get started on upgrading elements of the telescope. Suddenly, without any warning and whilst powered off, one of the two solar arrays spun through 150 degrees and struck its end stop. This coincided with the astronauts starting to depressurise the airlock (as they had done previously without event during the first servicing mission) and the array engineers watching from the ground were caught completely off guard. It turned out that the Shuttle engineers had modified the venting of air to improve the speed with which astronauts could egress, without checking where the plume of vented air might impinge. We got lucky because the vented gas, that started the array spinning, finished up slowing the rotation, the plume pressure?having transferred to the opposite face after the array swung beyond 90 degrees and there was enough margin to cope when the end stops were encountered, with twice the angular momentum they had been designed for. A visual survey of the array indicated no obvious damage and the solar array drive was powered up to slew the array back to 0 degrees to return to a nominal condition for the rest of the EVA. Each subsequent crew egress reverted to venting from the throttle-able hatch equalisation valve and the mission was completed without further incident.? This is a classic case of where the external impacts of a design change were overlooked with uncontrolled consequences. The role of the systems engineer is to think through the unexpected aspects of any design change, and this is best achieved if all interactions are managed via ICDs. With the development of robotic in orbit servicing the previous example highlights the need to make sure that all aspects of the client servicer interface are properly managed via an ICD.

Interfaces within a spacecraft broadly fall into three categories:

• Mechanical interfaces: intuitively, these should be the simplest to manage, since if the nut and bolt don’t line up this should be obvious but the way in which heat is conducted or radiated across the interface, vibration is amplified (or preferably attenuated), ensuring adequate grounding from an EMC/ESD perspective, even venting during depressurisation on ascent and demise-ability upon re-entry must also be considered.
• Electrical Interfaces: again the na?ve might think this only relates to the pinout at connectors between units but voltage levels, synchronisation and data protocols will impact upon how harnesses are wound, connectors are sized and lines distributed.
• Software interfaces: the most difficult aspect of interface control which will be familiar to the wider software community because the interface being controlled is not physical. It is important that the ICD not only identifies the data structures via which data is being exchanged but also makes sure that the content is interpreted consistently across the interface.

The systems engineer’s role must be to make sure that the information needed by each engineering discipline is shared across each interface so that the consequences of a design choice in one facet of a design are properly reflected into others. The most extreme case of this is the TMTC Interface (exchanging data between the spacecraft and the ground) because so many different disciplines have a vested interest in different aspects of the data-stream and everybody will blame the systems engineer when they can’t find what they are looking for:

• RF engineers will be worrying about link budgets,
• avionics engineers about data protocols and packet utilisation standards;
• electronics engineers about the endianness of the data (amongst many other things);
• software engineers about the data within the packets;
• and operators about the information within the data and how it relates to the monitoring and control of the spacecraft.

Add in that the verification team are going to be worrying about all of the above to support test plans and to design & validate test equipment. So the systems engineer must reconcile needs of multiple customers to provide mutually consistent data that allows the mission to be achieved. I would argue that it is the specialists who need to populate the detail of the ICD but the systems engineer must assure its completeness and translation for sharing with other users.

Early in system definition interface control is about making sure that all aspects of context are taken into account in formulating a coherent concept. In redrafting the sketch of an Earth Observation Mission that introduced this article to move from specification to interfaces there was not one bubble, box or arrow that didn’t have to be moved to accommodate interdependencies! As the architecture is defined the consequences of design choices in one part of the system have to be captured, so that their impact upon others is properly understood. By the time critical design review is reached every last bit must be detailed so that sub-system implementation will deliver the expected system outcome and successful integration can be demonstrated without any nasty surprises.

This is the fifth article in a series. If you are a glutton for punishment you may want to read the others:

Mission and System requirements. What’s the difference and why does it matter?

Does a Bicycle need a Systems Engineering Management Plan?

Why a System Engineering Management Plan helps Successful Delivery across a Programme or Product Lifecycle.

Why should I care about Requirement Decomposition as part of system design?