Model-based engineering (MBE)

Autores: Carlos Ordoñez, Elvis Burgos, Luis Villalta

Docente: Ing. Wilman Chamba Zaragocín
9 de diciembre de 2021

1. Resumen
Este ensayo analiza el estado actual de los procesos de Ingeniería de Sistemas Basada en Modelos (en
inglés Model-Based Systems Engineering, MBSE) que están siendo implementados, como porejemplo
en la industria aeronáutica. Los principios de esta filosofía de diseño son analizados para obtener todos
los beneficios que presenta frente a los proyectos tradicionales basados en documentos. Este nuevo
enfoque sustituye el núcleo de los proyectos de ingeniería de sistemas, reemplazando enormes
cantidades de documentación por modelos gráficos transversales. Esto ofrecerá muchas vistas
multidisciplinarias del sistema, brindando la información deseada que requieren todas las partes
interesadas, como ingenieros, gerentes o proveedores.

Actualmente el concepto de sistema se le atribuye a un conjunto organizado de elementos

interconectados, con el fin de lograr unos objetivos determinados. Dichos elementos pueden ser
agrupados en personas, productos y procesos, por lo que los miembros pertenecientes a un sistema
pueden ser hardware, software, datos, trabajadores, procedimientos, materiales o cualquier entidad
ambiental de la naturaleza, como puede ser un organismo o una masa de agua. Es por tanto un término
muy genérico, que describe una abstracción recursiva.

2. Introducción
Este concepto nace por la necesidad de estructurar metódicamente los sistemas complejos,
respondiendo inicialmente a una serie de preguntas, como cuales son los propósitos del sistema, como
se debe diseñar el sistema durante su proceso de desarrollo, cuáles son los límites de este, o que tipo
de organización industrial se debe poner en marcha para desarrollarlo. Para responder a estas
cuestiones, hasta hace escasos años han sido establecidos unos procesos bien definidos para recabar y
organizar todo el conocimiento. No obstante, no siempre se trata de una práctica absolutamente eficaz
y eficiente, por lo que aparece una nueva aproximación; ¿qué es la ingeniería de sistemas basada en
modelos?

Su finalidad principal es poder establecer una modificación en la fuente informativa que se utiliza en
el ciclo de vida de un sistema, donde a priori se utilizaba una documentación masificada e intervenían
diferentes actores. Pero ahora gracias a nuevas aproximaciones pueden estar unificadas en una única
fuente de verdad y servir como herramienta de comunicación a través de las múltiples fases de
desarrollo del producto.

Dentro de un modelo vamos a encontrar una serie de requisitos obtenidos a través de la documentación
establecida, esta documentación va a ser de utilidad para poder llevar a cabo la funcionalidad del
sistema que, por consiguiente, nos dará una serie de parámetros e información de diseño.
Posteriormente iremos modificando la arquitectura del modelo del sistema hasta dar con el enfoque
que más se aproxime al comportamiento del sistema real.

Por otro lado, es posible generar más documentos y de forma automática, sin tener dependencia directa
de un ingeniero en cuanto a la documentación se refiere. La fuente se creará de forma correcta al estar
acorde con el modelo que obtuvimos anteriormente. Es una forma de simplificar y acelerar el proceso
de documentación donde no tendremos que verificarlo continuamente, sino que se modificará
automáticamente en función a las relaciones establecidas, es decir a lo que se ha modelado con
anterioridad.

Las ventajas de emplear MBE son las siguientes [1]:

  Velocidad.
 El impacto-análisis concreto.
 Trazar los errores con exactitud.
 Centrarse en la arquitectura.
 Tener los documentos en una sola base de datos (por lo que va interrelacionado con el primer
punto).
 Punto de partida para los ingenieros para solucionar errores (interrelacionado con el punto
dos).

Siempre que se haga un modelo hay que tener presente que puede no ser veraz. De hecho, el modelo
nunca será la realidad en sí misma, tan solo una de sus múltiples interpretaciones. Sin embargo, sí que
es una herramienta útil a la hora de documentar y establecer conexiones con el objeto de estudio por
medio de diversos análisis. Es preciso tener en cuenta que un modelo siempre proporcionará una
información parcial de lo que será el sistema auténtico, por lo que podemos encontrar errores en la
interpretación real del modelo.

Es muy importante saber hasta qué punto se puede utilizar un modelo como fuente verificada, porque
hay un momento en el que no vale, en el que hace falta un producto tangible.

Aspectos de suma importancia en relación al modelo.

 Es un punto de partida.
 Es una ayuda para verificar que se pueda llevar a cabo el proyecto de manera concreta.
 Es una herramienta inexacta
 No se puede modelar todo, hay que elegir que se puede modelar y qué se puede aportar con
ese modelo.

Por ejemplo, muchas veces se invierte una cantidad enorme de dinero, tiempo y esfuerzo en generar
una serie de modelos para la interpretación real, sin embargo, como explicamos antes puede ser
inexacto (y lo será).

Otro ejemplo claro del error que se comete al modelar es que se tiende a creer que el modelo lo hará
todo. Un cliente podría confiar totalmente en las capacidades del modelo porque considere que está
bien y no es del todo cierto, ya que como se vio anteriormente sirve como supuesto.

3. Objetivos

 Analizar y describir la filosofía que emplea el Model based engineering, para comprender
como y cuando utilizar este modelo de software.
 Indagar y explicar cuáles son los componentes empleados en este modelo y las ventajas
al utilizar estos componentes.
 Explicar por qué y cuáles son los lenguajes de modelado que se emplea en este modelo.

4. Desarrollo
Estado Del Arte
4.1 Filosofía

En un principio, la construcción de un software se focalizaba fuertemente en la escritura de

código fuente compilable, asegurando que el programa resultante funcione cumpliendo los
objetivos esperados. Este método imposibilitaba la buena interacción y coordinación en
grandes grupos de trabajo para el desarrollo de software complejo y robusto, ya que el código
fuente resulta de difícil comprensión para quien no lo ha escrito, haciendo contraproducente
la inclusión o reemplazo de programadores. Resultando, además, de imposible lectura para
aquellos usuarios que no están familiarizados con la informática, lo cual dificultaba aún más
la participación activa multidisciplinaria durante el proceso de desarrollo del software.

A finales de la década de los 70, se planteó la idea de que un proyecto de software debía ser
encarado de la misma manera que cualquier otro propósito ingenieril, y para eso se tomó la
idea de “modelo” como parte fundamental del proceso de construcción de sistemas con alto
contenido de software y se definió un cuerpo de conocimientos englobado bajo el nombre de
Ingeniería de Software Basada en Modelos (conocido como MBE, por sus siglas en inglés).

Siguiendo una metodología de desarrollo basado en modelos, se debe comenzar con la

elaboración de un modelo que conceptualice de manera abstracta al problema, permitiendo un
análisis que posteriormente de lugar a un plan de implementación que contemple todo lo
aprendido del estudio de ese modelo. Para construir estos modelos se utilizan lenguajes
gráficos estándar. Si bien MBD solucionaba, de manera eficaz, algunos problemas en el
desarrollo de sistemas software, daba lugar a otros, como ser: dificultad de mantenimiento,
problemas de productividad, documentación y falta de flexibilidad a los cambios tecnológicos.

El objetivo es permitir la exploración del espacio de decisiones del proceso de la manera más
completa y eficaz posible, y respaldar las decisiones de diseño y operación con información
precisa.

MBE normalmente implica modelos de proceso de primeros principios de alta fidelidad

validados contra datos en el "ciclo de validación del modelo".

Figura 2: Ingeniería basada en modelos

MBE coloca los modelos predictivos de alta fidelidad en el centro del diseño de procesos o
del análisis operativo.

El esfuerzo inicial del proyecto se dedica a construir un modelo de alta fidelidad de la planta
o proceso que sea predictivo en todo el rango de interés. Luego, este modelo se utiliza para
optimizar el diseño o la operación, explorando un amplio espacio de diseño rápidamente y a
bajo costo, y aplicando técnicas de optimización para determinar las respuestas directamente
en lugar de mediante la simulación de prueba y error.

MBE se basa en tres enfoques principales:

  Modelado de primeros principios, donde todos los fenómenos relevantes se
describen a un nivel apropiado de representación de primeros principios de ingeniería
química. Por lo general, esto implica ecuaciones detalladas de transferencia de masa,
transferencia de calor y reacción.
 Modelado multiescala, donde se tienen en cuenta fenómenos en todas las escalas
relevantes. El diagrama de la derecha muestra, por ejemplo, las escalas que deben
tenerse en cuenta para un reactor multitubular. Los fenómenos que ocurren a
microescala en un poro de catalizador pueden tener una influencia significativa en el
diseño global del reactor (macroescala).
 Integración con datos experimentales, mediante la aplicación de un enfoque de
experimentación dirigido al modelo para refinar el modelo y al mismo tiempo
maximizar la efectividad del programa experimental.
4.2 Componentes

Capella. - Es una herramienta MBSE de código abierto que implementa el método Arcadia.
Es una solución MBSE completa, escalable y probada, enfocada en el diseño de arquitecturas
de sistemas. Capella está fuertemente influenciada por las prácticas actuales y las
preocupaciones de los ingenieros de sistemas y puede ser dominada fácilmente por aquellos
que conocen el lenguaje SysML.

Enterprise Architect. - Es una herramienta que, junto con MDG Technology para dar soporte
a través del modelado en SysML, ofrece capacidades avanzadas de modelado a bajo coste.
Este software permite especificar los requisitos del sistema, diseñar su estructura y la de sus
subsistemas por medio de bloques y diagramas de bloques, analizar su comportamiento
haciendo uso de diagramas de actividad, interacción y estado, y permite también definir la
dinámica del sistema aplicando restricciones con los bloques paramétricos de corrección.

IBM Rational Rhapsody Developer: es un entorno de modelado gráfico que aparte de dar
soporte con los lenguajes de modelado SysML, UML y Autosar, también tiene la flexibilidad
para operar con un lenguaje específico de dominio. Los puntos fuertes de esta herramienta son
su capacidad de detectar defectos durante el ciclo de vida del producto, mediante la inyección
de fallos que se pueden producir en el sistema, optimizar la comunicación entre los equipos o
automatizar el desarrollo de software. Permite simular los diseños y arquitecturas creadas para
probar su validez antes de que sea posible integrarlo en el hardware.

System Composer: Dentro de los productos pertenecientes al catálogo ofertado por

Mathworks, encontramos System Composer, una nueva toolbox enfocada al análisis de
software y arquitectura de sistemas. Su potencia reside en que admite el diseño de
arquitecturas, con la posibilidad de detallar lógicas a más bajo nivel, y simularlas a través del
eficaz motor de simulación de Simulink, con la posibilidad de generar código en C o C++.

Cameo: Systems Modeler es un entorno de ingeniería de sistemas basados en modelos

(MBSE) colaborativo multiplataforma líder en la industria, que proporciona herramientas
inteligentes, robustas e intuitivas para definir, rastrear y visualizar todos los aspectos de los
sistemas en los modelos SysML. Al haber seleccionado su metodología asociada MagicGrid.

4.3 Lenguajes de modelado utilizado

4.3.1 Lenguaje SysML
Este lenguaje es una evolución de UML 2.0, al que añade extensiones que aportan un
mayor número de funcionalidades y que tiene como principales capacidades especificar,
analizar, diseñar y verificar sistemas complejos. Puede aportar datos de todo tipo, desde
hardware y software hasta información del personal, procedimientos e instalaciones.
 Figura 1: Diagrama SysML

Los diagramas utilizados son los siguientes:

 Diagrama de requisitos
Están formados por bloques que representan requisitos basados en texto. Con la
finalidad de mejorar la trazabilidad muestra sus relaciones con elementos de diseño,
otros requisitos y casos de prueba.
 Diagrama de estructura
Indican la composición estructural, interconexiones o clasificación del sistema de
interés. A este conjunto pertenecen los siguientes:
o Diagrama de definición de bloques: Proveen el diseño de la estructura del
sistema, mostrando la composición de los bloques. Las interfaces son
modeladas como puertos en dichos bloques.
o Diagrama interno de bloques: Representan las interconexiones dentro de
un bloque. Hay un caso especial de este tipo de diagramas denominado
Diagrama paramétrico, que se emplea para modelar las restricciones en los
valores de propiedad de los bloques. Este tipo de diagramas son un fuerte
apoyo para el análisis de ingeniería, pues muestran ecuaciones para
relacionar diferentes variables físicas.
o Diagrama de paquetes Indica la organización del modelo en carpetas que
contienen sus elementos.
 Diagrama de comportamiento
Se emplean para establecer las funcionalidades del sistema por medio del análisis de
escenarios, en los que se suceden actividades consecutivamente. A este conjunto
pertenecen los siguientes:
o Diagrama de actividad: Plasma el comportamiento del sistema ordenando
las acciones que se tienen que ejecutar, transformando inputs en outputs.
o Diagrama de secuencia: Presenta el intercambio de mensajes en un
escenario concreto entre las distintas partes del sistema.
o Diagrama de máquina de estados: Muestra las transiciones, provocadas
por eventos, entre estados de una entidad del sistema.
o Diagrama de casos de uso: Identifica las capacidades funcionales que debe
tener el sistema, así como su interacción con las entidades externas.

4.4 Información Adicional

Ciclo en V. - El modelo de ciclo de vida de desarrollo más extendido en la industria
relacionada con la ingeniería de sistemas es el ciclo en V. Los procesos de verificación y
validación cubren desde la identificación de las actividades a llevar a cabo, el plan y la
ejecución detallados de estas actividades, así como la responsabilidad que les corresponde, y
el registro de todos los datos generados durante el desarrollo. Estos procesos son únicamente
 aplicables a requisitos técnicos de productos que tienen impacto directo en la forma o función
del producto final.

Figura 3: Ciclo de verificación y validación

Proceso de validación. - En primer lugar, el proceso de validación de requisitos ofrece una
aproximación rigurosa para asegurar que todos requisitos técnicos del producto han sido
cubiertos y que toda la información sobre la trazabilidad y otras evidencias de validación han
quedado registradas. Se determina si los requisitos del producto son correctos y completos,
correspondiendo con las necesidades del cliente.

Proceso de verificación. - Por otro lado, el diseño de actividades de verificación muestra que
el diseño cumple con todos los requerimientos y contribuye a reducir el riesgo de que el diseño
no funcione de forma apropiada cuando el producto físico sea verificado. Tienen un papel
muy importante en demostrar la madurez del producto. En otras palabras, se realiza una
evaluación de la implementación para comprobar que se han satisfecho los requisitos.

4.5 Aplicación de ingeniería de sistemas basado en modelos en un sistema de

aviónica

De acuerdo con la metodología MBSE, el modelo se utiliza para describir el diseño de nivel
superior del sistema electrónico, de modo que los resultados del diseño y el desarrollo se
puedan reutilizar en diferentes etapas y se pueda realizar una transición sin problemas de cada
etapa:

 Garantice la coherencia del diseño, evite el trabajo repetitivo y mejore la eficiencia

del trabajo
 Ayude a los ingenieros a deshacerse del trabajo tedioso y trivial como la escritura de
códigos y la depuración de bajo nivel, y concentrarse en el diseño del sistema
 Continúe verificando el diseño durante el proceso de diseño para asegurarse de que
el diseño sea correcto y confiable

1. Plan General
El flujo general del diseño MBSE y la verificación del sistema de aviónica se muestra en
la siguiente figura:
 Figura 4: MBSE en sistema de aviónica

El flujo de trabajo del diseño MBSE y la verificación del sistema de aviónica se puede
dividir aproximadamente en tres etapas: etapa de diseño y verificación de análisis de
requisitos y funciones, etapa de diseño y verificación de la arquitectura lógica y
descomposición funcional, interfaz de subsistema y etapa de diseño y verificación de
funciones. En cada etapa de verificación del diseño, se ejecuta la verificación del diseño
y la verificación basada en el modo V.

♦ Diseño de requisitos y análisis de funciones y etapa de verificación: En la etapa de

diseño y verificación de análisis de requisitos y funciones, los diseñadores realizan
principalmente análisis de requisitos en el sistema de aviónica. Después del análisis de
casos de uso y análisis de escenarios, se obtienen las principales funciones y
comportamientos del sistema. Este proceso de análisis se puede verificar a través de la
simulación de datos para garantizar que el sistema esté La precisión del análisis de
comportamiento.

♦ Descomposición funcional y diseño de arquitectura lógica y fase de verificación:

Después de completar los requisitos del sistema y el análisis de la función, en función de
los resultados del análisis de la etapa anterior, las funciones del sistema se descomponen
sobre la base de la arquitectura del sistema a través de la asignación de funciones, y cada
realización de la función se asigna a los diversos módulos dentro del sistema para definir
los componentes del sistema. Los requisitos funcionales.

Basado en la arquitectura lógica del sistema, diseñe el contenido específico de los

módulos del sistema, refine la lógica interna y los algoritmos del modelo del sistema,
complete el diseño DD y coopere con los métodos de verificación de simulación para
garantizar la exactitud y la coherencia de los resultados del diseño.

♦ Interfaz del subsistema y diseño de funciones y etapa de verificación: Sobre la base

de completar el diseño a nivel de sistema y pasar la verificación, continúe refinando el
modelo del sistema de aviónica, diseñe el tipo de bus y la interfaz de bus entre cada
sistema electrónico y asigne las variables interactivas entre los sistemas a la interfaz ICD
entre cada sistema Y siga el principio de diseño iterativo y simulación para la verificación
de simulación.

Sobre la base de completar el diseño y la aceptación a nivel de interfaz, admite el uso de

métodos de simulación en tiempo real para migrar cada modelo de simulación al servidor
de simulación principal, utilizando la interfaz de ejecución POP y la interfaz de monitoreo
 de simulación, y controlando los modelos de simulación en tiempo real a través de
Ethernet de alta velocidad. El equipo dedicado de recolección y monitoreo del bus se
enfrenta directamente al bus físico real y realiza la recolección, análisis, visualización,
almacenamiento, reproducción y otras operaciones en tiempo real de los datos
transmitidos en el bus, y verifica el cumplimiento del diseño y los requisitos de la interfaz
de datos externa.

2. Característica principal
La plataforma de diseño y verificación de MBSE del sistema de aviónica se basa en el
método de ingeniería de sistemas de Harmony, y la herramienta Rhapsody se utiliza como
plataforma de diseño y desarrollo de nivel superior.

Figura 5: La plataforma de diseño y verificación de MBSE

Basado en el método de ingeniería del sistema Harmony, con requisitos como la entrada
de diseño básica, a través del diseño de caja negra y el diseño de caja blanca, use
diagramas de casos, diagramas de actividad, diagramas de secuencia y otros métodos de
diseño para lograr el diseño y la descomposición de la arquitectura funcional del sistema,
y en el proceso de diseño Usando la tecnología de generación de código de Rhapsody, la
verificación de simulación digital se realiza en la plataforma Windows. En el proceso de
diseño, puede interactuar con las herramientas de diseño de ICD y las herramientas de
diseño de POP. A través de la interacción del archivo de datos, el proceso de diseño de
ICD, DD y POP se puede integrar para garantizar la coherencia del diseño.

Además de proporcionar información para el diseño detallado, los resultados de diseño

de nivel superior también se pueden reutilizar en el proceso de prueba de la etapa de
integración del sistema para integrarse perfectamente con la solución de prueba de
integración del sistema de aviónica. El sistema de simulación y el sistema de entrada /
salida en la fase de prueba integrada pueden reutilizar la fase de diseño de nivel superior
y el modelo de simulación y la interfaz de datos para proporcionar soporte para la
verificación de la función del sistema.

5. Conclusión

 El trabajo realizado ha servido para llevar a la práctica los procesos que debe tomar un equipo
de ingeniería de sistemas para poder recrear la representación más precisa y cercana a la
realidad del sistema de interés.
  Cuando se emplea esta metodología los clientes pueden elegir productos y servicios
individuales, o un programa personalizado completo, para ponerse al día rápidamente con un
enfoque que satisfaga sus necesidades únicas.
 MBSE utiliza un marco integrado de herramientas de ingeniería y fuentes de datos existentes,
centrado en un modelo central.

6. Referencias

[1] International Standard - Systems and software engineering System life cycle processes,
ISO/IEC/IEEE std 15288-2008

[2] INCOSE, Systems Engineering Handbook. A Guide for System Life Cycle for Activities and
Processes, 4ª ed., San Diego, CA, USA, 2015

[3] Nicole Viola, Sabrina Corpino, Marco Fioriti y Fabrizio Stesina, “Functional Analysis in Systems
Engineering: Methodology and Applications” en Systems Engineering - Practice and Theory,
InTech, 2012 Available from: http://www.intechopen.com/books/systemsengineering-practice-
andtheory/functional-analysis-in-systems-engineering-methodology-and-applications

[4] Lui Wang et al., “Effort to Accelerate MBSE Adoption and Usage at JSC”, NASA Johnson Space
Center, Houston, TX, USA y Tietronix Software, Inc., Houston, TX, USA, 2016

[5] SRI International and the University of Michigan, “Applying Model Based Systems Engineering
(MBSE) to a Standard CubeSat”, USA, 2012

[6] Aiste Aleksandraviciene y Aurelijus Morkevicius, Ph.D., MagicGrid Book of Knowledge. A

Practical Guide to Systems Modeling using MagicGrid from No Magic, Kaunas, Lituania: Vitae
Litera, 2018