3.1.2.2 Define Interfaces Among Subsystems

Overview

In activity 3.1.1.2 Define System Interfaces, the system interfaces are broadly defined. However, in this activity, these interfaces, as well as the subsystem-to-subsystem interfaces, are defined in more detail. The purpose of this activity is to gain an understanding of the flow of information throughout the system. This enables the systems engineering group to document the data and commands being passed, the data formats, and other interface detail in very specific terms in the Interface Design section of the MIL-STD-498 System/Subsystem Design Description (SSDD) (see Appendix E) or equivalent system documentation.

Roles and Responsibilities

The software developer, as a member of the systems engineering group, determines the appropriate subsystem interfaces, and the flow of commands and data.

Controls

The method of portraying command and data flow parameters will be determined by the selection and availability of system engineering tools, and the system design methodology selected by the systems engineering group.

Inputs

The inspected system requirements documented in a MIL-STD-498 System/Subsystem Specification (SSS) (see Appendix E) or equivalent system requirements documentation (see activity 3.1.1 Define System Requirements).

The subsystem definitions and allocated system requirements (see activity 3.1.2.1 Identify Subsystems).

Operational scenarios (developed in activity 3.1.2.3 Generate Subsystem Operational Scenarios) that discuss required subsystem actions with other subsystems.

Prototyping results (performed in activity 3.1.2.4 Perform Prototyping) that may indicate if a subsystem is adequate or feasible for use in the system (e.g., a new board).

The defect list generated during a formal inspection (see activity 3.1.2.5 Participate in the System Design Inspection).

Procedures

There are many detailed methodologies for modeling interfaces in a system, and the following steps have been selected for this Guidebook. These steps are iteratively performed as interface information becomes available.

Throughout this activity, the data dictionary is reviewed and updated as interfaces are identified and defined. The data dictionary contains each input and output for each subsystem.

If a defect, found during a formal inspection and documented on a defect list, is being corrected, each step is reviewed to verify that no additional changes are needed.

1) For each subsystem, the systems engineering group first identifies all input sources, such as human users, environment (e.g., the backscatter signal from the atmosphere as shown in Figure 3.1.1.2-2), or other interfacing systems (see activity 3.1.1.2. Define System Interfaces) or subsystems (see activity 3.1.2.1 Identify Subsystems). Scenarios (see activity 3.1.2.3 Generate Subsystem Operational Scenarios) may identify the appropriate inputs sources.

In Table 3.1.2.2-1, inputs to the Instrument Controller (IC) are initially identified (see Figure 3.1.2.1-3 and accompanying text in activity 3.1.2.1 Identify Subsystems for definitions of the IC and most of these inputs).

Table 3.1.2.2-1 Example IC Inputs

2) The input from these sources is specifically determined in terms of data type (e.g., Boolean, 16-bit 2s complement), units (e.g., watts, rad/sec, volts), range limits (e.g., m to n), accuracy (e.g., ± 5%), precision (e.g., number of significant digits), size (e.g., in bytes, words). Each input and complete description are assigned an identifier and entered into the data dictionary. The System External Interface Requirements section of the SSS may be referenced for information. Subsystem interfaces must be determined by the systems engineering group based on the subsystem descriptions and allocated system requirements (see activity 3.1.2.1 Identify Subsystems).

Each command and, if applicable, the command code (i.e., the bit patterns uplinked/transmitted corresponding to the actions to be taken for each command name) are identified. See example in Table 3.1.2.2-3.

3) The systems engineering group also identifies all destinations for the subsystems’ output. These destinations can include: 1) an external system; or 2) object (e.g., the ground station receiving the instrument and science data) which are documented in the System External Interface Requirements section of the SSS; or 3) another subsystem (see activity 3.1.2.1 Identify Subsystem) (e.g., the BA, Digital Data Handling Unit (DDHU) as shown in Figure 3.1.2.1-3). Scenarios (see activity 3.1.2.3 Generate Subsystem Operational Scenarios) may be used to identify the appropriate destinations.

IC outputs (see Figure 3.1.2.1-3 and accompanying text in activity 3.1.2.1 Identify Subsystem) are initially defined in Table 3.1.2.2-2.

Table 3.1.2.2-2 Example of Instrument Controller Outputs

4) The format of each subsystem’s output is specified in terms of data type (e.g., Boolean, 16 bit 2s complement), units (e.g., watts, rad/sec, volts), range limits (e.g., m to n), accuracy (e.g., within ± 5%), precision (e.g., number of significant digits), size (e.g., in bytes, words). Each output is assigned an identifier and entered into the data dictionary with a complete description. The System External Interface Requirements section of the SSS may be referenced for information. However, the SSS information may not be stated in this level of detail, and thus referencing this section may not be useful.

The following commands used to control the LTM (commands are shown in Table 3.1.2.2-3 and LTM is defined in the example in activity 3.1.2.1 Identify Subsystems) go to the IC from the Ground Station. Select_Laser commands select which laser to use. On/Off commands switch the laser and flashlamps to the On position. Other commands set various laser parameters (e.g., coolant flow limits, air temperature limits).

Table 3.1.2.2-3 LTM Commands

5) The systems engineering group looks at the amount of data being sent throughout the system and the required rate to determine the appropriate interface type (e.g., a RS422 bus is capable of higher bandwidth than a MIL-STD-1553B bus), and the required bandwidth. Documentation and software from past projects can be examined to determine appropriate interfaces and reuse possibilities. If similar components were used on past projects, the interface documentation is reviewed because the interfaces may be similar.

Example:

If a MIL-STD-1553B bus is selected and software was developed for this bus using a United Technologies Microelectronic Control chip in another project, the use of the chip should be seriously considered, thus, enabling software reuse.

Diagrams such as Figure 3.1.2.2-1 may be produced to help visualize the system. This diagram shows the type of interface used to uplink and downlink information between the spacecraft and the ground support software (GSS). Figure 3.1.2.2-1 also shows that the science/instrument data is downlinked over the Sband, processed by the GSS, displayed, and stored. Commands are uplinked over the Sband. The science/instrument data displays and command file generator are linked to a data storage device via a RS422 bus.

Figure 3.1.2.2-1 Example of Spacecraft to Ground Interface

The systems engineering group looks at each proposed interface to determine if the subsystem described can handle the required amount of information under the expected maximum load (e.g., the maximum data amount that may be received/transmitted in a given time, the maximum data amount that can be processed and/or stored, the processor speed) to determine potential bottlenecks. Prototyping can simulate these maximum loads and test the interfaces (see activity 3.1.2.4 Perform Prototyping). Examining the hardware documentation (e.g., MIL-STD-1553B Aircraft Internal Time Division Command/Response Multiplex Data Bus) may determine the maximum loads for commercial products (e.g., a SCSI I/O bus has a maximum bus length of 25m and can support synchronous or asynchronous clocking, while an IPI I/O bus can support only asynchronous clocking but has a maximum bus length of 50m). If the subsystem cannot handle the maximum expected load, it can be redefined (see activity 3.1.2.1 Identify Subsystems) or the hardware/software interfaces can be modified. Diagrams showing the appropriate bus structures, clock pulses, and interrupts are prepared.

An example diagram showing the bus structures, clock pulses, interrupts, and processors of the LIDAR Instrument (see activity 3.1.2.1 Identify Subsystems) is shown in Figure 3.1.2.2-2.

Figure 3.1.2.2-2 Example of a Subsystem Interface Diagram Showing Bus Structures, Clock Pulses, Interrupts, and Processors

6) The systems engineering group begins determining and describing the higher level subsystem interfaces and works its way down to the individual component interfaces. Diagrams are produced showing the commands and data flow between the various subsystems. An informal diagram showing the commands and data flow between the LIDAR Instrument subsystems (see an example in activity 3.1.2.1 Identify Subsystems) is shown in Figure 3.1.2.2-3. A sample formal object interaction diagram (OID) (as defined in Colbert’s Object-Oriented Software Development (OOSD) method [Colbert, 1993] see Attachment II) as shown in Figure 3.1.2.2-4 depicts the same interfaces.

The systems engineering group performs level checking to verify that all inputs and outputs in high-level designs also appear on the lower-level designs. This may be done by hand or automatically depending on the tools used.

7) The subsystem interface descriptions are then documented in the Interface Design section of the MIL-STD-498 System/Subsystem Design Description (SSDD) (see Appendix E).

Figure 3.1.2.2-3 Example of Data and Command Flow Between Subsystems

Figure 3.1.2.2-4 Example of an Object Interaction Diagram (OID)

Outputs

The subsystem interface descriptions consisting of the diagrams, tables, and data dictionary descriptions documenting information flows, and the format of all commands and data for each system component placed in the Interface Design section of the SSDD or equivalent system design documentation.