Introduction to Concept Design

6.6 Design Synthesis

Completing the initial definition of the functional architecture sets the stage for beginning design synthesis. The design synthesis task defines physical elements of hardware and software to carry out the functions in the functional architecture and to fulfill the requirements allocated to the functions. It is an allocation and partitioning task. Allocation refers to the mapping of functions to physical elements and partitioning refers to the grouping of functions and physical elements. It’s helpful if the functional architecture is defined to the second level, at least in draft form, before beginning design synthesis. Design synthesis is done in steps. Usually the steps are called concept design, preliminary design and detailed design. Each step adds more detail to the design and defines the design to lower levels of the system hierarchy. At the completion of detailed design a complete set of procurement documentation, manufacturing drawings, detailed software descriptions and integration and test (I&T) documentation is finalized and ready for procurement of parts, manufacturing, software coding and I&T.

6.6.1 Concept Design

Concept design is emphasized here as systems engineers have a greater role in the concept design than in preliminary and detailed design. The objective of concept design is to convert the functional architecture to a physical architecture. In this process the functional architecture and the allocated requirements may be refined and other supporting documentation developed. Three outputs from design synthesis during concept design are a physical architecture, a baseline design and a physical view of the system.

The physical architecture is defined by a physical block diagram or signal flow block diagram that schematically illustrates the relationships and interfaces between the physical subsystems (hardware and software) that map to the functional architecture. The physical architecture is part of the system architecture, which includes the enabling products and services needed by the system in all of its life cycle modes. An example of a simple physical block diagram of a candidate concept design for the toaster defined by the functions shown in Figure 6-24 is shown in Figure 6-31. (Again, apologies to toaster designers for any ignorance of toaster design.)

Figure 6-31 A physical block diagram for a candidate toaster concept design.

Systems that involve the collection, processing and communication of signals or similar information are often better described by a signal flow diagram. A signal flow diagram is a physical block diagram that follows the system signals from initial collection to their output from the system. Modularity is often easier to visualize in signal flow diagrams than block diagrams. Signal flow diagrams are typically more complex than simple block diagrams so it’s usually best to define alternative concepts and conduct trade studies using simple block diagrams. Once the final baseline concept is selected then constructing a signal flow diagram helps explain the selected design concept better than a simple block diagram.

The baseline design includes the functional architecture, the physical architecture, the system specification, and the ICD. The baseline design evolves with the design maturity and is the basic item under configuration management. The baseline design is a means for facilitating decision management during the three stages of design synthesis. At each stage; concept design, preliminary design and detailed design; it is good practice to force the work to a baseline design quickly and then conduct trade studies to refine the selected baseline. Otherwise too many design decisions are open at any time and control of the design work becomes difficult.

The physical view includes all of the diagrams, documents, models, etc. that describe how the system is constructed, how it interfaces with humans and other supporting systems during the life cycle modes, any customer supplied equipment, and any constraints on the design or operations.

Processes and Tools for Planning a Program- 7

System Design Document (SDD) - The SDD is intended to capture an overview of the system design. It should be generated in parallel with the system design work and serve as a concise data source for new personnel coming on to a project at any time during the life cycle and as a reference document for future designs. The SDD should include a summary of top level requirements, but is not the source of requirements information, and it should include the project information architecture.

The SDD captures all system level design diagrams, provides a description of each mode, defines the operational scenarios, includes key use cases, includes a complete functional description to at least the second level and includes a complete description of the physical architecture.

If the enterprise has a mature information system that is designed to archive design data such that links are preserved then the SDD can include links to more detailed design analysis and design documentation; if not then it probably isn’t worthwhile to include such links.

The SDD is not defined as part of the integrated design data packages by the DoD, NASA or IEEE handbooks. However, think of the SDD as the introduction and summary section of the total data package. Just as a good technical report or proposal needs an introduction and summary an integrated design data package needs a SDD to orient users, especially on their first visits to the data package and before they begin contributing to the product design effort. The SDD is also the primary reference for future development of similar products. Trying to wade through the design data of a prior product development without having a SDD to introduce and summarize the design is a formidable task that is avoided if a SDD is available as a roadmap to the design.

Information Architecture - Design of a modern complex system results in generating a large number of specifications, documents, drawings, plans etc. A drawing tree, or a specification tree and drawing tree, may have sufficed to describe the relationships and traceability of design documentation for simple products of the past but these simple trees are no longer sufficient.  It is critical to develop and maintain a data management system as part of an overall configuration management process so that data integrity is maintained and any desired data is easily retrievable. Part of planning a program is defining how this data base is to be configured for the system or product being developed. Unfortunately there seems to be no agreement on what name to give to the complex data base needed today. In this work the term Data Management Repository (DMR) is used for the data base that includes all the documentation associated with the product development. How this DMR database is structured and how traceability is defined is called the information architecture. A key element of the information architecture is the document tree, which is an expansion of the traditional specification tree that includes specifications, plans and key technical reports.

If a modern object oriented data management tool like Telelogic’s Dynamic Object Oriented Requirements System (DOORS^TM), or an equivalent tool is used the document tree can be a template for defining the database. For example, if DOORS^TM is used each box on the Document Tree represents a formal module (data set) in the DOORS^TM database.  Arrows between the boxes identify important relationships (DOORS^TM links) between DOORS^TM formal objects.  These links represent the requirements and decision traceability when complete and they facilitate change management and impact assessment. A Link Module is created in DOORS^TM for each different relationship type captured in the Document Tree. These link modules can include requirements, verification, decision and change with each having a different color on the tree diagram to make traceability easy. An example of a simple document tree for a hypothetical system called AB is shown in Figure 4-5 with only requirements links and verification links shown.

Figure 4-5 A simplified document tree for a hypothetical system called AB showing requirements links and verification links.

The SEMP outline given in a previous posting includes a specification tree and a list of other documents. It is recommended that these two items be replaced by the document tree.