Model-Based Systems Engineering

by A.Wayne Wymore

For the purposes of a mathematical theory of system design, the set of system theoretic models chosen for development in this book, for both practical and pedagogical reasons, is the set of discrete-time automata or state machines.

DSYS...

functional system designs, buildable system designs, and implementable system designs—will be represented by system theoretic models in the set DSYSTEMS.

1.53 Definition: The system life cycle is defined in seven phases: Phase 1: Requirements development, Phase 2: Concept development, Phase 3: Full-scale engineering development, Phase 4: System development—production, manufacturing, deployment, Phase 5: System test and integration, Phase 6: Operations, support, and modification, and

Phase 7: Retirement and replacement.

Phases 1 through 3 are called the system design cycle. Phases 1 through 5 are called the...

System life cycle Phase 1 1.54 Definition: In system life cycle Phase 1, the requirements development phase, systems engineering must perform the following tasks: Task 1.1: Understand the problem situation, identify the customer, and design the system SYNERGY, Task 1.2: Understand the customer’s operational need, Task 1.3: Derive the system requirements, Task 1.4: Validate the system requirements, and Task 1.5: Design the subsystem SANITY. Systems engineering must also produce the following systems engineering documents: Document 1: The Problem Situation Document,

Document 2: The Operational Need Document, Document 3: The System Requirements Document, and Document 4: The System Requirements Validation Document.

Phase 1 interdisciplinary input

1.57 SYNERGY—the SYstems eNgineERinG sYstem:

SYNERGY—the systems engineering system to provide systems engineering services throughout the life cycle of the system. • SANITY—the systems analysis and trade-off study (or trade study, for short) system to model, evaluate, and compare proposed system designs in Phase 2 and subsequently as required. • REALITY—the system to test the real system in Phase 5.

DETAILED DESIGN SYSTEM—the system to accomplish the detailed design of the system in Phase 3, involving the design of hardware, definition of data structures and design of algorithms, and design of job descriptions and training programs and • SYSTEM DEVELOPMENT SYSTEM—the

system to acquire the real components of the system and to deploy them in Phase 4, involving the purchase of off-the-shelf components, manufacture of hardware, coding and installation of software, recruitment and training of operators, and orientation of users.

This is the reason that emphasis herein is placed on SANITY and REALITY. The necessity to design SANITY and REALITY is rarely acknowledged.

Problem Situation Document. It could be modified to fit any particular situation: 1.1 The Top-Level System Function of SYSTEMTBD 1.2 History of the Problem and the Project 1.3 The Present System or Systems 1.4 The Customer 1.4.1 Owners 1.4.2 Bill-Payers: The Client 1.4.3 Users

1.4.4 Operators 1.4.5 Beneficiaries 1.4.6 Victims 1.4.7 Technical Representatives to Systems Engineering 1.4.8 Other Stakeholders 1.5 System Environment of SYSTEMTBD 1.5.1 Social/Economic Impact of SYSTEMTBD 1.5.2 Environmental Impact of SYSTEMTBD 1.5.3 Interoperability of SYSTEMTBD 1.6 Design of SYNERGY 1.6.1 System Life Cycle Phase 1 of SYSTEMTBD 1.6.2 System Life Cycle Phase 2 of SYSTEMTBD 1.6.3 System Life Cycle Phase 3 of SYSTEMTBD 1.6.4 System Life Cycle Phase 4 of SYSTEMTBD 1.6.5 System Life Cycle Phase 5 of SYSTEMTBD 1.6.6 System Life Cycle Phase 6 of SYSTEMTBD 1.6.7 System Life Cycle Phase 7 of SYSTEMTBD 1.6.8 Systems Engineering Management Plan for SYSTEMTBD 1.7 Exhibits 1.8

The ultimate objective is to achieve a statement of the “top-level” problem first in human terms and then, consistently, in mathematical terms and to show that the mathematical problem has a solution in the real world. The statement of the customer’s problem ought to be comprehensive, complete, consistent, and precise. Such a problem statement can only rarely be achieved by one systems engineer working alone with the customer or even by a group of systems engineers. Almost always a comprehensive, complete, consistent and precise statement of the problem of the design of a system can be achieved only by an interdisciplinary team looking at all aspects of the customer’s problem.

Phase 1: Systems engineering personnel and consultants appropriate to the discovery and development of system requirements for SYSTEMTBD, and personnel and facilities necessary to the acquisition of the subsystem SANITY of SYNERGY, Phase 2: Systems engineering personnel and technological consultants appropriate to concept development; personnel, and facilities necessary to the acquisition of the subsystem REALITY, Phase 3: Systems, hardware, software, and human factors engineering personnel, facilities, and subcontractors necessary for full-scale engineering development, Phase 4: Systems, manufacturing and industrial engineering personnel, hardware and software production personnel and facilities, and training personnel and facilities necessary to the actual production of the system components of SYSTEMTBD, including the training of the operators and users, Phase 5: Systems and other engineering personnel and facilities necessary for test and integration of SYSTEMTBD, Phase 6: Systems engineering personnel and facilities available for periodic monitoring and evaluation of SYSTEMTBD and review of proposed engineering changes throughout the operational phase of the system, and Phase 7: Systems engineering personnel available to recommend and plan for the retirement and replacement of SYSTEMTBD.

systems engineering must apply the same rigorous systems engineering methodology to the design of SYNERGY and its subsystems SANITY and REALITY as would be applied to the design of any other large-scale, complex bioware/hardware/software system!

The systems engineer tries, rather, to see the problem from a technology-free point of view.

The systems engineer tries first to symbolize and then to attack the human problem that the system to be designed or analyzed will exist to solve, not, at the outset, the technological problem.

The Operational Need Document 1.63 Definition: Systems Engineering Document 2, the Operational Need Document for SYSTEMTBD: • is readable by both systems engineering management and the customer, • states the problem of the design of SYSTEMTBD, not the solution, • introduces the structure for defining system design requirements in mathematical terms in the next document, • defines the system requirements in all

categories but in nontechnical terms, • traces every requirement to an expressed and recorded opinion of the customer, • states, if possible, the human problem to be solved, not the technical problem, • states the problem as the customer sees it, and • is kept current throughout the system life cycle. Proposed table of contents: 2.1 The Deficiency Motivating the Acquisition of SYSTEMTBD 2.2 Input/Output Requirement for SYSTEMTBD 2.3 Technology Requirement for SYSTEMTBD 2.4 Performance Requirement for SYSTEMTBD 2.5 Cost Requirement for SYSTEMTBD 2.6 Trade-off Requirement for SYSTEMTBD 2.7 System Test Requirement for SYSTEMTBD

2.8 Rationale for Operational Need Specifications 2...

Systems Engineering Document 3, the System Requirements Document for SYSTEMTBD: • states a mathematical problem whose solution is a model on the basis of which a real system can be built that will satisfy all system requirements stated in the Operational Need Document, • defines computable and testable figures of merit in terms of which system requirements in all categories are defined, • includes a requirements rationale section which – traces each mathematically defined requirement to a requirement recorded in the Operational Need Document and – justifies each mathematically defined requirement on the basis of simulations,

analyses, literary citations, correspondence with the customer, minutes of meetings, or expert opinions, • does not oversimplify the problem, and • avoids stating the problem in terms of a solution or class of solutions. Proposed table of contents: 3.1 Introduction to the System Requirements for SYSTEMTBD 3.2 The Input/Output Requirement for SYSTEMTBD 3.2.1 Operational Life of SYSTEMTBD 3.2.2 Inputs to SYSTEMTBD 3.2.3 Input Trajectories of SYSTEMTBD 3.2.4 Outputs from SYSTEMTBD 3.2.5 Output Trajectories from SYSTEMTBD 3.2.6 Eligibility Function for SYSTEMTBD 3.3 The Technology Requirement for SYSTEMTBD

3.3.1 Restrictions 3.3.2 Stipulations 3.3.3 Specification Functions 3.3.4 Models 3.4 The Performance Requirement for SYSTEMTBD 3.4.1 Notation for Performance Indices and Figures of Merit 3.4.2 Lower and Upper Threshold Values, Baselines, Weights, and Scoring Functions for Performance Indices and Figures of Merit 3.4.3 Definitions of Performance Indices 3.4.4 Definitions of Performance Figures of Merit 3.4.5 Definition of the Performance Requirement 3.5 The Cost Require...

Scoring Functions for Cost Figures of Merit 3.5.3 Definitions of Cost Figures of Merit 3.5.4 Definition of the Cost Requirement 3.6 The Trade-off Requirement for SYSTEMTBD 3.6.1 Notation for Trade-off Figures of Merit 3.6.2 Lower and Upper Threshold Values, Baselines, Weights, and Scoring Functions for Trade-off Figures of Merit 3.6.3 Definitions of Trade-off Figures of Merit 3.6.4 Definition of The Trade-off Requirement 3.7 The System Test Requirement for SYSTEMTBD 3.7.1 Observance 3.7.2 Compliance 3.7.3 Conf...

Proposed table of contents: 4.1 Functional System Designs 4.2 Implementable System Designs 4.3 A Real System 4.4 Exhibits 4.5

SANITY —the Systems ANalysIs and Trade study sYstem: When

SANITY, the Systems ANalysIs and Trade study sYstem.

System life cycle Phase 2 1.76 Definition In system life cycle Phase 2, the concept development phase, systems engineering must perform the following tasks: Task 2.1: Choose a system design concept, Task 2.2: Design the subsystem REALITY, Task 2.3: Perform system functional analysis, Task 2.4: Perform physical synthesis, and Task 2.5: Provide design requirements for system components. Systems engineering must also produce the following systems engineering documents: Document 5: The Concept Exploration Document, Document 6: The System Functional Analysis Document, and Document 7: The Physical Synthesis Document

The system design concept

Phase 2 interdisciplinary input

The Concept Exploration Document

1.80 Definition: Systems Engineering Document 5, the Concept Exploration Document for SYSTEMTBD: • identifies the set of alternative system design concepts, • describes a model for each alternative, • gives, for each alternative, a value for each figure of merit defined in the System Requirements Document, • records how the numbers were derived or estimated, • records the trade-off analysis, • recommends an alternative to be chosen, • includes a sensitivity analysis, • includes rationale for the choice of alternatives, the level of modeling, and the methods for estimating the values of the figures of merit, and

is so complete that the decision analysis can be repeated. Proposed table of contents: 5.1 System Design Concept Alternatives 5.2 Models of System Design Concepts 5.3 Estimation of the Values of Figures of Merit 5.4 Trade-off Analysis 5.5 Alternative Recommended 5.6 Sensitivity Analysis 5.7 Rationale for Alternatives, Models, and Methods of Estimation 5.8 Exhibits 5.9

REALITY

System functional analysis

three steps: Step 1: Decompose the top-level input/output requirement into an interrelated set of input/output requirements each defined in the same format as, and consistent with, the top-level input/output requirement. This decomposition is based on guidance from

physical synthesis. At the top level, this guidance is in the form of the system design concept. Step 2: Decompose the requirements in all the other categories of the top-level system design problem as described in the System Requirements Document and allocate them to the input/output requirements defined in Step 1. This step results in a resolution of the top-level system design problem into an interrelated set of system design problems for components. Step 3: Demonstrate that the system design problem resolution is consistent with the top-level system design problem. One criterion for this consistency is that, when functional system designs for each of the input/output requirements in the resolution are combined according to the interrelations specified for the input/output requirement decomposition, the result is a functional system design for the original input/output requirement. Similarly, criteria are generated for buildable system designs and implementable system designs.

Additional consistency conditions in terms of performance, cost, trade-off, and system test requi...

Physical synthesis

Step 1: Demonstrate the validity of the system requirements of each system design problem in the resolution produced at Step 2 of system functional analysis, with techniques similar to those used to validate the system requirements of the top-level system design problem in Systems Engineering Document 4, the System Requirements Validation Document. Figure 1.13 The effects of the first two iterations of system functional analysis. Step 2: Choose a system design concept for the implementation of each system function with techniques similar to those used to choose a system design concept for the top-level system design problem in Systems Engineering Document 5, the Concept Exploration Document, where each system function is represented by a system design problem in the resolution produced at Step 2 of system functional analysis. Step 3: Assign each system function (represented by a system design problem in the resolution) to a physical component described in the Concept Exploration Document consistent with the design concepts chosen in Step 2 of physical synthesis and with previous assignments of system functions to physical elements. Step 4: Elaborate, that is, derive further detail in the specification of, the statement of the problem of the design of each physical component described in the Concept Exploration Document on the basis of the necessity to accommodate the new system functions assigned to the physical component. Step 5: Demonstrate that – all system functions wi...

In systems engineering, an accountability problem frequently appears during the review of a system design: “Who made the decision to do it this way and why?” The trade study provides the ideal design rationale: “All these alternatives were considered with respect to all these criteria and

these trade-offs among the criteria, and this alternative was the best.

System life cycle Phase 3 1.102 Definition: In system life cycle Phase 3, the full-scale engineering development phase, hardware, software, and human factors engineers coordinated by systems engineering produce the detailed specifications necessary for the production and manufacture of the hardware and software elements and the training of the human operators and users, based on the requirements generated by systems engineering for each physical component as recorded in the System Functional Analysis Document and the Physical Synthesis Document.

System life cycle Phase 4