Difference between revisions of "Types of Models"

From SEBoK
Jump to navigation Jump to search
Line 95: Line 95:
  
 
[[{{TALKPAGENAME}}|[Go to discussion page]]]
 
[[{{TALKPAGENAME}}|[Go to discussion page]]]
<center>[[Why Model?|<- Previous Article]] | [[Representing Systems with Models|Parent Article]] | [[System Modeling Concepts|Next Article ->]]
+
<center>[[Why Model?|<- Previous Article]] | [[Representing Systems with Models|Parent Article]] | [[System Modeling Concepts|Next Article ->]]</center>
 +
==Signatures==
 
[[Category:Part 2]][[Category:Topic]]
 
[[Category:Part 2]][[Category:Topic]]

Revision as of 19:07, 9 August 2011

This section introduces a classification for the many different types of models, and highlights how different models must work together to support the broader engineering effort.

Model Classification

There are many different types of models and associated modeling languages to address different aspects of a system. Since different models serve different purposes, a classification of models can be useful for selecting the right type of model for the intended purpose and scope.

Formal versus Informal Models

Since a system model is a representation of a system, many different expressions that vary in degrees of formalism could be considered models. In particular, one could draw a picture of a system and consider it a model. Similarly, one could write a description of a system in text, and refer to that as a model. Both examples are representations of a system. However, unless there is some agreement on the meaning of the terms, there is a potential lack of precision and ambiguity in the representation.

The primary focus of system modeling is on the use of models supported by a well-defined modeling language . While less formal representations can be useful, there are certain expectations of a model for it to be considered within the scope of MBSE. In particular, the initial classification distinguishes between informal models, and more formal models supported by a modeling language with a defined syntax and semantics for the domain of interest.

Physical Models versus Abstract Models

The DoD 5000.59 -M 1998 definition [1] of a model asserts that, “a model can be physical, mathematical, or otherwise logical representation of a system”. This definition provides a starting point for a high level model classification. A physical model is a concrete representation that is distinguished from the mathematical and logical models which are more abstract representations of the system. The abstract model can be further classified as descriptive (similar to logical) or analytical (similar to mathematical). Some example models are shown in Figure 1 (to be updated).

Typical Models

Descriptive Models

A descriptive model describes the logical relationships such as the systems whole-part relationship that defines its parts tree, the interconnection between its parts, the functions that its components perform, or the test cases that are used to verify the system requirements. Typical descriptive models may include models that describe the system architecture, or computer aided design models that describe the three dimensional geometric representation of a system.

Analytical Models

An analytical model describes mathematical relationships such as differential equations that support quantifiable analysis about the system parameters. The analytical models can be further classified into static and dynamic models. Dynamic models describe the time-varying state of a system, whereas static models perform computations that do not represent the time varying state of a system. A static model may represent the mass properties calculation or a reliability prediction, where-as a dynamic model may represent the performance of a system, such as the aircraft position, velocity, acceleration, and fuel consumption over time.

Hybrid Descriptive and Analytical Models

A particular model may include descriptive aspects and analytical aspects as described above, but most models tend to emphasize support for one or the other. It should be noted that the logical relationships of a descriptive model can also be analyzed, and inferences can be made from reasoning about the system, but the logical analysis provides different insights than a quantitative analysis of the system parameters.

Domain-specific models

Both descriptive and analytical models can be further classified according to the domain that they represent. The following classification is partially derived from the presentation on OWL, Ontologies and SysML Profiles: Knowledge Representation and Modeling (Jenkins and Rouquette 2010):

  • properties of the system, such as reliability, mass properties, power, structural, or thermal models.
  • design and technology implementations such as electrical, mechanical, and software design models.
  • subsystems and products, such as communications, fault management, or power distribution models.
  • system applications such as information system, automotive system, aerospace system, or medical device models.

A single model may include multiple domain categories from above. For example, a reliability, thermal, and/or power model may be defined for an electrical design of a communications subsystem for an aerospace system such as an aircraft or sattelite.

System Models

System models can be hybrid models that are both descriptive and analytical. They often span several modeling domains that must be integrated to ensure a consistent and cohesive system representation. As such, the system model must provide both general purpose system constructs and domain-specific constructs that are shared across modeling domains.

According to wikipedia [2], a system model is the conceptual model that describes and represents a system. A system comprises multiple views such as planning, requirement (analysis), design, implementation, deployment, structure, behavior, input data, and output data views. A system model is required to describe and represent all these multiple views.

One of the original efforts to formally define a system model using a mathematical framework was developed by Wayne Wymore and documented in his book entitled Model-Based Systems Engineering: An Introduction to the Mathematical Theory of Discrete Systems and to the Tricotyledon Theory of System Design . This approach establishes a rigorous mathematical framework for designing systems in a model-based context. A summary of his work can be found in the A Survey of Model-Based Systems Engineering (MBSE) Methodologies.

Simulation versus Model

The term simulation, or more specifically computer simulation , refers to an analytical model that can be executed by a computing infrastructure. The computer simulation includes the analytical model and the computing infrastructure, as well as the initial conditions required to execute the model. There are many different types of computer simulations. According to wikipedia [3], computer simulations can be characterized based on the following characteristics:

  • Stochastic or deterministic
  • Steady-state or dynamic
  • Continuous or discrete
  • Local or distributed

Simulations may often be integrated with actual hardware, software, and operators of the system, to evaluate how actual components and users of the system perform in a simulated environment.

In addition to representing the system and its environment, the simulation must provide efficient computational methods for solving the equations. Simulations may be required to operate in real time, particularly if there is an operator in the loop. Other simulations may be required to operate much faster than real time, and perform thousands of simulation runs to provide statistically valid simulation results. Several computational and other simulation methods are described in Simulation Modeling and Analysis.

Visualization

Computer simulation results and other analytical results often need to be processed so they can be presented to the users in a meaningful way. Visualization techniques and tools are used to display the results in various visual forms. Examples include parametric relationships that may include a simple plot of the state of the system versus time, or the input and output values from several simulation executions that are displayed on a response surface showing the sensitivity of the output to the input. Additional statistical analysis of the results may be performed to provide probability distributions for selected parameter values. Animation is often used to provide a virtual representation of the system and its dynamic behavior, such as displaying aircraft three-dimensional position and orientation as a function of time, and a projection of its path on the surface of the earth represented by detailed terrain maps.

Integration of Models

Many different types of models may be developed as artifacts of a model-based systems engineering effort. Many other domain specific models are created for component design and analysis. The different descriptive and analytical models must be integrated in order to fully realize the benefits of a model-based approach. The role of MBSE to integrate across multiple domains is a primary theme in the INCOSE Systems Engineering Vision 2020.

As an example, system models can be used to specify the components of the system. The descriptive model of the system architecture may be used to identify and partition the components of the system, and define their interconnection and other relationships. Analytical models for performance, physical and other quality characteristics, such as reliability, may be employed to determine the required values for specific component properties to satisfy the system requirements. An executable system model that represents the interaction of the system components may be used to validate that the component requirements can satisfy the system behavioral requirements. The descriptive, analytical and executable system model must ensure they represent different facets of the same system.

The component designs must satisfy the component requirements that are specified by the system models. As a result, the component design and analysis models must have some level of integration to ensure the design model is traceable to the requirements model. The different design disciplines for electrical, mechanical and software each create their own models that represent different facets of the same system as well. It is evident that the different models must be sufficiently integrated to ensure a cohesive system solution.

In order to support the integration, the models must establish semantic interoperability to ensure that a construct in one model has the same meaning as a corresponding construct in another model. In addition to semantic interoperability for models to share common definitions when referring to the same thing, the information must also be exchanged from one modeling tool to another.

An approach to achieve semantic interoperability is to use model transformations between different models. This approach defines a transformation to establish correspondence between the concepts in one model and the concepts in another. In addition to establishing correspondence, the tools must have a means to exchange the model data in order to share the information. There are multiple means for exchanging data between tools including file exchange, use of application program interfaces (API), and a shared repository.

The use of modeling standards for modeling languages, model transformations, and data exchange, is an important enabler to achieve integration across modeling domains.

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

[1] DoD Directive 5000.59. DoD Modeling and Simulation (M&S) Management. January 4, 1994.

[2] Wikipedia. System Model. Available at http://en.wikipedia.org/wiki/System_model

[3] Wikipedia. Computer simulation. Available at http://en.wikipedia.org/wiki/Computer_simulation#Types

Primary References

Law, A. 2007. Simulation Modeling & Analysis. Fourth Edition. McGraw Hill

Wymore, A.W. 1993. Model-Based Systems Engineering. CRC Press, Inc. Boca Raton, FL.

Additional References

Jenkins, S, Rouquette. 2010. OWL, Ontologies and SysML Profiles:Knowledge Representation and Modeling May 2010 NASA- ESA PDE Workshop. Available at http://www.congrex.nl/10m05post/presentations/pde2010-Jenkins.pdf

Estefan, J, 2008. A Survey of Model-Based Systems Engineering (MBSE) Methodologies. INCOSE-TD-2007-003-02 dated 5/23/2008. Available at http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf

INCOSE 2007. Systems Engineering Vision 2020. INCOSE-TP-2004-004-02 September, 2007. Available at http://www.incose.org/ProductsPubs/products/sevision2020.aspx

Wikipedia. Computer simulation. Available at http://en.wikipedia.org/wiki/Computer_simulation#Types


Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures