Why Model?
System models can be used for many purposes. This topic highlights some of those purposes in support of model-based systems engineering (MBSE), and provides indicators of an effective model.
Purpose of a Model
Models are representations that can aid in defining, analyzing, and communicating a set of concepts. System models are specifically developed to support analysis, specification, design, and verification of a system, and communication of this information. One of the first principles of modeling is to clearly define the purpose of the model. Some of the purposes that models can serve throughout the system life cycle are highlighted below.
- Characterizing an existing system. Many existing systems may be poorly documented, and modeling the system can provide a concise way to capture the existing system design. This information can then be used to facilitate maintaining the system or to assess the system with the goal of improving it. This is analogous to creating an architectural model of an old building with overlays for electrical, plumbing, and structure before proceeding to upgrade it to withstand new earthquake standards.
- Mission and system concept formulation and evaluation. Models can be applied early in the system life cycle to synthesize and evaluate alternative mission and system concepts. This includes clearly and unambiguously defining the system's mission and the value it is expected to deliver to its beneficiaries. Models can be used to explore a trade-space by modeling alternative system designs, and assessing the impact of critical system parameters such as weight, speed, accuracy, reliability, and cost on the overall measures of merit. In addition to bounding the system design parameters, models can also be used to validate that the system requirements meet stakeholder needs before proceeding too far with later life cycle activities such as synthesizing the detailed system design.
- System design synthesis and requirements flowdown. Models can be applied to support architecting system solutions, and flow mission and system requirements down to system components. Different models may be required to address different aspects of the system design and respond to the broad range of system requirements. This may include models to specify functional, interface, performance, and physical requirements, and other non-functional requirements such as reliability, maintainability, safety, and security.
- Support for system integration and verification. Models can be applied to support integration of the hardware and software components into a system and to support verification that the system satisfies its requirements. This often involves integrating lower level hardware and software design models with system-level design models that verify system requirements are satisfied. System integration and verification may also include replacing selected hardware and design models with actual hardware and software products in order to incrementally verify that system requirements are satisfied. This is referred to as hardware- (glossary) and software-in-the-loop testing (glossary). Models can also be used to define the test cases (glossary) and the other aspects of the test program to assist in test planning and execution.
- Support for Training. Models can be used to simulate various aspects of the system to help train users on how to interact with the system. Users may be operators, maintainers, or potentially other stakeholders. Models may be a basis for developing a simulator of the system with varying degrees of fidelity to represent user interaction in different usage scenarios.
- Knowledge Capture and System Design Evolution. Models can provide an effective means for capturing knowledge about the system and retaining it as part of the organizational knowledge. This knowledge, which can be reused and evolved, provide a basis for supporting the evolution of the system, including changing requirements in the face of emerging relevant technologies, new applications, and new customers.
Indicators of an Effective Model
When modeling is done well, its purposes are clear and well-defined. The value of a model can be assessed in terms of how effectively it supports those purposes. Example indicators of model effectiveness are listed next. (Friedenthal, Moore, and Steiner 2009)
Model Scope
The model must be scoped to address the intended purpose. In particular, the type of models and associated modeling languages must be selected to support the specific needs. For example, suppose models are constructed to support an aircraft development. A system architecture model may describe the interconnection among the airplane parts; a trajectory analysis model may analyze the airplane trajectory, and a fault tree analysis model may assess potential causes of airplane failure.
For each type of model, the appropriate breadth, depth, and fidelity of the model should be determined to address the intended purpose. The model breadth reflects the system requirements coverage in terms of the degree to which the model must address the functional, interface, performance, and physical requirements and other non-functional requirements, such reliability, maintainability, and safety. For an airplane functional model, the model breadth may be required to address some or all of the functional requirements to power up, takeoff, fly, land, power down, and maintain the aircraft environment.
The model depth indicates the coverage of system decomposition from the system context down to the system components. For the airplane example, the model scope may be required to model the system context, ranging from the aircraft, the control tower and the physical environment, down to the navigation subsystem and its components, such as the inertial measurement unit, and perhaps down to lower-level parts of the inertial measurement unit.
The model fidelity indicates the level of detail the model must represent for any given part of the model. For example, a model that specifies the system interfaces may be fairly abstract and represent only the logical information content, such as aircraft status data, or it may be much more detailed to support higher fidelity information that includes the encoding of a message in terms of bits, bytes, and signal characteristics. Fidelity can also refer to the precision of a computational model, such as the time step required for a simulation.
Indicators of Model Quality
The quality of a model should not be confused with the quality of the design that the model represents. For example, one may have a high-quality computer-aided design model of a chair, which accurately represents the design of the chair. However, the design itself may be flawed, such that when one sits in the chair, it falls apart. A high quality model should assist the design team in assessing the quality of the design and uncovering design issues.
Model Quality is often assessed in terms of the adherence of the model to modeling guidelines and the degree to which the model addresses its intended purpose. Typical examples of modeling guidelines include naming conventions, application of appropriate model annotations, proper use of modeling constructs, and applying model reuse considerations. Specific guidelines are different for different types of models. For example, the guidelines for developing a geometric model using a computer-aided design tool may include conventions for defining coordinate systems, dimensioning, and tolerances.
Model-based Metrics
Models can provide a wealth of information that can be used for both technical and management metrics to assess the modeling effort and in some cases, the overall systems engineering effort. Different types of models will provide different types of information. In general, models can provide information that enables one to perform the following:
- Assess progress
- Estimate effort and cost
- Assess technical quality and risk
- Assess model quality
The models can be used to capture metrics that are similar to those captured in a traditional document-based approach to systems engineering, but potentially more precisely due to the more precise nature of models over documents. Traditional systems engineering metrics are described in Metrics Guidebook for Integrated Systems and Product Development.
Progress can be assessed in terms of the completeness of the modeling effort relative to the defined scope of the model. Models may also be used to assess progress in terms of the extent to which requirements have been satisfied by the design or verified through test. When augmented with productivity metrics, the model can be used to estimate the cost to perform the required systems engineering effort to deliver the system.
The models can be used to identify critical system parameters, and assess technical risk in terms of uncertainty in those parameters. The models may also be used to provide additional metrics that are associated with its purpose. For example, when the modeling purpose is to support mission and system concept formulation and evaluation, then a key metric may be the number of alternative concepts that are explored over a specified period of time.
References
Citations
Friedenthal, S., Moore, A. and Steiner, R. 2009. A Practical Guide to SysML: The Systems Modeling Language Chapter 2. Needham, MA, USA: OMG Press.
Wilbur, A., Towers, G., Sherman, T., Yasukawa, D. and Shreve, S. 2005. Metrics Guidebook for Integrated Systems and Product Development. Seattle, WA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-1995-002-01. Available at http://www.incose.org/ProductsPubs/products/metricsguidebook.aspx
Primary References
Friedenthal, S., Moore, A. and Steiner, R. 2009. A Practical Guide to SysML: The Systems Modeling Language Chapter 2. Needham, MA, USA: OMG Press.
Wilbur, A., Towers, G., Sherman, T., Yasukawa, D. and Shreve, S. 2005. Metrics Guidebook for Integrated Systems and Product Development. Seattle, WA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-1995-002-01. Available at http://www.incose.org/ProductsPubs/products/metricsguidebook.aspx
Additional References
None.
Article Discussion
Signatures
--Radcock 21:35, 10 August 2011 (UTC)
--Olwell 18 Aug 2011
--Lee 12:44, 22 August 2011 (UTC)