Overview
In this activity, the individual subsystems making up the system are identified. The system-level requirements are allocated to the various subsystems, and additional requirements are derived from them, based on the design decisions being made. In some cases, the subsystem consists of one or more commercial or pre-existing products, while in other cases, all or part of the subsystem may have to be developed.
Roles and Responsibilities
The software developer, as a member of the systems engineering group, identifies the various subsystems and requirements, and the derived requirements allocated to each one.
Controls
See parent activity 3.1.2 Define System Design.
Inputs
The inspected system requirements documented in a MIL-STD-498 System/Subsystem Specification (SSS) (see Appendix E) or other equivalent system requirements documentation (see activity 3.1.1 Define System Requirements).
Subsystem interface descriptions defined (see activity 3.1.2.2 Define Interfaces Among Subsystems) in previous iterations.
Operational scenarios that discuss details of subsystem interactions (see activity 3.1.2.3 Generate Subsystem Operational Scenarios) developed in previous iterations.
Prototyping results (see activity 3.1.2.4 Perform Prototyping) that may indicate if a subsystem is adequate or feasible for system use (e.g., can the integrated motor controller assembly developed for a previous project be reused on the new system?).
The defect list generated during a formal inspection (see activity 3.1.2.5 Participate In System Design Inspection).
Procedures
When correcting defects found during a formal inspection, the systems engineering group ensures that any necessary changes are also incorporated in the system requirements (see activity 3.1.1 Define System Requirements). The systems engineering group determines if correcting a subsystem definition affects the subsystem scenarios (see activity 3.1.2.3 Generate Subsystem Operational Scenarios), and the subsystem interfaces (see activity 3.1.2.2 Define Interfaces Among Subsystems).
The following steps are iteratively performed. At first, only the major subsystems are identified. Some of these may be apparent from the system requirements (e.g., the flight subsystem, the ground subsystem). It is important the developer keeps in mind that there may be subsystems required to support the mission that are not readily apparent from the requirements documentation (e.g., subsystems required for testing, data analysis). These major subsystems are then iteratively broken down into lower-level subsystems as the operational scenarios and interface definitions are developed. In turn, these subsystems may identify other subsystems. Prototyping may be performed and the results evaluated as necessary to support design decisions (see activity 3.1.2.4 Perform Prototyping).
1) Identify the major subsystems making up the system. These subsystems are normally the instrument, the platform (e.g., pallet or launch vehicle), and the ground support.
The example, shown in Figure 3.1.2.1-1, is based upon a Light Detection and Ranging (LIDAR) System and other similar systems developed in the Software Engineering and Analysis Laboratory (SEAL).
Figure 3.1.2.1-1. Example of Major Subsystems
2) Each subsystem is then broken down into its various major components as shown in Figure 3.1.2.1-2.
Figure 3.1.2.1-2 Example of Further Subsystem Decomposition
The systems engineering group carefully reviews documentation from previous similar experiments to identify potential reusable hardware and/or software components. Commercial products that can be used are identified. If the subsystems are not obvious, the group may simply divide each system into various objects or functional components to identify subsystems.
For space projects, the flight subsystem and three ground subsystems are normally required.
Flight Subsystems. Consists of the platform and instrument(s). Instruments’ subsystems include the various instrument components (e.g., lasers, cryo-coolers, heaters, cameras, motors) and the software to control them (e.g., process scientific data, evaluate instrument status, perform safety limit checking, control motors, monitor sensors). In the example (Figure 3.1.2.1-2), this was broken down as follows:
Example:
LIDAR Instrument
Laser. The laser emits short pulses of laser light down to the atmosphere.
Instrument Controller (IC). The IC handles all uplinked data, processes all commands and commands and controls the laser.
Receiver Assembly (RA). The RA detects the portion of laser light scattered back to the instrument by the atmosphere.
Experimental Platform. The LIDAR Instrument is mounted on a support platform attached by struts to the Spacelab pallet. The support platform for the instrument subsystems is designed to be immune to thermal deformations which could affect optical alignment.
Ground support subsystems. Normally, this is the simulation hardware and software (which simulates hardware or other external interfaces) that test and validate the flight software or hardware, and associated interfaces and data. This cannot be defined until the flight subsystems have been defined. Software may be written to test every hardware interface, so there may be as many simulators as interfaces. Hardware also may simulate various aspects of the environment (e.g., light, heat, vibration).
Mission operations subsystems. The mission operations subsystems command the spacecraft and instrument (e.g., control the power, attitude, heat, fault detection, and instrument functions), monitor all flight subsystems, manage the data recorders, and receive the data. The hardware is normally pre-existing (e.g., the receiving and tracking station hardware).
Post-mission data analysis subsystems. This software analyzes the mission science data. This involves suitably formatting data for the science personnel. Normally, the science team asks for additional analyses, based on the initial format and analysis results. Consequently, this may be iterated several times, and involve developing additional software. This cannot be defined until the flight and mission operations subsystems are defined to understand the actual data formats that will be used.
The software developer confirms that the software functionality of each category is defined and understood before software development begins on those subsystems.
3) Each subsystem is decomposed to a level where the systems engineering group feels comfortable that its functionality is clearly defined, and that the components are available (commercially or reusable from a past project) or are defined well enough to begin development. Additional lower-level subsystems may be identified as shown in Figure 3.1.2.1-3.
Figure 3.1.2.1-3 Example of a Lower Level Subsystem Decomposition of the LIDAR Instrument
Data Digital Handling Unit (DDHU). The DDHU controls the analog to digital converter hardware, generates all clock pulses, digitizes and averages the science channels’ analog data, receives commands (e.g., Digitizer_On, raw signal selection) and status (i.e., Instrument Status Data Block (ISDB) data) from the IC, and formats and transmits the telemetry data stream (i.e., science data and ISDB).
Boresight Assembly (BA). The BA, a two-axis, motor-driven prism, aligns the laser beam to the telescope field-of-view so that both point to the same column of atmosphere. It receives commands from and transmits data to the IC.
Laser Transmitter Module (LTM). The LTM consists of two lasers. Each laser simultaneously emits at the three, harmonically-related wavelengths of 1064 nm (infrared), 532 nm (visible green), and 355 nm (ultraviolet). The two-laser system provides redundancy in case one laser fails. Only one laser operates at a time.
Instrument Controller (IC). The IC handles all user commands, command parameters, and uplinked software. All subsystems are commanded and controlled via the IC. Instrument health and status are monitored and recorded in the ISDB. The ISDB is transferred to the DDHU which transmits it as part of the telemetry data stream. The IC handles all out-of-safe-limit conditions (e.g., when limits are exceeded, it may automatically halt operations, and go to a "safe" (i.e., standby) mode).
Receiver Assembly (RA). The RA includes a one meter telescope and an aft-optics package. The telescope collects laser light scattered from the atmosphere, and focuses it in the aft optics. The aft optics include wavelength selective optics to separate the return signal into its three color components. The IC commands it to collect the laser light and it returns the laser light data to the IC. The assembly includes the light sensors.
4) Once the system is decomposed into its various subsystems, and these are decomposed into various well-defined components, the systems engineering group identifies any other subsystems or components necessary to use, develop, or test the system. These can include: ground support software to support testing, post-mission software or hardware to analyze the data received, special hardware tools required for system integration, and any support equipment. Special adaptations or equipment to support external interface testing (e.g., the spacecraft bus) are noted.
5) Each hardware and software subsystem and component is carefully described in the System Components section of the MIL-STD-498 System/Subsystem Design Description (SSDD) (see Appendix E) or other equivalent system design documentation. If the component is commercial or being reused from another project, the product documentation is obtained and referenced. System requirements are reviewed and allocated to the various subsystems. The systems engineering group verifies that the components selected or planned will work together and meet all system requirements without violating any system or subsystem constraints (e.g., power and weight limitations).
6) A traceability matrix should be developed mapping the system requirements to the subsystems to which they have been allocated. The system requirements should be grouped in terms of system components, showing traceability between the system requirements and the various system components. This should be placed in the Requirements Traceability section of the SSDD or other equivalent system documentation.
7) The software developer reviews all system design documentation and verifies that the subsystems requiring software support are identified and described in sufficient detail to proceed with software development (see activity 3.2 Perform Software Development).
Outputs
The definition of each subsystem documented in the System Components section, and the allocated system requirements it fulfills as identified via a trace matrix in the Requirement Traceability section of the SSDD or equivalent system documentation. In some cases, requirements will be satisfied by selecting a commercial product, while in others, it may involve documenting in-depth requirements specifications for products that must be developed.