Types of Models - SEBOK (24)

There are many different types of models (glossary) expressed in a diverse array of modeling languages and tool sets. This article offers a taxonomy of model types and highlights how different models must work together to support broader engineering efforts.

Model Classification

There are many different types of models and associated modeling languages to address different aspects of a system and different types of systems. 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 the possibility of ambiguity in the representation. The primary focus of system modeling is to use models supported by a well-defined modeling language. While less formal representations can be useful, a model must meet certain expectations for it to be considered within the scope of model-based systems engineering (MBSE). In particular, the initial classification distinguishes between informal and formal models as supported by a modeling language with a defined syntax and the semantics for the relevant domain of interest.

Physical Models versus Abstract Models

The United States “Department of Defense Modeling and Simulation (M&S) Glossary” asserts that “a model can be [a] physical, mathematical, or otherwise logical representation of a system” (1998). 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, both of 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).

Descriptive Models

A descriptive model describes logical relationships, such as the system's 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 those that describe the functional or physical architecture of a system, or the three dimensional geometric representation of a system.

Analytical Models

An analytical model (glossary) describes mathematical relationships, such as differential equations that support quantifiable analysis about the system parameters. Analytical models can be further classified into dynamic and static 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 dynamic model may represent the performance of a system, such as the aircraft position, velocity, acceleration, and fuel consumption over time. A static model may represent the mass properties estimate or reliability prediction of a system or component.

Hybrid Descriptive and Analytical Models

A particular model may include descriptive and analytical aspects as described above, but models may favor one aspect or the other. The logical relationships of a descriptive model can also be analyzed, and inferences can be made to reason about the system. Nevertheless, logical analysis provides different insights than a quantitative analysis of system parameters.

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. A system model may comprise multiple views to support planning, requirements, design, analysis, and verification.

Integration of Models

Many different types of models may be developed as artifacts of a MBSE 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 as the models integrate across multiple domains is a primary theme in the International Council on Systems Engineering (INCOSE) INCOSE Systems Engineering Vision 2020 (2007).

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 or 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 each 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 that the design model is traceable to the requirements model. The different design disciplines for electrical, mechanical, and software each create their own models representing different facets of the same system. It is evident that the different models must be sufficiently integrated to ensure a cohesive system solution.

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. This information must also be exchanged between modeling tools. One approach to semantic interoperability is to use model transformations between different models.

Transformations are defined which 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 and share the transformation 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 of integration across modeling domains.

System Model - SEBOK (23)

System models can be used for many purposes. This topic highlights some of those purposes, and provides indicators of an effective model, in the context of model-based systems engineering (MBSE).

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, verification, and validation of a system, as well as to communicate certain 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

• Characterizing an existing system.

• Mission and system concept formulation and evaluation

• System design synthesis and requirements flowdown

• Support for system integration and verification

• Support for training

• Knowledge capture and system design evolution

Indicators of an Effective Model

When modeling is done well, a model’s purposes are clear and well-defined. The value of a model can be assessed in terms of how effectively it supports those purposes. The remainder of this section and the topics Types of Models, System Modeling Concepts, and Modeling Standards describe indicators of an effective model (Friedenthal, Moore, and Steiner 2009).

Model Scope

The model must be scoped to address its intended purpose. In particular, the types of models and associated modeling languages selected must support the specific needs to be met. For example, suppose models are constructed to support an aircraft’s 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 should be determined to address the model’s 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, as well as other non-functional requirements, such as 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’s environment.

The model’s depth indicates the coverage of system decomposition from the system context down to the system components. For the airplane example, a model’s scope may require it to define 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’s 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, such as 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 that accurately represents the design of the chair, yet the design itself may be flawed such that when one sits in the chair, it falls apart. A high quality model should provide a representation sufficient to 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.

Integración de un ERP (1/2) (47)

Las soluciones que ofrece una empresa pretenden integrar “desde el tablero de control hasta la mesa de dirección”... y más allá: también aspiran a unir una cadena de valor desde el cliente del cliente hasta el proveedor del proveedor. No obstante, tal pretensión presenta varios obstáculos, por lo que la integración debe de trabajarse por niveles.

El primer problema que se busca resolver con la integración es comunicar el software A con el B mediante la homologación de sus códigos.

El segundo obstáculo a superar es integrar procesos, sin importar los sistemas que se usen. Los procesos deben ser transparentes, más allá de los códigos comunes. Con ese propósito, la empresa desarrolló un producto, a través del cual se pueden “mapear” los procesos, independientemente de las herramientas que estén interviniendo.

El tercer escollo a eliminar es la integración de la información. Además de que el software y los procesos estén integrados, es preciso que los directores tengan esa información en su mesa. Con el objetivo de poner disponible los datos de los diferentes procesos en un lugar único, se crea el portal de la empresa. De ese modo, el personal no tiene que entrar a las aplicaciones individuales para ver sus resultados.

El último paso de la integración se refiere al manejo productivo de los datos con los que se cuentan. Para la empresa, el final de la colaboración está englobado en su solución de Business Intelligence, que es una base de datos que captura la operación de todos los sistemas en una herramienta única de información, en tiempo real. El enorme énfasis que ha puesto la empresa en la integración se ha convertido en su ventaja competitiva.

Otra de sus ventajas competitivas es, sin duda, la velocidad del ERP para salir de la crisis. El pasado mes, la firma de este ERP estaba al borde la quiebra; ninguno de sus potenciales clientes querían escuchar las ventajas de sus nuevos productos y la competencia pensaba que ya era uno menos. Sin embargo, en esta era de competencia (una mezcla de colaboración y competencia), las firmas de software integrador tendrán que acostumbrarse a tomar en cuenta a la empresa de ERP.

Tres consultores ingleses describieron la implementación de un ERP como el equivalente a hacerse un tratamiento de conducto: es muy doloroso; es caro y a veces es preferible no hacerlo, aunque los especialistas digan que será mejor.

El ERP es un hueso duro de roer y a través de los años hay una buena cantidad de proyectos fallidos. Muchos de estos pueden atribuirse a fallas en uno o varios de los siete hábitos para una implementación exitosa. Se trata de hábitos porque muchos de los problemas subyacentes están relacionados con dificultades para afrontar cuestiones culturales dentro de la organización.

Las personas están acostumbradas a trabajar con métodos viejos y quieren continuar con esas formas. Están habituados a trabajar con datos inapropiados, fechas inválidas del sistema y otras ineficiencias. Mucha gente prefiere la informalidad a la formalidad. Tienen ciertos vicios. ¿Por qué cambiar estos hábitos a esta altura de la vida?

La implementación de un ERP trae consigo la necesidad de adoptar mayor formalidad en el trabajo y la adhesión a más procesos de los que la gente está acostumbrada. La verdad es que el mundo es más global, más competitivo y cambia muy rápido. Y en este contexto las empresas necesitan integrarse tanto en los negocios como en los países, industrias y culturas para poder sobrevivir.