Systems engineering is not about developing electronics, mechanical, or software designs. Systems engineering is really about four things:

  • Creation of system requirements that meet stakeholder needs;
  • Identification of a system architecture;
  • Allocation of requirements into the system architecture;
  • Handing off subsystem-level specifications to teams responsible for their development.

Figure 1. Systems Engineering Architectural Definition Workflow
Of course, creating the right requirements involves some deep analysis of safety, reliability, control theory, and often, physics. Identification of architecture usually involves trade studies to evaluate architectural alternatives against various measures of effectiveness.

In a traditional systems engineering environment, the primary medium of exchange is textual documentation, often encompassing hundreds to thousands of pages of text. Text, while wonderfully expressive, has some well-known problems for such specifications, including inherent ambiguity and difficulty in ensuring and maintaining consistency, accuracy, and the right level of fidelity.

Including model-based artifacts (UML or SysML) in the hand-off provides better understandability while simultaneously offering greater precision. It is possible to organize the systems engineering workflow to support both the systems engineering work and to support the hand-off to subsystem design teams.

Creating Systems Engineering Specifications

Model-based systems engineering normally proceeds through a black-box functional analysis step and a subsequent architecture synthesis step. This analysis may be revisited if change requests or functional/non-functional issues require a reexamination of the higher-level requirements.

The functional analysis is performed by clustering requirements into groups (use cases, capabilities, or system functions are most common) that are relatively independent of each other and analyzing the black-box system behavior of each. Using executable models to verify and validate the system behavior decreases risk and increases confidence in the correctness and completeness of the system requirements. Logical interfaces to the external elements that have significant interactions with the system (known as “actors”) and the data and control transformations that the system must perform to provide the use case, capability, or function are identified. Logical interfaces focus on semantic intent of the interaction (such as the nature of the command or data) and not on the physical connection-level details.

Once the functional characteristics are rigorously understood, system engineers “open the box” to define a system architecture that can meet the functional and non-functional requirements of the system. Figure 1 shows such a system architecture definition workflow. In the Detailed Architectural Design activity, requirements are allocated to subsystems. One of the ways this is done is to cluster requirements at the subsystem level in the same way as was done at the system level. The scope, however, is limited to the subsystem. In addition, the logical interfaces between the subsystems and the allocation of the functions of the control laws are also done here.

It should be noted that, for the most part, the allocation of requirements and responsibilities to different engineering disciplines isn’t considered yet. Each subsystem usually contains a combination of software, mechanical, digital electronics, and analog electronics. The allocation to engineering disciplines happens immediately after the hand-off to downstream engineering.

The Hand-off to Subsystem Teams

In a model-based systems engineering effort, the most natural hand-off to downstream engineering is — you guessed it — models. Organizing the systems engineering model appropriately simplifies the hand-off to subsystem teams. Figure 2 shows how the systems engineering model can be organized to support the hand-off to the subsystem teams. The primary packages within the systems engineering model are:

  • Requirements package: this package contains the textual requirements (typically imported from a textual based requirements tool, such as DOORSTM), the use cases, and the use case diagrams.
  • Safety Analysis package: this package contains the safety analysis, usually organized around Fault Tree Analysis (FTA) diagrams, but may also contain Fault Means and Effect Analysis (FMEA), Fault Means, Effect, and Criticality Analysis (FMECA), as well as links from those analyses to other elements in the model such as requirements, use cases, scenarios, interfaces, and behavioral specifications.
  • Functional Analysis package: this package contains the deep functional analysis of the system most often with a subpackage per use case. In these packages, each use case is detailed with sequence diagrams, state machines, and activity diagrams. Executable requirements models are a great way to ensure the consistency and correctness of the specifications.
  • Design Synthesis package: this package identifies the largest scale architectural elements — subsystems (sometimes called Line Replaceable Units) and the requirements allocated to those elements and, if necessary, use cases allocated to the subsystems.

The organization of this last package is key to the easy transition to the subsystem teams. Within the Design Synthesis package, simply create a subpackage for each subsystem into which you put all of the specification data for that subsystem. In the simple case, this may just be the interfaces (both offered and required by the subsystem), the control and data transformations they invoke, and the links to the requirements the subsystem must meet. In more complex subsystems, the subsystem is further decomposed into subsystem-level use cases that cluster the subsystem requirements in the same way the system use cases cluster the system requirements. It is this package that constitutes the hand-off to the individual subsystem teams. In the example shown in Figure 2, the Brake Management Subsystem has two use cases that it must support — Normal Braking and ABS Braking. Each of these is detailed with sequence diagrams, state machines, and links to requirements.

Developing Software

Figure 2. Structure of the hand-off from Systems Engineering.
Once the hand-off from systems engineering occurs, the appropriate subsystem spec package is imported into a separate subsystem model. This package forms the detailed requirements that the subsystem, as a separate entity, must meet.

The very first activities taken by the subsystem team are the allocation of subsystem responsibilities to different engineering disciplines and the conversion of the logical interfaces into physical interfaces.

The first of these allocates responsibilities to different engineering disciplines, such as mechanical, digital electronics, analog electronics, and software. It also includes the specification of the cross-discipline interfaces, such as how the software will communicate with the digital hardware, down to the memory map and bit level. Requirements are allocated and derived to form discipline-specific subsystem level specifications.

The second of these takes the fundamental need for the exchange of messages, information, material, and/or energy among subsystems and converts them into physical specifications. For electronic interfaces, this will include specifications of voltage, power, and frequencies. For mechanical interfaces, it will include form, fit, stress, and other characteristics. For software, it will include the identification of bus or network communications, often down to the bit level. These interfaces are best addressed by a cross disciplinary team including representatives from all incorporated disciplines and all subsystems that participate in the interface.

Once the software functionality, interfaces to hardware, and interfaces to other subsystems are defined, the software engineering work can truly begin. The software can be developed using agile or more traditional methods. The workflow is iterative, developing one (or a small number) of use cases at a time and validating the work before going on. The iterations are anywhere from four to six weeks in length and include:

  • Prototype Definition: planning the iteration and detailing of the software use cases;
  • Object Analysis: construction of a demonstrably functionally correct software model and code base;
  • Architectural Design: optimization of the software at the large (system or subsystem) scale;
  • Mechanistic Design: optimization of the software at the medium (collaboration) scale;
  • Detailed Design: optimization of the software at the detailed (class, function, or data structure) scale;
  • Model/Code Review: examination of the model by different stakeholders to ensure compliance with quality standards, architecture, etc.;
  • Validation: formal V&V testing against the requirements implemented thus far;
  • Increment Review (Party Phase): examination of the project performance against key project metrics with replanning when appropriate.

Summary

What we’ve seen here is a very brief discussion of what can be a very complex topic. However, by using model-based systems engineering and organizing the models properly, the hand-off to downstream engineering, including software, can be simplified while maintaining quality, consistency, accuracy, and fidelity of the requirements. When coupled with an agile software development approach, even highly complex systems can be addressed with good success and effectiveness.

This article was written by Dr. Bruce Powel Douglass, Chief Evangelist and Industry Solution Architect for Electronics, Automotive, and Aerospace, IBM Rational (Armonk, NY). For more information, contact Dr. Douglass at This email address is being protected from spambots. You need JavaScript enabled to view it., or visit http://info.hotims.com/28057-400.


Embedded Technology Magazine

This article first appeared in the September, 2010 issue of Embedded Technology Magazine.

Read more articles from this issue here.

Read more articles from the archives here.