1.

Introducción

• 1.1 ¿Qué es MBSE?

o Definición: MBSE (Model-Based Systems Engineering) es un enfoque de la

ingeniería de sistemas que utiliza modelos como artefacto principal a lo
largo del ciclo de vida del sistema, desde la concepción hasta el retiro. A
diferencia del enfoque tradicional basado en documentos, MBSE se
centra en la creación y gestión de modelos digitales integrados que
representan los diferentes aspectos del sistema.

o Principios:

▪ Modelos como fuente única de verdad: El modelo del sistema es

la referencia autorizada para todas las decisiones de diseño y
desarrollo.

▪ Abstracción y formalismo: Los modelos utilizan un lenguaje

formal (como SysML) para representar el sistema en diferentes
niveles de abstracción.

▪ Trazabilidad y consistencia: Los modelos mantienen relaciones

de trazabilidad entre los diferentes elementos del sistema,
asegurando la consistencia entre los requisitos, el diseño, el
análisis y las pruebas.

▪ Automatización: Las herramientas de software se utilizan para

automatizar tareas como la generación de documentación, la
verificación de la consistencia y la simulación del comportamiento
del sistema.

o Evolución desde el enfoque basado en documentos: Comparación con

el enfoque tradicional, destacando las limitaciones de la documentación
en papel (ambigüedad, inconsistencia, dificultad de mantenimiento) y
cómo MBSE las supera.

• 1.2 Beneficios de MBSE

o Mejora de la comunicación: Los modelos proporcionan un lenguaje

común y una representación visual del sistema que facilita la
comunicación entre las partes interesadas (stakeholders).

o Gestión de la complejidad: MBSE ayuda a descomponer sistemas

complejos en partes más manejables y a comprender las interrelaciones
entre ellas.

o Detección temprana de errores: Los modelos permiten identificar y

corregir errores en las etapas iniciales del desarrollo, cuando el costo de
corrección es menor.

o Reducción del tiempo y costo de desarrollo: La automatización y la

reutilización de modelos pueden acelerar el proceso de desarrollo y
reducir los costos.
 o Mejora de la calidad y la confiabilidad: La verificación formal y la
simulación del comportamiento del sistema contribuyen a mejorar su
calidad y confiabilidad.

o Facilita la reutilización: Los modelos se pueden reutilizar en proyectos

similares, reduciendo el esfuerzo de desarrollo.

o Soporte para la toma de decisiones: Los modelos proporcionan una

base sólida para la toma de decisiones informadas sobre el diseño y la
arquitectura del sistema.

• 1.3 ¿Qué es SysML?

o Definición: SysML (Systems Modeling Language) es un lenguaje de

modelado gráfico estándar para la ingeniería de sistemas, basado en UML
(Unified Modeling Language) pero extendido para cubrir las necesidades
específicas de los sistemas.

o Desarrollo y estandarización: Historia del desarrollo de SysML por el

OMG (Object Management Group) e INCOSE (International Council on
Systems Engineering).

o Características principales:

▪ Diagramas: SysML define nueve tipos de diagramas para modelar

diferentes aspectos del sistema (estructura, comportamiento,
requisitos, paramétricos).

▪ Perfil de UML: SysML es un perfil de UML, lo que significa que

hereda y extiende la semántica de UML.

▪ Extensiones para sistemas: SysML incluye extensiones

específicas para la ingeniería de sistemas, como el modelado de
requisitos y paramétricos.

▪ Soporte para MBSE: SysML es un lenguaje clave para la

implementación de MBSE, ya que permite crear modelos formales
del sistema.

• 1.4 Introducción al Grid MBSE

o Concepto: El Grid MBSE es una matriz estructurada que organiza los

diferentes aspectos del sistema y los relaciona con los niveles de
abstracción. Actúa como un mapa que guía el proceso de modelado y
facilita la trazabilidad entre los diferentes artefactos del modelo.

o Propósito:

▪ Organizar la información: Proporcionar una estructura para

organizar los diferentes modelos y artefactos del sistema.

▪ Facilitar la navegación: Permitir a los ingenieros navegar

fácilmente a través de los diferentes aspectos y niveles de
abstracción del sistema.
 ▪ Asegurar la completitud: Ayudar a identificar lagunas o
inconsistencias en el modelo del sistema.

▪ Mejorar la comunicación: Proporcionar una visión general del

sistema que facilita la comunicación entre las partes interesadas.

o Relación con SysML: El Grid MBSE se utiliza en conjunto con SysML para
organizar y relacionar los diferentes diagramas SysML que se crean
durante el proceso de desarrollo del sistema.

• 1.5 Alcance de la Guía

o Objetivos: Definir claramente lo que la guía pretende enseñar al lector.

o Público objetivo: Especificar el perfil del lector al que está dirigida la guía
(ingenieros de sistemas, arquitectos de sistemas, etc.).

o Contenido: Resumen de los temas que se cubrirán en cada sección de la

guía.

o Limitaciones: Aclarar cualquier aspecto que no se vaya a cubrir en la guía.

2. Fundamentos de MBSE y SysML

• 2.1 Principios de MBSE

o Modelos como artefacto principal: Explicación detallada de cómo los

modelos se convierten en el centro del proceso de desarrollo.

o Abstracción y formalismo: Importancia de utilizar diferentes niveles de

abstracción para gestionar la complejidad y la necesidad de un lenguaje
formal (como SysML) para evitar ambigüedades.

o Trazabilidad y consistencia: Cómo se establecen y mantienen las

relaciones de trazabilidad entre los diferentes elementos del modelo para
asegurar la consistencia.

o Automatización: Ejemplos de cómo se pueden automatizar tareas como

la generación de documentación, la verificación de la consistencia y la
simulación del comportamiento del sistema.

o Colaboración: Cómo MBSE facilita la colaboración entre los miembros

del equipo y las diferentes disciplinas involucradas en el desarrollo del
sistema.

o Iteración e incrementalidad: Cómo MBSE se puede integrar con

metodologías ágiles para un desarrollo iterativo e incremental.

• 2.2 Conceptos Clave de SysML

o 2.2.1 Diagramas de Estructura (BDD, IBD, PKG)

▪ Diagrama de Definición de Bloques (BDD):

 ▪ Propósito: Definir los bloques que componen el sistema,
sus propiedades (atributos, operaciones) y las relaciones
entre ellos (asociación, generalización, composición).

▪ Elementos: Bloques, Puertos, Flujos de Ítems,

Asociaciones, Generalizaciones, Composiciones,
Realizaciones.

▪ Ejemplo: Definir los bloques de un sistema de control de

temperatura (sensor, controlador, actuador) y sus
propiedades.

▪ Diagrama de Bloques Internos (IBD):

▪ Propósito: Describir la estructura interna de un bloque,

mostrando cómo se conectan sus partes y cómo fluye la
información o la energía entre ellas.

▪ Elementos: Partes, Puertos, Conectores, Flujos de Ítems.

▪ Ejemplo: Mostrar cómo se conectan los componentes

internos de un controlador de temperatura
(microprocesador, memoria, interfaz de comunicación).

▪ Diagrama de Paquetes (PKG):

▪ Propósito: Organizar los elementos del modelo en

paquetes y definir las dependencias entre ellos.

▪ Elementos: Paquetes, Dependencias, Importaciones,

Fusiones de Paquetes.

▪ Ejemplo: Organizar los diagramas de un sistema en

paquetes como "Requisitos", "Diseño Lógico", "Diseño
Físico".

o 2.2.2 Diagramas de Comportamiento (UC, ACT, SD, STM)

▪ Diagrama de Casos de Uso (UC):

▪ Propósito: Capturar los requisitos funcionales del sistema

desde la perspectiva del usuario, mostrando cómo los
actores interactúan con el sistema para lograr sus
objetivos.

▪ Elementos: Actores, Casos de Uso, Asociaciones,

Inclusiones, Extensiones, Generalizaciones.

▪ Ejemplo: Modelar los casos de uso de un sistema de

control de temperatura, como "Configurar Temperatura
Deseada", "Ver Temperatura Actual".

▪ Diagrama de Actividades (ACT):

▪ Propósito: Describir el flujo de control y de datos dentro de

una operación o proceso.
 ▪ Elementos: Nodos de Acción, Nodos de Control (Decisión,
Fusión, Bifurcación, Unión), Flujos de Control, Flujos de
Objetos, Pines de Entrada/Salida.

▪ Ejemplo: Modelar el algoritmo de control de temperatura,

mostrando los pasos desde la lectura del sensor hasta el
ajuste del actuador.

▪ Diagrama de Secuencia (SD):

▪ Propósito: Mostrar la interacción entre los objetos a lo

largo del tiempo, describiendo el intercambio de mensajes
entre ellos.

▪ Elementos: Líneas de Vida, Mensajes, Activaciones,

Operadores de Fragmento (alt, opt, loop, par).

▪ Ejemplo: Modelar la secuencia de mensajes

intercambiados entre el sensor, el controlador y el
actuador durante el control de temperatura.

▪ Diagrama de Máquina de Estados (STM):

▪ Propósito: Describir el comportamiento de un objeto o

sistema en términos de sus estados y las transiciones
entre ellos.

▪ Elementos: Estados, Transiciones, Eventos, Acciones,

Pseudoestados (Inicial, Final, Histórico).

▪ Ejemplo: Modelar los estados de un controlador de

temperatura (Inactivo, Calentando, Enfriando, Alerta).

o 2.2.3 Diagramas de Requisitos (REQ)

▪ Propósito: Capturar, organizar y gestionar los requisitos del

sistema.

▪ Elementos: Requisitos, Relaciones de Requisitos (Contiene,

Deriva, Satisface, Verifica, Refina, Traza), Tablas de Requisitos.

▪ Ejemplo: Definir y relacionar los requisitos funcionales, no

funcionales, de rendimiento y de interfaz de un sistema de control
de temperatura.

▪ Tipos de Requisitos: Funcionales, No Funcionales (rendimiento,

seguridad, usabilidad, etc.), de Interfaz, de Diseño, etc.

▪ Relaciones entre Requisitos: Derivación, Satisfacción,

Verificación, Refinamiento, Trazabilidad.

▪ Atributos de Requisitos: Identificador, Descripción, Prioridad,

Estado, Autor, Fuente, Riesgo, etc.

o 2.2.4 Diagramas Paramétricos (PAR)

 ▪ Propósito: Modelar las relaciones cuantitativas entre los
parámetros del sistema y realizar análisis de ingeniería.

▪ Elementos: Bloques de Restricción, Parámetros de Restricción,

Expresiones Matemáticas.

▪ Ejemplo: Modelar la relación entre la temperatura deseada, la

temperatura ambiente y la potencia del actuador en un sistema de
control de temperatura.

▪ Uso en análisis de ingeniería: Simulación, optimización, análisis

de sensibilidad, análisis de fallos.

o 2.2.5 Vistas y Puntos de Vista

▪ Concepto: Una vista es una representación de un sistema desde

una perspectiva particular (punto de vista). Un punto de vista
define las convenciones y los tipos de diagramas utilizados para
crear una vista.

▪ Importancia: Permiten abordar las preocupaciones específicas de

diferentes stakeholders y gestionar la complejidad del sistema.

▪ Ejemplos de Puntos de Vista: Arquitectura, Seguridad,

Rendimiento, Interfaz de Usuario.

o 2.2.6 Perfiles y Extensiones

▪ Concepto: Los perfiles permiten extender y adaptar SysML a

dominios o metodologías específicas.

▪ Ejemplos: Perfiles para sistemas embebidos, sistemas de tiempo

real, sistemas de seguridad crítica.

▪ Mecanismos de extensión: Estereotipos, tagged values,

restricciones.

• 2.3 Relación entre MBSE y SysML

o SysML como habilitador de MBSE: SysML proporciona el lenguaje de

modelado necesario para implementar los principios de MBSE.

o Modelos SysML como artefactos centrales: Los modelos SysML se

convierten en la fuente principal de información sobre el sistema.

o Trazabilidad a través de diagramas SysML: Los diferentes diagramas

SysML se interconectan para mantener la trazabilidad entre los requisitos,
el diseño, el análisis y las pruebas.

• 2.4 Herramientas de Soporte para MBSE y SysML

o Tipos de herramientas:

▪ Herramientas de modelado: Permiten crear y editar diagramas

SysML (ej: Cameo Systems Modeler, Enterprise Architect, Papyrus,
IBM Rhapsody).
 ▪ Herramientas de gestión de requisitos: Permiten capturar,
gestionar y rastrear requisitos (ej: DOORS, Jama Connect, ReqIF).

▪ Herramientas de simulación y análisis: Permiten ejecutar

modelos de simulación y realizar análisis paramétricos (ej:
MATLAB/Simulink, Modelica).

▪ Herramientas de generación de código: Permiten generar código

a partir de modelos SysML.

▪ Herramientas de gestión de configuración: Permiten controlar

las versiones de los modelos y gestionar los cambios.

o Características clave:

▪ Soporte completo de SysML: La herramienta debe soportar todos

los diagramas y características de SysML.

▪ Capacidades de trazabilidad: La herramienta debe permitir

establecer y visualizar relaciones de trazabilidad entre los
elementos del modelo.

▪ Integración con otras herramientas: La herramienta debe poder

integrarse con otras herramientas de ingeniería, como
herramientas de gestión de requisitos, simulación y análisis.

▪ Facilidad de uso: La herramienta debe ser intuitiva y fácil de usar.

▪ Soporte para colaboración: La herramienta debe permitir que

varios usuarios trabajen simultáneamente en el mismo modelo.

o Ejemplos de herramientas comerciales y de código abierto:

Descripción breve de las herramientas más populares.

3. El Grid MBSE: Un Marco de Referencia Multidimensional

• 3.1 Estructura del Grid MBSE

o Concepto: Revisión del concepto del Grid como una matriz que organiza
los aspectos del sistema (filas) y los niveles de abstracción (columnas).

o Importancia: Enfatizar cómo el Grid proporciona una estructura para el

proceso de modelado, asegurando la completitud y la consistencia.

o 3.1.1 Columnas: Niveles de Abstracción / Perspectivas

▪ [Link] Necesidades del Negocio:

▪ Definición: Describe la motivación estratégica detrás del

desarrollo del sistema, desde una perspectiva de negocio.

▪ Artefactos: Documento de Visión, Análisis de Mercado,

Modelo de Negocio (ej. Business Model Canvas).
 ▪ Ejemplo: "Incrementar la cuota de mercado en un 10% en
los próximos dos años mediante la introducción de un
nuevo producto innovador."

▪ [Link] Necesidades del Interesado:

▪ Definición: Captura las expectativas y deseos de todas las

partes interesadas (stakeholders) que se verán afectadas
por el sistema.

▪ Artefactos: Diagrama de Contexto, Lista de Interesados,

Casos de Uso de Alto Nivel, Tabla de Necesidades.

▪ Ejemplo: "El agricultor necesita un sistema que le permita

monitorizar la temperatura del invernadero de forma
remota."

▪ [Link] Requisitos del Sistema:

▪ Definición: Especifica lo que el sistema debe hacer para

satisfacer las necesidades de los interesados, incluyendo
funciones, rendimiento, interfaces y restricciones.

▪ Artefactos: Diagrama de Requisitos, Tabla de Requisitos

(funcionales, no funcionales, de rendimiento, de interfaz),
Casos de Uso Detallados.

▪ Ejemplo: "El sistema debe medir la temperatura con una

precisión de ±0.5°C."

▪ [Link] Arquitectura Lógica:

▪ Definición: Describe la estructura funcional del sistema,

independiente de la tecnología de implementación. Define
los bloques lógicos y sus interacciones.

▪ Artefactos: BDD (descomposición funcional), IBD

(interfaces lógicas), ACT (flujo de actividades), SD
(intercambio de mensajes), STM (estados del sistema).

▪ Ejemplo: "El sistema se compone de un Módulo de

Adquisición de Datos, un Módulo de Procesamiento y un
Módulo de Comunicación."

[Link] Arquitectura Física:

• Definición: Describe la implementación física del sistema en términos de

hardware, software y personas.

• Artefactos: BDD (componentes físicos), IBD (interfaces físicas), Diagramas de

Despliegue.

• Ejemplo: "El sistema se implementa con un sensor de temperatura DHT22

• [Link] Diseño Detallado:

o Definición: Proporciona las especificaciones detalladas de los

componentes individuales del sistema, incluyendo hardware, software y la
interacción con el entorno.

o Artefactos: Especificaciones de interfaces a bajo nivel (protocolos de

comunicación detallados), pseudocódigo de algoritmos, diagramas de
clases detallados, modelos de datos, etc.

o Ejemplo: Especificación del protocolo de comunicación I2C para el

sensor DHT22, incluyendo la estructura de los mensajes, la frecuencia de
reloj y los registros de configuración.

• [Link] Verificación y Validación:

o Definición: Define cómo se verificará que el sistema cumple con los

requisitos (verificación) y cómo se validará que satisface las necesidades
de los interesados (validación).

o Artefactos: Plan de Verificación y Validación, Casos de Prueba, Matriz de

Trazabilidad de Requisitos, Informes de Pruebas, Análisis de Riesgos
(FMEA), Resultados de Simulaciones.

o Ejemplo: Definición de casos de prueba para verificar que el sistema

genera una alerta cuando la temperatura excede el umbral configurado.

• [Link] Operaciones y Mantenimiento:

o Definición: Considera los aspectos relacionados con la operación, el

soporte y el mantenimiento del sistema a lo largo de su ciclo de vida.

o Artefactos: Manual de Usuario, Manual de Mantenimiento, Plan de

Actualización de Software, Procedimientos de Gestión de Fallos, Análisis
de Costos del Ciclo de Vida.

o Ejemplo: Procedimientos para la calibración periódica del sensor de

temperatura.

• 3.1.2 Filas: Aspectos del Sistema (Modelado)

o [Link] Estructura (Composición, Interfaces, Contexto):

▪ Composición:

▪ Definición: Describe cómo se descompone el sistema en

sus partes constitutivas y cómo se relacionan entre sí.

▪ Diagramas Asociados: BDD, PKG.

▪ Ejemplo: Descomponer el sistema de control de

temperatura en sensor, controlador y actuador, y luego
descomponer el controlador en sus subcomponentes.

▪ Interfaces:
 ▪ Definición: Define los puntos de interacción entre las
partes del sistema o entre el sistema y su entorno.

▪ Diagramas Asociados: IBD.

▪ Ejemplo: Definir las interfaces entre el sensor y el

controlador (por ejemplo, la señal analógica que
representa la temperatura).

▪ Contexto:

▪ Definición: Describe el entorno externo del sistema y

cómo interactúa con él.

▪ Diagramas Asociados: Diagrama de Contexto (en BDD o

como diagrama independiente).

▪ Ejemplo: Mostrar el sistema de control de temperatura

interactuando con el agricultor, el invernadero y la red
eléctrica.

o [Link] Comportamiento (Funcionalidad, Interacciones, Estados):

▪ Funcionalidad:

▪ Definición: Describe las acciones y procesos que realiza el

sistema.

▪ Diagramas Asociados: UC, ACT.

▪ Ejemplo: Modelar la función de "Controlar Temperatura"

como una actividad que incluye leer el sensor, comparar
con el valor deseado y ajustar el actuador.

▪ Interacciones:

▪ Definición: Describe el intercambio de información,

energía o materia entre los elementos del sistema o entre
el sistema y su entorno.

▪ Diagramas Asociados: SD.

▪ Ejemplo: Mostrar la secuencia de mensajes

intercambiados entre el sensor, el controlador y el
actuador durante un ciclo de control.

▪ Estados:

▪ Definición: Describe los diferentes modos operativos o

condiciones del sistema y las transiciones entre ellos.

▪ Diagramas Asociados: STM.

▪ Ejemplo: Modelar los estados del controlador de

temperatura (Inactivo, Calentando, Enfriando, Alerta).

o [Link] Requisitos (Tipos, Relaciones, Atributos):

 ▪ Tipos:

▪ Definición: Clasificación de los requisitos según su

naturaleza (funcionales, no funcionales, de rendimiento,
de interfaz, etc.).

▪ Diagramas Asociados: REQ.

▪ Ejemplo: Definir requisitos funcionales (medir

temperatura), de rendimiento (precisión de la medición),
de interfaz (protocolo de comunicación), etc.

▪ Relaciones:

▪ Definición: Describe las dependencias y relaciones

lógicas entre los requisitos.

▪ Diagramas Asociados: REQ.

▪ Ejemplo: Mostrar que un requisito de "Generar Alerta"

depende de un requisito de "Medir Temperatura".

▪ Atributos:

▪ Definición: Metadatos asociados a los requisitos que

proporcionan información adicional sobre ellos.

▪ Diagramas Asociados: REQ (en tablas o como

propiedades de los elementos de requisito).

▪ Ejemplo: Definir atributos como el identificador, la

descripción, la prioridad, el estado, el autor y la fuente de
cada requisito.

o [Link] Paramétricos / Análisis (Restricciones, Simulación,

Optimización, Riesgos, Costos):

▪ Restricciones:

▪ Definición: Limitaciones físicas o matemáticas que

afectan al sistema o a sus componentes.

▪ Diagramas Asociados: PAR.

▪ Ejemplo: Modelar la restricción de que la potencia del

actuador no puede exceder un cierto valor.

▪ Simulación:

▪ Definición: Modelado dinámico del comportamiento del

sistema para predecir su rendimiento bajo diferentes
condiciones.

▪ Diagramas Asociados: PAR (integrado con herramientas

de simulación como MATLAB/Simulink).
 ▪ Ejemplo: Simular el comportamiento del sistema de
control de temperatura a lo largo del tiempo para evaluar
su estabilidad y precisión.

▪ Optimización:

▪ Definición: Búsqueda de la mejor configuración del

sistema en base a criterios específicos, como el
rendimiento, el costo o la eficiencia.

▪ Diagramas Asociados: PAR (integrado con herramientas

de optimización).

▪ Ejemplo: Optimizar los parámetros del controlador de

temperatura para minimizar el consumo de energía y
maximizar la precisión.

▪ Riesgos:

▪ Definición: Identificación y evaluación de riesgos

potenciales que pueden afectar al sistema.

▪ Artefactos Asociados: FMEA (Failure Mode and Effects

Analysis), Árboles de Fallos.

▪ Ejemplo: Realizar un análisis FMEA para identificar los

modos de fallo potenciales del sistema de control de
temperatura y sus efectos.

▪ Costos:

▪ Definición: Estimación y análisis del costo del ciclo de vida

del sistema, incluyendo el desarrollo, la producción, la
operación y el mantenimiento.

▪ Artefactos Asociados: Modelos de Costos, Análisis de

Costo-Beneficio.

▪ Ejemplo: Estimar el costo total de propiedad del sistema

de control de temperatura a lo largo de su vida útil.

• 3.2 Interconexiones y Trazabilidad en el Grid MBSE

o Importancia: Enfatizar la importancia de la trazabilidad para asegurar la

consistencia, la completitud y la gestionabilidad del cambio.

o 3.2.1 Trazabilidad Horizontal:

▪ Definición: Conexiones entre celdas dentro de la misma fila,

mostrando cómo se relacionan los diferentes artefactos en el
mismo nivel de abstracción.

▪ Ejemplo: Conectar un Diagrama de Actividades en la columna

"Arquitectura Lógica" con la Tabla de Requisitos Funcionales en la
columna "Requisitos del Sistema" para mostrar qué requisitos se
satisfacen con esa actividad.
 o 3.2.2 Trazabilidad Vertical:

▪ Definición: Conexiones entre celdas dentro de la misma columna,

mostrando cómo se refinan los conceptos a medida que se
desciende en los niveles de abstracción.

▪ Ejemplo: Conectar un Caso de Uso de Alto Nivel en la columna

"Necesidades del Interesado" con un Caso de Uso Detallado en la
columna "Requisitos del Sistema."

o 3.2.3 Trazabilidad Cruzada:

▪ Definición: Conexiones entre celdas en diferentes filas y

columnas, mostrando relaciones complejas entre diferentes
aspectos y niveles de abstracción.

▪ Ejemplo: Conectar un Requisito de Rendimiento en la columna

"Requisitos del Sistema" con un Análisis de Simulación en la
columna "Verificación y Validación" y la fila "Paramétricos /
Análisis" para mostrar cómo se verifica ese requisito.

o 3.2.4 Relaciones de Satisfacción, Verificación, Derivación,

Composición y Descomposición:

▪ Satisfacción: Un elemento de diseño satisface un requisito.

▪ Verificación: Un caso de prueba verifica un requisito o un

elemento de diseño.

▪ Derivación: Un requisito de bajo nivel se deriva de un requisito de

alto nivel.

▪ Composición y Descomposición: Un elemento se compone de

otros elementos, o un elemento se descompone en otros
elementos.

▪ Ejemplos concretos de cada relación utilizando diagramas

SysML.

• 3.3 Navegación a través del Grid MBSE

o Concepto: Explicar cómo el Grid se puede utilizar como una herramienta

de navegación para explorar el modelo del sistema.

o 3.3.1 Hilo de Requisitos:

▪ Descripción: Seguir un requisito desde su origen en las

necesidades del interesado hasta su implementación en el diseño
y su verificación.

▪ Ejemplo: Rastrear un requisito de precisión de temperatura a

través del Grid, desde las necesidades del interesado, pasando
por los requisitos del sistema, la arquitectura lógica y física, hasta
la verificación y validación.

o 3.3.2 Hilo de Funcionalidad:

 ▪ Descripción: Explorar cómo una función específica se
implementa a través de los diferentes niveles de abstracción.

▪ Ejemplo: Seguir la función de "Controlar Temperatura" a través del

Grid, desde los casos de uso de alto nivel, pasando por las
actividades en la arquitectura lógica, la implementación en la
arquitectura física, hasta las pruebas de verificación.

o 3.3.3 Hilo de Verificación:

▪ Descripción: Examinar cómo se verifica cada aspecto del

sistema, desde los requisitos hasta el diseño.

▪ Ejemplo: Rastrear todos los casos de prueba y análisis asociados

a un requisito o a un componente del sistema.

4. Implementación del Grid MBSE con SysML: Guía Paso a Paso

• 4.1 Fase 1: Definición del Contexto y las Necesidades

o 4.1.1 Identificación de las Necesidades del Negocio:

▪ Técnicas: Análisis de mercado, análisis de la competencia,

estudios de viabilidad.

▪ Entregables: Documento de Visión, Modelo de Negocio.

o 4.1.2 Identificación de los Interesados y sus Necesidades (Stakeholder

Needs):

▪ Técnicas: Entrevistas, encuestas, talleres, análisis de

documentos.

▪ Diagrama de Contexto: Representar el sistema y su entorno,

identificando los actores y sus interacciones.

▪ Casos de Uso de Alto Nivel: Describir las principales

interacciones entre los actores y el sistema.

▪ Tabla de Necesidades: Documentar las necesidades de cada

interesado en un formato tabular.

o 4.1.3 Definición del Contexto del Sistema:

▪ Diagrama de Contexto del Sistema (BDD o diagrama

específico): Refinar el diagrama de contexto para definir
claramente el límite del sistema y sus interfaces con el entorno.

▪ Descripción del Entorno: Documentar los elementos externos

con los que interactúa el sistema.

• 4.2 Fase 2: Especificación de Requisitos del Sistema

o 4.2.1 Desarrollo de Requisitos del Sistema:

 ▪ Técnicas: Derivación de requisitos a partir de las necesidades de
los interesados, análisis de casos de uso, descomposición
funcional.

▪ Diagrama de Requisitos: Representar los requisitos y sus

relaciones (dependencia, derivación, satisfacción, etc.).

▪ Tabla de Requisitos: Documentar los requisitos en un formato

tabular, incluyendo atributos como el identificador, la descripción,
la prioridad, el estado, etc.

▪ Casos de Uso Detallados: Expandir los casos de uso de alto nivel

para describir en detalle la interacción entre los actores y el
sistema.

o 4.2.2 Gestión de Requisitos (Atributos, Relaciones, Trazabilidad):

▪ Definición de Atributos: Establecer los atributos relevantes para

los requisitos (por ejemplo, prioridad, estado, autor, fuente,
riesgo).

▪ Establecimiento de Relaciones: Definir las relaciones entre los

requisitos (por ejemplo, derivación, dependencia, conflicto).

▪ Mantenimiento de la Trazabilidad: Asegurar que los requisitos

estén vinculados a las necesidades de los interesados, los
elementos de diseño, los casos de prueba, etc.

• 4.3 Fase 3: Diseño de la Arquitectura Lógica

o 4.3.1 Descomposición Funcional (BDD):

▪ Identificar las funciones principales del sistema.

▪ Descomponer las funciones en subfunciones.

▪ Representar la descomposición en un diagrama BDD.

o 4.3.2 Definición de Interfaces Lógicas (IBD):

▪ Identificar las interfaces entre las funciones.

▪ Definir el tipo de información o energía que se intercambia a

través de cada interfaz.

▪ Representar las interfaces en un diagrama IBD.

o 4.3.3 Modelado del Comportamiento (ACT, SD, STM):

▪ Utilizar diagramas de actividades (ACT) para modelar el flujo de

control y de datos dentro de cada función.

▪ Utilizar diagramas de secuencia (SD) para modelar las

interacciones entre las funciones.
 ▪ Utilizar diagramas de máquina de estados (STM) para modelar
el comportamiento de las funciones en términos de estados y
transiciones.

o 4.3.4 Análisis Paramétricos (PAR):

▪ Identificar los parámetros clave del sistema.

▪ Modelar las relaciones entre los parámetros utilizando

diagramas paramétricos (PAR).

▪ Utilizar los modelos paramétricos para realizar análisis de

ingeniería, como la simulación o la optimización.

• 4.4 Fase 4: Diseño de la Arquitectura Física

o 4.4.1 Selección de Componentes (BDD):

▪ Identificar los componentes de hardware, software y humanos

necesarios para implementar la arquitectura lógica.

▪ Representar los componentes en un diagrama BDD.

o 4.4.2 Definición de Interfaces Físicas (IBD):

▪ Identificar las interfaces entre los componentes.

▪ Definir el tipo de conexión física y el protocolo de

comunicación utilizado en cada interfaz.

▪ Representar las interfaces en un diagrama IBD.

o 4.4.3 Modelado del Comportamiento a Nivel Físico (ACT, SD):

▪ Refinar los modelos de comportamiento de la arquitectura

lógica para adaptarlos a la arquitectura física.

▪ Utilizar diagramas de actividades (ACT) y de secuencia (SD)

para modelar el comportamiento de los componentes físicos.

• 4.5 Fase 5: Diseño Detallado

o 4.5.1 Especificación Detallada de Componentes:

▪ Proporcionar una descripción detallada de cada componente,

incluyendo sus especificaciones técnicas, diagramas internos
(si es necesario) y cualquier otra información relevante.

o 4.5.2 Definición de Interfaces a Bajo Nivel:

▪ Especificar en detalle los protocolos de comunicación

utilizados en cada interfaz, incluyendo el formato de los
mensajes, la temporización y el manejo de errores.

• 4.6 Fase 6: Planificación de la Verificación y Validación

o 4.6.1 Estrategia de Verificación y Validación:

 ▪ Definir los métodos que se utilizarán para verificar y validar el
sistema (por ejemplo, pruebas unitarias, pruebas de
integración, pruebas de sistema, inspecciones, revisiones).

o 4.6.2 Desarrollo de Casos de Prueba (STM, ACT, SD):

▪ Derivar casos de prueba a partir de los requisitos, los casos de

uso y los modelos de comportamiento.

▪ Utilizar diagramas de máquina de estados (STM), de

actividades (ACT) y de secuencia (SD) para definir los casos de
prueba.

• 4.6.3 Matriz de Trazabilidad de Requisitos: * Crear una matriz que vincule

cada requisito con los casos de prueba que lo verifican. * Asegurar que todos
los requisitos estén cubiertos por al menos un caso de prueba.

o 4.6.4 Análisis de Riesgos (FMEA):

▪ Realizar un Análisis de Modos de Fallo y Efectos (FMEA) para

identificar los posibles fallos del sistema, sus causas y sus
consecuencias.

▪ Definir acciones de mitigación para reducir la probabilidad o el

impacto de los fallos.

• 4.7 Fase 7: Consideraciones para Operaciones y Mantenimiento

o 4.7.1 Plan de Mantenimiento:

▪ Definir las actividades de mantenimiento preventivo y

correctivo que se realizarán durante la vida útil del sistema.

o 4.7.2 Procedimientos de Actualización:

▪ Establecer los procedimientos para actualizar el software o el

hardware del sistema.

o 4.7.3 Gestión de Fallos:

▪ Definir los procedimientos para detectar, diagnosticar y

resolver los fallos del sistema.

o 4.7.4 Análisis de Costos del Ciclo de Vida:

▪ Estimar los costos de operación y mantenimiento del sistema a

lo largo de su vida útil.

5. Ejemplo Práctico: Sistema de Monitoreo de Temperatura para un Invernadero

• 5.1 Aplicación del Grid MBSE al Ejemplo:

o Descripción del Sistema: Un sistema que monitoriza la temperatura en

un invernadero y envía alertas al agricultor si la temperatura está fuera de
los límites establecidos.
 o Recorrido por el Grid: Se mostrará cómo se completa cada celda del Grid
para este ejemplo específico, desde las necesidades del negocio hasta las
consideraciones de operación y mantenimiento.

• 5.2 Desarrollo de Diagramas SysML para cada Celda del Grid:

o Necesidades del Negocio:

▪ Documento de Visión: "Mejorar la eficiencia y la productividad del

invernadero mediante un control preciso de la temperatura."

o Necesidades del Interesado:

▪ Diagrama de Contexto: Muestra al agricultor, el invernadero y la

red eléctrica como actores externos.

▪ Casos de Uso de Alto Nivel: "Monitorear Temperatura", "Recibir

Alertas", "Configurar Umbrales".

▪ Tabla de Necesidades: "Necesito saber la temperatura en tiempo

real", "Necesito recibir alertas si la temperatura excede los
límites".

o Requisitos del Sistema:

▪ Diagrama de Requisitos: Muestra los requisitos del sistema y sus

relaciones.

▪ Tabla de Requisitos: "El sistema debe medir la temperatura con

una precisión de ±0.5°C", "El sistema debe enviar una alerta al
agricultor si la temperatura supera los 30°C o cae por debajo de
los 10°C".

▪ Casos de Uso Detallados: Descripción detallada de cada caso de

uso, incluyendo el flujo de eventos, las precondiciones y las
poscondiciones.

o Arquitectura Lógica:

▪ BDD: Descomposición en Módulo de Sensor, Módulo de

Procesamiento, Módulo de Comunicación.

▪ IBD: Interfaces lógicas entre los módulos (datos de temperatura,

comandos de configuración, alertas).

▪ ACT: Diagrama de actividades para la función de "Monitorear

Temperatura".

▪ SD: Diagrama de secuencia para el envío de una alerta.

▪ STM: Diagrama de estados del Módulo de Procesamiento

(Monitoreando, Alerta, Configuración).

o Arquitectura Física:
 ▪ BDD: Componentes físicos (Sensor de Temperatura DHT22,
Microcontrolador ESP32, Módulo WiFi).

▪ IBD: Interfaces físicas (conexión I2C entre el sensor y el

microcontrolador, conexión WiFi con el router).

o Diseño Detallado:

▪ Especificación del protocolo I2C para el sensor DHT22.

▪ Pseudocódigo del algoritmo de control de temperatura.

o Verificación y Validación:

▪ Casos de Prueba: "Verificar que el sistema mide la temperatura

con la precisión especificada", "Verificar que el sistema envía una
alerta cuando la temperatura excede los límites".

▪ Matriz de Trazabilidad: Vincula los requisitos con los casos de

prueba.

o Operaciones y Mantenimiento:

▪ Procedimiento de calibración del sensor.

• 5.3 Demostración de la Trazabilidad y las Interconexiones:

o Ejemplo de trazabilidad vertical: Mostrar cómo un caso de uso de alto

nivel se refina en requisitos del sistema, se implementa en la arquitectura
lógica y se verifica con casos de prueba.

o Ejemplo de trazabilidad horizontal: Mostrar cómo un diagrama de

actividades en la arquitectura lógica se relaciona con la tabla de requisitos
funcionales.

o Ejemplo de trazabilidad cruzada: Mostrar cómo un requisito de

rendimiento se verifica mediante un análisis paramétrico y un caso de
prueba.

6. Herramientas y Tecnologías de Soporte

• 6.1 Herramientas de Modelado SysML (Cameo Systems Modeler, Enterprise

Architect, Papyrus, etc.)

o Descripción de las características principales de cada herramienta.

o Ventajas y desventajas de cada herramienta.

o Criterios para la selección de una herramienta.

• 6.2 Herramientas de Gestión de Requisitos (DOORS, Jama Connect, ReqIF)

o Descripción de las funcionalidades para la captura, gestión y

trazabilidad de requisitos.

o Integración con herramientas de modelado SysML.

• 6.3 Herramientas de Simulación y Análisis (MATLAB/Simulink, Modelica)

 o Capacidades de simulación de modelos SysML.

o Integración con herramientas de modelado SysML.

• 6.4 Integración de Herramientas y Flujo de Trabajo

o Importancia de la integración entre herramientas para un flujo de

trabajo fluido.

o Estrategias para la integración de herramientas (por ejemplo, a través

de APIs o formatos de intercambio de datos como ReqIF).

o Descripción de un flujo de trabajo típico utilizando un conjunto de

herramientas integradas.

7. Consideraciones Metodológicas Avanzadas

• 7.1 MBSE y Metodologías Ágiles:

o Adaptación de MBSE a un entorno ágil.

o Desarrollo iterativo e incremental de modelos.

o Uso de sprints para la creación y revisión de modelos.

• 7.2 Model-Based Reviews:

o Realización de revisiones formales de los modelos para detectar

errores y mejorar la calidad.

o Técnicas para la revisión de modelos (por ejemplo, inspecciones,

walkthroughs).

• 7.3 Gestión de la Configuración del Modelo:

o Control de versiones de los modelos.

o Gestión de cambios en los modelos.

o Uso de herramientas de gestión de configuración (por ejemplo, Git).

• 7.4 Reutilización de Modelos:

o Creación de bibliotecas de modelos reutilizables.

o Estrategias para la adaptación y extensión de modelos existentes.

• 7.5 Validación y Verificación Formal:

o Aplicación de técnicas formales para la verificación de propiedades

críticas del sistema.

o Uso de herramientas de verificación formal.

• 7.6 Integración con el Ciclo de Vida del Sistema:

o Conexión del Grid MBSE con las diferentes fases del ciclo de vida del
sistema (concepción, desarrollo, producción, operación, retiro).

8. Desafíos y Mejores Prácticas

 • 8.1 Desafíos Comunes en la Implementación de MBSE:

o Resistencia al cambio.

o Curva de aprendizaje de SysML y las herramientas de soporte.

o Complejidad del modelo.

o Dificultad para mantener la consistencia del modelo.

o Costo de las herramientas y la formación.

• 8.2 Mejores Prácticas para una Implementación Exitosa:

o 8.2.1 Comenzar con un Proyecto Piloto:

▪ Seleccionar un proyecto piloto de tamaño y complejidad

manejables.

▪ Demostrar los beneficios de MBSE en el proyecto piloto.

o 8.2.2 Formación y Capacitación:

▪ Proporcionar formación adecuada al equipo en SysML y las

herramientas de soporte.

▪ Desarrollar guías de estilo y mejores prácticas para el modelado.

o 8.2.3 Establecer Estándares y Guías:

▪ Definir convenciones de modelado claras y consistentes.

▪ Establecer plantillas para los diferentes tipos de diagramas.

o 8.2.4 Fomentar la Colaboración:

▪ Promover la comunicación y la colaboración entre los miembros

del equipo.

▪ Utilizar herramientas que faciliten el trabajo colaborativo en el

modelo.

• 8.3 Lecciones Aprendidas de Implementaciones Reales:

o Compartir experiencias de proyectos reales que han implementado

MBSE con éxito.

o Identificar los factores clave de éxito y las dificultades encontradas.

9. Conclusiones y Perspectivas Futuras

• 9.1 Resumen de los Beneficios de MBSE y el Grid Estructurado:

o Recapitular los principales beneficios de utilizar MBSE y el Grid

Estructurado para el desarrollo de sistemas complejos.

• 9.2 Tendencias Futuras en MBSE y SysML:

o Inteligencia Artificial y Aprendizaje Automático para la generación y

validación de modelos.
 o Modelado basado en la nube.

o Integración con gemelos digitales.

o Evolución del estándar SysML.

10. Apéndices

• 10.1 Glosario de Términos:

o Definiciones de los términos clave utilizados en la guía.

• 10.2 Plantillas de Diagramas SysML:

o Ejemplos de plantillas para los diferentes tipos de diagramas SysML.

• 10.3 Recursos Adicionales (Libros, Artículos, Sitios Web):

o Lista de recursos para profundizar en los temas tratados en la guía.

11. Referencias Bibliográficas

• Lista de libros, artículos y otras fuentes utilizadas en la elaboración de la guía.

1. Introducción

La ingeniería de sistemas se enfrenta a una creciente complejidad en el desarrollo de

productos y servicios modernos. Los sistemas actuales integran múltiples disciplinas,
involucran a un gran número de partes interesadas y deben cumplir con requisitos cada
vez más exigentes en términos de rendimiento, seguridad, confiabilidad y sostenibilidad.
En este contexto, los enfoques tradicionales basados en documentos se han vuelto
insuficientes para gestionar la complejidad y asegurar la calidad y eficiencia en el
desarrollo de sistemas.

Para abordar estos desafíos, surge la Ingeniería de Sistemas Basada en Modelos

(MBSE, Model-Based Systems Engineering), un paradigma que promueve el uso de
modelos digitales como artefacto central a lo largo de todo el ciclo de vida del sistema.
Esta introducción detalla los conceptos fundamentales de MBSE, sus beneficios, el rol
del lenguaje de modelado SysML, la utilidad del Grid MBSE como marco de referencia y el
alcance de esta guía.

1.1 ¿Qué es MBSE?

Definición Detallada:

MBSE es una metodología formalizada para el desarrollo de sistemas que se centra en la

creación, gestión y utilización de modelos digitales como la principal fuente de
información y el medio principal para la toma de decisiones a lo largo de todo el ciclo de
vida del sistema. A diferencia del enfoque tradicional, que se basa en documentos
textuales y diagramas inconexos, MBSE utiliza modelos computacionales,
semánticamente ricos y formalmente definidos para representar los diferentes aspectos
del sistema, incluyendo sus requisitos, estructura, comportamiento, parámetros y
relaciones.

Principios Fundamentales de MBSE:

El éxito de la implementación de MBSE se basa en la adhesión a una serie de principios

fundamentales que guían el proceso de modelado y la gestión del ciclo de vida del
sistema:

• Modelos como Fuente Única de Verdad (Single Source of Truth): Este principio
establece que el modelo digital del sistema es la referencia autorizada y
definitiva para todas las decisiones de diseño, análisis, verificación y validación.
Se elimina la ambigüedad y la redundancia al tener una única fuente de
información consistente y actualizada. Todos los artefactos del proyecto, desde
la documentación hasta el código, se derivan o se vinculan directamente al
modelo.

• Abstracción y Formalismo: Los modelos se construyen utilizando un lenguaje

de modelado formal (como SysML) que proporciona una sintaxis y semántica
bien definidas. Esto permite representar el sistema en diferentes niveles de
abstracción, desde la concepción de alto nivel hasta el diseño detallado,
ocultando la complejidad innecesaria en cada nivel y facilitando la comprensión
del sistema desde diferentes perspectivas. El formalismo del lenguaje de
modelado permite la verificación automática de la consistencia y la detección
temprana de errores.
 • Trazabilidad y Consistencia: El enfoque MBSE enfatiza el establecimiento y
mantenimiento de relaciones de trazabilidad entre los diferentes elementos del
modelo. Esto permite rastrear el origen de los requisitos, verificar que se han
implementado correctamente y evaluar el impacto de los cambios en cualquier
parte del sistema. La trazabilidad asegura la consistencia entre los diferentes
artefactos del modelo, como los requisitos, el diseño, el análisis y las pruebas.

• Automatización: MBSE aprovecha el poder de las herramientas de software para

automatizar tareas repetitivas y propensas a errores, como la generación de
documentación, la verificación de la consistencia del modelo, la ejecución de
simulaciones y la generación de código. La automatización mejora la eficiencia
del proceso de desarrollo y reduce la posibilidad de errores humanos.

• Colaboración: Los modelos digitales facilitan la colaboración entre los

miembros del equipo y las diferentes disciplinas involucradas en el desarrollo
del sistema. Al proporcionar una representación visual y un lenguaje común, los
modelos mejoran la comunicación y el entendimiento entre las partes
interesadas.

• Iteración e Incrementalidad: MBSE se integra bien con metodologías de

desarrollo iterativo e incremental, como las metodologías ágiles. Los modelos se
pueden desarrollar y refinar de forma iterativa, permitiendo una adaptación
flexible a los cambios en los requisitos o en el entorno.

Evolución desde el Enfoque Basado en Documentos:

Tradicionalmente, la ingeniería de sistemas se ha basado en la creación y gestión de una

gran cantidad de documentos textuales, como especificaciones de requisitos,
documentos de diseño, planes de prueba, etc. Este enfoque presenta varias
limitaciones:

• Ambigüedad: El lenguaje natural utilizado en los documentos puede ser ambiguo

e interpretarse de diferentes maneras por diferentes personas.

• Inconsistencia: Es difícil mantener la consistencia entre múltiples documentos,

especialmente cuando se realizan cambios.

• Dificultad de Mantenimiento: Actualizar y gestionar una gran cantidad de

documentos puede ser una tarea tediosa y propensa a errores.

• Falta de Trazabilidad: Es difícil rastrear las relaciones entre los requisitos, el

diseño, el análisis y las pruebas cuando la información está dispersa en múltiples
documentos.

• Comunicación Ineficiente: Los documentos textuales no son el medio más

efectivo para comunicar ideas complejas sobre la arquitectura y el
comportamiento del sistema.

MBSE surge como una solución a estas limitaciones. Al reemplazar los documentos por
modelos digitales interconectados, MBSE proporciona una representación más precisa,
consistente y manejable del sistema. Los modelos eliminan la ambigüedad, facilitan la
trazabilidad, mejoran la comunicación y permiten la automatización de tareas, lo que
conduce a un proceso de desarrollo más eficiente y a la creación de sistemas de mayor
calidad.

1.2 Beneficios de MBSE

La adopción de MBSE ofrece una serie de beneficios tangibles que impactan

positivamente en el desarrollo de sistemas:

• Mejora de la Comunicación:

o Lenguaje Común: Los modelos proporcionan un lenguaje común y una

representación visual del sistema que facilita la comunicación y el
entendimiento entre todas las partes interesadas, incluyendo ingenieros
de diferentes disciplinas, clientes, gerentes y usuarios finales.

o Reducción de Ambigüedades: El uso de un lenguaje de modelado formal

como SysML minimiza las ambigüedades y las malas interpretaciones que
pueden surgir con la documentación textual.

o Visualización Clara: Los diagramas y las representaciones gráficas del

sistema facilitan la comprensión de la arquitectura, el comportamiento y
las interrelaciones entre los componentes del sistema.

• Gestión de la Complejidad:

o Descomposición Jerárquica: MBSE permite descomponer sistemas

complejos en subsistemas y componentes más pequeños y manejables,
facilitando su análisis y diseño.

o Manejo de la Abstracción: Los modelos permiten trabajar en diferentes

niveles de abstracción, ocultando los detalles innecesarios en cada nivel y
enfocándose en los aspectos relevantes para cada etapa del desarrollo.

o Visualización de Interrelaciones: Los modelos permiten visualizar y

analizar las interrelaciones entre los diferentes componentes del sistema,
identificando dependencias y posibles conflictos.

• Detección Temprana de Errores:

o Verificación de la Consistencia: Las herramientas de modelado pueden

verificar automáticamente la consistencia del modelo, identificando
errores de sintaxis y semántica en etapas tempranas del desarrollo.

o Simulación y Análisis: Los modelos permiten simular el comportamiento

del sistema y realizar análisis de ingeniería para identificar posibles
problemas de diseño antes de la implementación física.

o Reducción del Costo de Corrección: Detectar y corregir errores en las

etapas iniciales del desarrollo es mucho menos costoso que hacerlo en
etapas posteriores, cuando el sistema ya está construido.

• Reducción del Tiempo y Costo de Desarrollo:

o Automatización de Tareas: MBSE permite automatizar tareas como la

generación de documentación, la generación de código y la ejecución de
 pruebas, lo que reduce el tiempo y el esfuerzo requeridos para el
desarrollo.

o Reutilización de Modelos: Los modelos se pueden reutilizar en proyectos

similares, lo que reduce el tiempo y el costo de desarrollo de nuevos
sistemas.

o Mejora de la Eficiencia: La detección temprana de errores y la mejora en

la comunicación contribuyen a un proceso de desarrollo más eficiente y a
una reducción del tiempo de comercialización.

• Mejora de la Calidad y la Confiabilidad:

o Verificación Formal: MBSE permite aplicar técnicas de verificación

formal para asegurar que el sistema cumple con sus requisitos,
especialmente en sistemas críticos donde la seguridad y la confiabilidad
son fundamentales.

o Simulación Exhaustiva: La capacidad de simular el comportamiento del

sistema bajo diferentes condiciones permite identificar y mitigar riesgos
potenciales, mejorando la confiabilidad del sistema.

o Trazabilidad Completa: La trazabilidad entre los requisitos, el diseño, el

análisis y las pruebas asegura que todos los aspectos del sistema se han
considerado y verificado adecuadamente.

• Facilita la Reutilización:

o Bibliotecas de Modelos: MBSE promueve la creación de bibliotecas de

modelos reutilizables, que pueden ser adaptados y extendidos para el
desarrollo de nuevos sistemas, reduciendo el esfuerzo y el tiempo de
desarrollo.

o Modelos como Base para Variantes: Los modelos pueden servir como
base para la creación de variantes del sistema, permitiendo la gestión
eficiente de la variabilidad y la personalización del producto.

• Soporte para la Toma de Decisiones:

o Análisis de Impacto: La trazabilidad en los modelos permite evaluar

rápidamente el impacto de los cambios en los requisitos o en el diseño,
facilitando la toma de decisiones informadas.

o Evaluación de Alternativas: Los modelos permiten comparar diferentes

alternativas de diseño y seleccionar la mejor opción en base a criterios
predefinidos.

o Base para la Justificación: Los modelos proporcionan una base sólida y

objetiva para justificar las decisiones de diseño y arquitectura del sistema.

1.3 ¿Qué es SysML?

Definición Detallada:
SysML (Systems Modeling Language) es un lenguaje de modelado gráfico de propósito
general para la ingeniería de sistemas. Es un estándar abierto desarrollado y mantenido
por el Object Management Group (OMG), en colaboración con el International Council
on Systems Engineering (INCOSE). SysML se basa en UML (Unified Modeling Language),
el lenguaje estándar para el modelado de software, pero lo extiende y adapta para cubrir
las necesidades específicas del modelado de sistemas complejos, que pueden incluir
hardware, software, datos, personal y procesos.

Desarrollo y Estandarización:

SysML surgió como respuesta a la necesidad de un lenguaje de modelado estándar para

la ingeniería de sistemas que fuera más allá del alcance de UML. El proceso de desarrollo
de SysML comenzó a principios de la década de 2000, y la versión 1.0 fue adoptada por el
OMG en 2006. Desde entonces, SysML ha evolucionado a través de varias revisiones, con
la versión actual siendo la 1.6 (a la fecha de este escrito, con la versión 2.0 en desarrollo).

Características Principales:

• Diagramas: SysML proporciona un conjunto de nueve tipos de diagramas

diseñados para capturar diferentes aspectos de un sistema:

o Diagramas de Estructura: Diagrama de Definición de Bloques (BDD),

Diagrama de Bloques Internos (IBD), Diagrama de Paquetes (PKG).

o Diagramas de Comportamiento: Diagrama de Casos de Uso (UC),

Diagrama de Actividades (ACT), Diagrama de Secuencia (SD), Diagrama de
Máquina de Estados (STM).

o Diagramas de Requisitos: Diagrama de Requisitos (REQ).

o Diagramas Paramétricos: Diagrama Paramétrico (PAR).

o Cada diagrama tiene un propósito específico y se utiliza para modelar un

aspecto particular del sistema.

• Perfil de UML: SysML es un perfil de UML, lo que significa que hereda muchos de
los conceptos y la notación de UML, pero también define extensiones
específicas para la ingeniería de sistemas. Esto permite a los ingenieros de
sistemas aprovechar la familiaridad y las herramientas existentes de UML, al
mismo tiempo que se benefician de las capacidades adicionales de SysML.

• Extensiones para Sistemas: SysML incluye estereotipos, tagged values y

restricciones específicos para el modelado de sistemas. Estas extensiones
permiten, por ejemplo:

o Modelar requisitos de forma estructurada, incluyendo sus relaciones y

atributos.

o Definir bloques de restricciones para el modelado paramétrico y el

análisis de ingeniería.

o Representar flujos continuos de materia, energía o datos.

• Soporte para MBSE: SysML es un lenguaje clave para la implementación de

MBSE. Proporciona la sintaxis y la semántica necesarias para crear modelos
 formales del sistema que pueden ser utilizados para el análisis, la simulación, la
verificación y la generación de documentación.

1.4 Introducción al Grid MBSE

Concepto Detallado:

El Grid MBSE es una matriz estructurada que sirve como marco de referencia para
organizar, visualizar y gestionar los diferentes aspectos de un sistema modelado con
SysML. Actúa como un mapa multidimensional que guía el proceso de modelado y
facilita la trazabilidad entre los diversos artefactos del modelo. No es un diagrama SysML
en sí, sino una herramienta conceptual para la organización y la navegación del modelo
del sistema.

Propósito y Beneficios:

• Organización Estructurada: El Grid proporciona una estructura clara y

consistente para organizar los modelos SysML, clasificándolos según su nivel de
abstracción y el aspecto del sistema que representan.

• Visualización Holística: Ofrece una visión general del sistema, permitiendo a

los ingenieros comprender rápidamente su alcance y complejidad.

• Navegación Intuitiva: Facilita la navegación a través de los diferentes modelos y

niveles de detalle, permitiendo a los usuarios encontrar la información que
necesitan de forma rápida y eficiente.

• Gestión de la Complejidad: Ayuda a gestionar la complejidad de los sistemas

grandes y complejos al dividirlos en partes más manejables y al visualizar las
relaciones entre ellas.

• Identificación de Lagunas: Permite identificar áreas del sistema que no han

sido modeladas o que requieren mayor detalle, asegurando la completitud del
modelo.

• Mejora de la Comunicación: Sirve como una herramienta de comunicación

efectiva entre los miembros del equipo y con las partes interesadas, al
proporcionar una representación visual y estructurada del sistema.

• Base para la Trazabilidad: Facilita el establecimiento y mantenimiento de la

trazabilidad entre los diferentes elementos del modelo, como los requisitos, el
diseño, el análisis y las pruebas.

Relación con SysML:

El Grid MBSE y SysML son conceptos complementarios que trabajan juntos para
implementar un enfoque MBSE efectivo. SysML proporciona el lenguaje de modelado
para crear los modelos del sistema, mientras que el Grid MBSE proporciona el marco de
organización para esos modelos. Cada celda del Grid corresponde a un aspecto
específico del sistema en un nivel de abstracción particular, y puede contener uno o más
diagramas SysML que modelan ese aspecto.

1.5 Alcance de la Guía

Objetivos Claros y Específicos:

Esta guía tiene como objetivo proporcionar a los lectores una comprensión profunda y
práctica de cómo implementar MBSE utilizando el lenguaje de modelado SysML y el Grid
MBSE como marco de referencia. Al finalizar la lectura de esta guía, los lectores serán
capaces de:

• Comprender los principios fundamentales de MBSE y sus beneficios.

• Dominar los conceptos clave de SysML y sus diferentes tipos de diagramas.

• Utilizar el Grid MBSE como una herramienta para organizar y gestionar modelos
de sistemas complejos.

• Desarrollar modelos SysML para diferentes aspectos y niveles de abstracción de

un sistema.

• Establecer y mantener la trazabilidad entre los diferentes elementos del modelo.

• Navegar a través del Grid MBSE para explorar el modelo del sistema desde
diferentes perspectivas.

• Conocer las herramientas de software que soportan MBSE y SysML.

• Identificar los desafíos y las mejores prácticas para la implementación de

MBSE.

Público Objetivo:

Esta guía está dirigida a un público técnico con experiencia en ingeniería de sistemas, que
incluye, pero no se limita a:

• Ingenieros de Sistemas: Responsables del diseño, desarrollo, integración y

verificación de sistemas complejos.

• Arquitectos de Sistemas: Encargados de definir la arquitectura de alto nivel de

los sistemas.

• Analistas de Requisitos: Responsables de la captura, el análisis y la gestión de

los requisitos del sistema.

• Ingenieros de Software y Hardware: Que deseen comprender cómo su trabajo

se integra en el contexto general del sistema.

• Gerentes de Proyecto: Que buscan mejorar la eficiencia y la calidad del

desarrollo de sistemas.

• Académicos e Investigadores: Interesados en el estudio y la aplicación de MBSE

y SysML.

Contenido Detallado por Capítulos:

La guía se estructura en los siguientes capítulos:

• Capítulo 1: Introducción: Presenta los conceptos fundamentales de MBSE,

SysML y el Grid MBSE, estableciendo el contexto y el alcance de la guía.
 • Capítulo 2: Fundamentos de MBSE y SysML: Profundiza en los principios de
MBSE y describe en detalle los conceptos clave de SysML, incluyendo sus nueve
tipos de diagramas.

• Capítulo 3: El Grid MBSE: Un Marco de Referencia Multidimensional: Explica la

estructura y la utilidad del Grid MBSE, detallando sus columnas (niveles de
abstracción) y filas (aspectos del sistema), así como las interconexiones y la
trazabilidad entre las celdas.

• Capítulo 4: Implementación del Grid MBSE con SysML: Guía Paso a Paso:
Proporciona una metodología detallada para aplicar el Grid MBSE en el desarrollo
de un sistema, utilizando SysML como lenguaje de modelado. Se describen las
actividades y los artefactos a generar en cada fase, siguiendo un enfoque iterativo
e incremental.

• Capítulo 5: Ejemplo Práctico: Sistema de Monitoreo de Temperatura para un

Invernadero: Ilustra la aplicación práctica del Grid MBSE y SysML a través del
desarrollo de un ejemplo concreto, mostrando cómo se completan las celdas del
Grid y cómo se generan los diagramas SysML correspondientes.

• Capítulo 6: Herramientas y Tecnologías de Soporte: Presenta una panorámica

de las herramientas de software disponibles para el modelado SysML, la gestión
de requisitos, la simulación y el análisis, y discute los criterios para su selección e
integración.

• Capítulo 7: Consideraciones Metodológicas Avanzadas: Aborda temas más

avanzados como la adaptación de MBSE a metodologías ágiles, la realización de
revisiones basadas en modelos, la gestión de la configuración del modelo, la
reutilización de modelos, la validación y verificación formal, y la integración de
MBSE con el ciclo de vida del sistema.

• Capítulo 8: Desafíos y Mejores Prácticas: Discute los desafíos comunes que se

encuentran al implementar MBSE y ofrece una serie de mejores prácticas para
superarlos y asegurar una implementación exitosa.

• Capítulo 9: Conclusiones y Perspectivas Futuras: Resume los beneficios clave

de MBSE y el Grid Estructurado, y explora las tendencias emergentes en el campo
de MBSE y SysML.

• Capítulo 10: Apéndices: Incluye un glosario de términos, plantillas de diagramas

SysML y una lista de recursos adicionales para profundizar en los temas tratados.

• Capítulo 11: Referencias Bibliográficas: Proporciona una lista de las fuentes

utilizadas en la elaboración de la guía.

Limitaciones:

Si bien esta guía abarca una amplia gama de temas relacionados con la implementación
de MBSE con SysML utilizando un Grid Estructurado, es importante reconocer algunas
limitaciones:

• Profundidad de SysML: Aunque se describen los conceptos clave de SysML, la

guía no pretende ser un tutorial exhaustivo del lenguaje. Se recomienda a los
 lectores que consulten la especificación oficial de SysML y otros recursos para
obtener una comprensión más profunda del lenguaje.

• Herramientas Específicas: La guía no se centra en el uso de una herramienta de

modelado específica. Se mencionan varias herramientas a lo largo de la guía, pero
no se proporciona un tutorial detallado de ninguna de ellas. Los lectores deberán
familiarizarse con la herramienta de su elección a través de su documentación
oficial y otros recursos de aprendizaje.

• Experiencia Práctica: Esta guía proporciona una base teórica y metodológica

sólida para la implementación de MBSE, pero no puede reemplazar la experiencia
práctica. Se recomienda a los lectores que apliquen los conceptos y las técnicas
descritas en la guía a proyectos reales para consolidar su aprendizaje.

• Dominios Específicos: Aunque los principios de MBSE y el uso del Grid son
generalmente aplicables, la guía no se enfoca en un dominio de aplicación
específico (por ejemplo, automotriz, aeroespacial, médico). Los lectores deberán
adaptar los conceptos y ejemplos presentados a su propio contexto.

2. Fundamentos de MBSE y SysML

Este capítulo profundiza en los cimientos de la Ingeniería de Sistemas Basada en Modelos

(MBSE) y el Lenguaje de Modelado de Sistemas (SysML). Se describen los principios
rectores de MBSE, se detallan los conceptos clave de SysML, incluyendo sus nueve tipos
de diagramas, y se explora la sinergia entre MBSE y SysML como habilitador clave para un
desarrollo de sistemas eficiente y robusto. Finalmente, se ofrece una visión general de las
herramientas de software que soportan la implementación de MBSE con SysML.

2.1 Principios de MBSE

MBSE se fundamenta en un conjunto de principios que guían la adopción de un enfoque

basado en modelos para la ingeniería de sistemas. Estos principios son esenciales para
comprender la filosofía de MBSE y para aplicarlo de manera efectiva.

• Modelos como Artefacto Principal (y Única Fuente de Verdad): Este es el

principio central de MBSE. Los modelos digitales del sistema se convierten en el
elemento central del proceso de desarrollo, reemplazando a los documentos
como la principal fuente de información. Esto implica que:

o El modelo es la referencia autorizada: Todas las decisiones de diseño,

análisis, verificación y validación se basan en el modelo del sistema.

o El modelo es la fuente de toda la información: Los requisitos, la

arquitectura, el comportamiento, los parámetros y las relaciones entre los
elementos del sistema se capturan y gestionan en el modelo.

o El modelo es consistente y actualizado: Se mantiene la consistencia

interna del modelo y se refleja cualquier cambio de forma inmediata,
evitando discrepancias y ambigüedades.
 o Eliminación de redundancias: Al centralizar la información en el modelo,
se elimina la necesidad de mantener múltiples documentos que
describen el mismo sistema desde diferentes perspectivas, reduciendo el
riesgo de inconsistencias.

• Abstracción y Formalismo:

o Abstracción: MBSE utiliza la abstracción para gestionar la complejidad de

los sistemas. Los modelos se crean en diferentes niveles de
abstracción, permitiendo a los ingenieros enfocarse en los aspectos
relevantes para cada etapa del desarrollo y ocultando los detalles
innecesarios.

▪ Niveles de Abstracción: Desde la concepción de alto nivel

(necesidades del negocio, necesidades del interesado) hasta el
diseño detallado, pasando por la arquitectura lógica y física.

▪ Enfoque en lo esencial: Cada nivel de abstracción se centra en un

conjunto específico de preocupaciones, permitiendo una mejor
comprensión del sistema desde diferentes perspectivas.

o Formalismo: MBSE utiliza lenguajes de modelado formales como

SysML. Un lenguaje formal posee una sintaxis y semántica bien
definidas, lo que elimina las ambigüedades inherentes al lenguaje natural
y permite la verificación automática de la consistencia del modelo.

o Beneficios del Formalismo: Precisión, consistencia, automatización

(verificación, generación de código, etc.)

• Trazabilidad y Consistencia:

o Trazabilidad: Se refiere a la capacidad de rastrear las relaciones entre

los diferentes elementos del modelo, desde los requisitos de alto nivel
hasta los componentes de diseño detallados, y viceversa.

▪ Tipos de Trazabilidad: Horizontal (entre elementos del mismo

nivel), Vertical (entre diferentes niveles de abstracción), Cruzada
(entre diferentes aspectos y niveles).

▪ Beneficios: Facilita el análisis de impacto de los cambios, asegura

que todos los requisitos se han implementado y verificado, y
proporciona una justificación para las decisiones de diseño.

o Consistencia: Se refiere a la coherencia interna del modelo, asegurando

que no haya contradicciones ni ambigüedades entre sus diferentes partes.

▪ Verificación de la Consistencia: Las herramientas de modelado

pueden verificar automáticamente la consistencia del modelo,
identificando errores de sintaxis y semántica.

▪ Importancia: Un modelo consistente es fundamental para la toma

de decisiones y para evitar errores costosos en etapas posteriores
del desarrollo.
 • Automatización:

o Objetivo: MBSE busca automatizar la mayor cantidad posible de tareas

en el proceso de desarrollo de sistemas.

o Beneficios: Reduce el tiempo y el costo de desarrollo, minimiza los

errores humanos y mejora la eficiencia general del proceso.

o Ejemplos de Automatización:

▪ Generación de Documentación: Generar automáticamente

documentos a partir del modelo.

▪ Verificación de la Consistencia: Verificar automáticamente la

consistencia del modelo.

▪ Ejecución de Simulaciones: Ejecutar modelos de simulación para

evaluar el comportamiento del sistema.

▪ Generación de Código: Generar código de software o

descripciones de hardware a partir del modelo.

• Colaboración:

o Modelos como Medio de Comunicación: Los modelos proporcionan un

lenguaje común y una representación visual del sistema que facilita la
comunicación y el entendimiento entre los miembros del equipo,
independientemente de su disciplina o especialización.

o Trabajo Concurrente: Las herramientas de modelado permiten que

varios ingenieros trabajen simultáneamente en el mismo modelo,
facilitando la colaboración y el desarrollo en paralelo.

o Integración de Disciplinas: MBSE facilita la integración de diferentes

disciplinas de ingeniería (mecánica, eléctrica, software, etc.) en un único
modelo del sistema.

• Iteración e Incrementalidad:

o Adaptabilidad al Cambio: MBSE se integra bien con metodologías de

desarrollo iterativo e incremental, como las metodologías ágiles. Los
modelos se pueden desarrollar y refinar de forma iterativa, permitiendo
una adaptación flexible a los cambios en los requisitos o en el entorno.

o Desarrollo Evolutivo: El sistema se construye de forma incremental,

añadiendo y refinando la funcionalidad en cada iteración.

o Retroalimentación Temprana: El desarrollo iterativo permite obtener

retroalimentación temprana de los interesados y realizar ajustes en el
diseño del sistema.

2.2 Conceptos Clave de SysML

SysML es el lenguaje de modelado estándar para la Ingeniería de Sistemas Basada en

Modelos. Comprender sus conceptos clave es fundamental para utilizarlo de manera
efectiva.
• 2.2.1 Diagramas de Estructura (BDD, IBD, PKG)

o Diagrama de Definición de Bloques (BDD):

▪ Propósito: El BDD es el pilar para definir la jerarquía del sistema

y la clasificación de sus componentes. Se utiliza para modelar la
estructura estática del sistema, definiendo los bloques que lo
componen, sus propiedades (atributos y operaciones) y las
relaciones entre ellos.

▪ Elementos:

▪ Bloques (Blocks): Representan los componentes del

sistema (hardware, software, personas, etc.). Pueden ser
atómicos o compuestos.

▪ Propiedades:

▪ Partes (Parts): Representan la composición de un

bloque en términos de otros bloques.

▪ Referencias (References): Representan

asociaciones entre bloques que no son de
composición.

▪ Valores (Values): Representan datos o

propiedades cuantificables de un bloque (por
ejemplo, peso, potencia, costo).

▪ Operaciones (Operations): Representan las

acciones o funciones que puede realizar un bloque.

▪ Puertos (Ports): Puntos de interacción de un bloque con

su entorno o con otros bloques. Pueden ser estándar (para
flujos de ítems) o de flujo (para flujos continuos de materia,
energía o datos).

▪ Flujos de Ítems (Item Flows): Especifican los elementos

que pueden fluir entre puertos.

▪ Relaciones:

▪ Asociación (Association): Representa una relación

semántica entre dos bloques.

▪ Generalización (Generalization): Representa una

relación de herencia entre un bloque general y un
bloque más específico (relación "es un").

▪ Composición (Composition): Representa una

relación de "todo/parte" donde la parte no puede
existir sin el todo.
 ▪ Dependencia (Dependency): Representa una
relación en la que un bloque depende de otro para
su definición o funcionamiento.

▪ Realización (Realization): Representa una relación

en la que un bloque implementa la especificación
de otro bloque.

▪ Ejemplo: En un sistema de piloto automático de un avión, se

pueden definir bloques como "Computadora de Vuelo," "Sensor de
Altitud," "Actuador de Superficie de Control," etc. Se pueden
definir sus propiedades (por ejemplo, la precisión del sensor) y las
relaciones entre ellos (por ejemplo, la computadora de vuelo
"utiliza" el sensor de altitud).

o Diagrama de Bloques Internos (IBD):

▪ Propósito: El IBD se utiliza para describir la estructura interna de

un bloque específico, mostrando cómo se conectan sus partes y
cómo fluye la información, la energía o la materia entre ellas.

▪ Elementos:

▪ Partes (Parts): Instancias de bloques que forman parte de

la estructura interna del bloque que se está describiendo.

▪ Puertos (Ports): Puntos de interacción entre las partes

internas de un bloque.

▪ Conectores (Connectors): Representan las conexiones

entre los puertos de las partes, indicando el flujo de ítems.

▪ Flujos de Ítems (Item Flows): Especifican los elementos

que pueden fluir a través de los conectores.

▪ Ejemplo: Para el bloque "Computadora de Vuelo" del ejemplo

anterior, un IBD podría mostrar cómo se conectan internamente
sus partes, como el procesador, la memoria, los puertos de
entrada/salida, etc., y cómo fluyen los datos entre ellos.

o Diagrama de Paquetes (PKG):

▪ Propósito: El PKG se utiliza para organizar los elementos del

modelo en grupos lógicos llamados paquetes y para definir las
dependencias entre estos paquetes. Facilita la gestión de la
complejidad del modelo y la modularidad.

▪ Elementos:

▪ Paquetes (Packages): Contenedores que agrupan

elementos del modelo relacionados.

▪ Dependencias (Dependencies): Indican que los

elementos de un paquete dependen de los elementos de
otro paquete.
 ▪ Importaciones (Import): Permiten que los elementos de
un paquete utilicen elementos de otro paquete.

▪ Fusiones de Paquetes (Package Merge): Permiten

combinar los contenidos de dos o más paquetes.

▪ Ejemplo: Se podrían organizar los elementos del modelo del piloto

automático en paquetes como "Requisitos," "Arquitectura Lógica,"
"Arquitectura Física," "Verificación y Validación," y definir las
dependencias entre ellos.

• 2.2.2 Diagramas de Comportamiento (UC, ACT, SD, STM)

o Diagrama de Casos de Uso (UC):

▪ Propósito: El UC se utiliza para capturar los requisitos

funcionales del sistema desde la perspectiva del usuario.
Describe cómo los actores (usuarios u otros sistemas externos)
interactúan con el sistema para lograr sus objetivos.

▪ Elementos:

▪ Actores (Actors): Representan los roles que interactúan

con el sistema.

▪ Casos de Uso (Use Cases): Representan las interacciones

entre los actores y el sistema que producen un resultado
observable de valor para un actor en particular.

▪ Relaciones:

▪ Asociación (Association): Indica que un actor

participa en un caso de uso.

▪ Inclusión (Include): Indica que un caso de uso (el

caso de uso base) incorpora el comportamiento de
otro caso de uso (el caso de uso incluido). Se utiliza
para factorizar el comportamiento común.

▪ Extensión (Extend): Indica que un caso de uso (el

caso de uso extendido) puede modificar
opcionalmente el comportamiento de otro caso de
uso (el caso de uso base) bajo ciertas condiciones.

▪ Generalización (Generalization): Indica que un

caso de uso es una especialización de otro caso de
uso más general.

▪ Ejemplo: En el sistema de piloto automático, se podrían definir

casos de uso como "Mantener Altitud," "Cambiar Rumbo," "Iniciar
Descenso," etc., y actores como "Piloto" y "Sistema de
Navegación."

o Diagrama de Actividades (ACT):

▪ Propósito: El ACT se utiliza para modelar el flujo de control y de
datos dentro de una operación, función o proceso. Describe la
secuencia de acciones, las decisiones, las concurrencias y la
sincronización de actividades.

▪ Elementos:

▪ Nodos de Acción (Action Nodes): Representan la

ejecución de una acción o tarea atómica.

▪ Nodos de Control (Control Nodes):

▪ Nodo Inicial (Initial Node): Indica el punto de inicio

del flujo de actividades.

▪ Nodo Final de Actividad (Activity Final Node):

Indica el punto de finalización del flujo de
actividades.

▪ Nodo de Decisión (Decision Node): Representa un

punto de ramificación en el flujo de control, donde
se toma una decisión en base a una condición.

▪ Nodo de Fusión (Merge Node): Representa la

unión de varios flujos de control en uno solo.

▪ Nodo de Bifurcación (Fork Node): Representa la

división del flujo de control en varios flujos
concurrentes.

▪ Nodo de Unión (Join Node): Representa la

sincronización de varios flujos concurrentes en uno
solo.

▪ Flujos de Control (Control Flows): Representan la

secuencia de ejecución de las actividades.

▪ Flujos de Objetos (Object Flows): Representan el flujo de

datos o de objetos entre las actividades.

▪ Pines de Entrada/Salida (Input/Output Pins):

Representan los datos de entrada y salida de una acción.

▪ Regiones de Expansión (Expansion Regions):

Representan la ejecución repetida de un conjunto de
actividades.

▪ Regiones de Interrupción (InterruptibleActivityRegion):

Representan una región que puede ser interrumpida por un
evento externo.

▪ Ejemplo: Se podría modelar el algoritmo de control de altitud del

piloto automático, mostrando la secuencia de acciones como leer
la altitud actual, compararla con la altitud deseada, calcular el
 ajuste necesario en las superficies de control, y enviar el comando
a los actuadores.

o Diagrama de Secuencia (SD):

▪ Propósito: El SD se utiliza para modelar la interacción entre

objetos o partes a lo largo del tiempo, mostrando el intercambio
de mensajes entre ellos en una secuencia específica.

▪ Elementos:

▪ Líneas de Vida (Lifelines): Representan la existencia de un

objeto o parte a lo largo del tiempo.

▪ Mensajes (Messages): Representan la comunicación

entre líneas de vida. Pueden ser síncronos (con retorno) o
asíncronos (sin retorno).

▪ Activaciones (Activations): Representan el período de

tiempo durante el cual una línea de vida está activa,
ejecutando una operación.

▪ Operadores de Fragmento (Combined Fragments):

Permiten modelar comportamientos condicionales (alt,
opt), iterativos (loop), paralelos (par), etc.

▪ alt: Representa una elección entre dos o más

alternativas.

▪ opt: Representa una secuencia opcional de

mensajes.

▪ loop: Representa una secuencia de mensajes que

se repite un número determinado de veces o hasta
que se cumpla una condición.

▪ par: Representa la ejecución concurrente de dos o

más secuencias de mensajes.

▪ Ejemplo: Se podría modelar la secuencia de mensajes

intercambiados entre la computadora de vuelo, el sensor de
altitud y el actuador de la superficie de control durante un ajuste
de altitud.

o Diagrama de Máquina de Estados (STM):

▪ Propósito: El STM se utiliza para modelar el comportamiento de

un objeto o sistema en términos de sus estados y las
transiciones entre ellos en respuesta a eventos.

▪ Elementos:

▪ Estados (States): Representan las diferentes condiciones

o situaciones en las que puede encontrarse un objeto o
sistema.
 ▪ Transiciones (Transitions): Representan los cambios de
estado que ocurren en respuesta a eventos.

▪ Eventos (Events): Representan los estímulos que pueden

desencadenar una transición de estado.

▪ Acciones (Actions): Representan el comportamiento que

se ejecuta durante una transición o al entrar o salir de un
estado.

▪ Pseudoestados (Pseudostates):

▪ Inicial (Initial): Indica el estado inicial del objeto o

sistema.

▪ Final (Final): Indica la finalización del ciclo de vida

del objeto o sistema.

▪ Histórico (History): Permite recordar el último

estado activo de una región ortogonal.

▪ Elección (Choice): Representa una decisión

dinámica basada en una condición.

▪ Unión (Junction): Combina multiples transiciones

entrantes en una unica transición saliente

▪ Bifurcación (Fork): Divide una transición entrante

en multiples transiciones salientes

▪ Unión (Join):

• Elementos (Continuación):

o Pseudoestados (Pseudostates) (Continuación):

▪ Entrada (Entry Point): Especifica un punto de entrada a una

máquina de estados o a un estado compuesto.

▪ Salida (Exit Point): Especifica un punto de salida de una máquina

de estados o de un estado compuesto.

▪ Terminación (Terminate): Indica la destrucción explícita de una

instancia de la máquina de estados.

o Regiones Concurrentes (Concurrent Regions): Permiten modelar el

comportamiento concurrente dentro de un estado, dividiéndolo en
regiones ortogonales que se ejecutan en paralelo.

o Ejemplo: Se podría modelar el comportamiento de la computadora de

vuelo del piloto automático en términos de sus estados (por ejemplo, "En
Espera," "Ascendiendo," "Descendiendo," "Mantenimiento de Altitud") y
las transiciones entre estos estados en respuesta a eventos como
"Cambio en la Altitud Deseada" o "Señal del Piloto."

• 2.2.3 Diagramas de Requisitos (REQ)

o Propósito: El diagrama de requisitos se utiliza para capturar, organizar,
visualizar y gestionar los requisitos del sistema. Permite modelar los
requisitos de forma estructurada y establecer relaciones entre ellos, así
como con otros elementos del modelo.

o Elementos:

▪ Requisito (Requirement): Representa una capacidad o condición

que el sistema debe satisfacer. Puede ser de diferentes tipos,
como funcional, no funcional, de rendimiento, de interfaz, etc.

▪ Relaciones de Requisitos:

▪ Contiene (Contains): Indica que un requisito se

descompone en otros requisitos más detallados.

▪ Deriva (Derive): Indica que un requisito se deriva de otro

requisito.

▪ Satisface (Satisfy): Indica que un elemento del modelo

(por ejemplo, un bloque o un caso de uso) satisface un
requisito.

▪ Verifica (Verify): Indica que un caso de prueba verifica un

requisito.

▪ Refina (Refine): Indica que un elemento del modelo refina

un requisito, proporcionando una descripción más
detallada de cómo se implementará.

▪ Traza (Trace): Una relación genérica de trazabilidad entre

un requisito y otro elemento del modelo.

▪ Tabla de Requisitos: Una representación tabular de los requisitos

que incluye sus atributos, como el identificador, la descripción, el
tipo, la prioridad, el estado, la fuente, etc.

o Ejemplo: Se pueden definir requisitos para el sistema de piloto

automático como: "El sistema mantendrá la altitud con una precisión de
±10 pies," "El sistema responderá a los comandos del piloto en menos de
0.5 segundos," "El sistema operará en un rango de temperaturas de -40°C
a +85°C," y establecer relaciones entre estos requisitos y otros elementos
del modelo, como los casos de uso, los bloques y los casos de prueba.

o Tipos de Requisitos:

▪ Requisitos Funcionales: Describen lo que el sistema debe hacer.

▪ Requisitos No Funcionales: Describen las cualidades del

sistema, como el rendimiento, la seguridad, la usabilidad, la
confiabilidad, etc.

▪ Requisitos de Rendimiento: Especifican los requisitos

cuantitativos de rendimiento del sistema (por ejemplo, velocidad,
precisión, tiempo de respuesta).
 ▪ Requisitos de Interfaz: Especifican cómo el sistema interactúa
con otros sistemas o con el entorno.

▪ Requisitos de Diseño: Restricciones impuestas al diseño del

sistema.

▪ Requisitos Derivados: Requisitos que se deducen de otros

requisitos de nivel superior.

o Relaciones entre Requisitos:

▪ Derivación: Un requisito de bajo nivel se deduce o se deriva de un

requisito de alto nivel.

▪ Satisfacción: Un elemento de diseño o un caso de uso satisface

un requisito.

▪ Verificación: Un caso de prueba verifica que el sistema cumple

con un requisito.

▪ Refinamiento: Un elemento del modelo proporciona una

descripción más detallada de un requisito.

▪ Trazabilidad: Una relación genérica que indica una conexión entre

un requisito y otro elemento del modelo.

o Atributos de Requisitos:

▪ Identificador Único: Un identificador único para cada requisito.

▪ Descripción: Una descripción clara y concisa del requisito.

▪ Tipo: El tipo de requisito (funcional, no funcional, etc.).

▪ Prioridad: La importancia relativa del requisito (por ejemplo, alta,

media, baja).

▪ Estado: El estado actual del requisito (por ejemplo, propuesto,

aprobado, implementado, verificado).

▪ Autor: La persona que creó o modificó el requisito.

▪ Fuente: El origen del requisito (por ejemplo, un documento de

especificaciones, una entrevista con un stakeholder).

▪ Riesgo: El riesgo asociado al incumplimiento del requisito.

▪ Comentarios: Cualquier comentario o nota adicional sobre el

requisito.

• 2.2.4 Diagramas Paramétricos (PAR)

o Propósito: El diagrama paramétrico se utiliza para modelar las

relaciones cuantitativas entre los parámetros del sistema y para
realizar análisis de ingeniería. Permite definir restricciones y ecuaciones
que relacionan los parámetros y se puede integrar con herramientas de
simulación y optimización.
 o Elementos:

▪ Bloque de Restricción (ConstraintBlock): Define una restricción

o ecuación que relaciona los parámetros del sistema. Contiene
una expresión matemática que debe cumplirse.

▪ Parámetros de Restricción (Constraint Parameters): Variables

que representan los parámetros del sistema que participan en la
restricción.

▪ Propiedades de Valor (Value Properties): Se ligan a los

parámetros de restricción para representar los valores específicos
utilizados en un contexto determinado.

o Ejemplo: Se podría modelar la relación entre la fuerza de empuje, la masa

del avión y la aceleración utilizando un bloque de restricción que contenga
la ecuación F = m * a.

o Uso en Análisis de Ingeniería:

▪ Simulación: Los diagramas paramétricos se pueden integrar con

herramientas de simulación para evaluar el comportamiento del
sistema bajo diferentes condiciones y valores de parámetros.

▪ Optimización: Se pueden utilizar para optimizar el diseño del

sistema, encontrando los valores de los parámetros que
maximizan el rendimiento o minimizan el costo.

▪ Análisis de Sensibilidad: Permiten evaluar cómo los cambios en

los valores de los parámetros afectan al comportamiento del
sistema.

▪ Análisis de Fallos: Se pueden utilizar para modelar las

condiciones de fallo del sistema y evaluar su impacto.

• 2.2.5 Vistas y Puntos de Vista

o Concepto: Una vista es una representación parcial del sistema, que se

enfoca en un conjunto específico de preocupaciones o intereses. Un
punto de vista define las convenciones, los tipos de diagramas y los
elementos de modelado que se utilizan para construir una vista.

o Importancia: Las vistas y los puntos de vista permiten gestionar la

complejidad del sistema al dividirlo en representaciones más pequeñas y
manejables. También facilitan la comunicación con las diferentes partes
interesadas, al proporcionarles una visión del sistema que es relevante
para sus intereses.

o Ejemplo: Se podría definir un punto de vista de "Arquitectura de Software"

que especifique que las vistas correspondientes deben utilizar diagramas
de bloques, diagramas de secuencia y diagramas de componentes para
representar la estructura y el comportamiento del software del sistema.
Luego, se podría crear una vista específica de la "Arquitectura de Software
 del Piloto Automático" que siga las convenciones definidas en el punto de
vista.

o Relación con el Grid MBSE: Los puntos de vista se pueden alinear con las
filas (aspectos) del Grid MBSE. Cada fila puede corresponder a un punto
de vista específico, y las celdas de esa fila contendrían las vistas
relevantes para ese punto de vista.

o 4+1 View Model: Un ejemplo popular de un conjunto de puntos de vista es

el modelo "4+1" de Philippe Kruchten, que define cinco vistas: Vista
Lógica, Vista de Desarrollo, Vista de Proceso, Vista Física y Escenarios
(Casos de Uso).

• 2.2.6 Perfiles y Extensiones

o Concepto: SysML es un lenguaje extensible que permite a los usuarios

adaptarlo a sus necesidades específicas. Los perfiles son un mecanismo
de extensión de UML que se utiliza en SysML para personalizar el
lenguaje para un dominio o una metodología en particular.

o Ejemplos:

▪ Perfil para Sistemas Embebidos: Podría definir estereotipos y

tagged values adicionales para modelar aspectos específicos de
los sistemas embebidos, como el consumo de energía o las
restricciones de tiempo real.

▪ Perfil para Automoción: Podría definir estereotipos para modelar

componentes automotrices específicos, como ECUs (Unidades de
Control Electrónico) o buses CAN.

▪ Perfil para una Metodología Específica: Podría definir

estereotipos y restricciones para adaptar SysML a una
metodología de desarrollo de sistemas particular, como la
metodología V-Model.

o Mecanismos de Extensión:

▪ Estereotipos (Stereotypes): Permiten extender la semántica de

los elementos de modelado existentes. Un estereotipo se aplica a
un elemento de modelado para indicar que tiene un significado o
una restricción adicional.

▪ Tagged Values: Permiten agregar propiedades adicionales a los

elementos de modelado. Un tagged value es un par clave-valor
que se puede asociar a un elemento de modelado para
proporcionar información adicional.

▪ Restricciones (Constraints): Permiten definir restricciones

adicionales sobre los elementos de modelado. Una restricción es
una expresión booleana que debe ser verdadera para que el
modelo sea válido.

2.3 Relación entre MBSE y SysML

 • SysML como Habilitador de MBSE: SysML proporciona el lenguaje de modelado
formal que es fundamental para la implementación de los principios de MBSE.
Permite la creación de modelos precisos, consistentes y no ambiguos del
sistema.

• Modelos SysML como Artefactos Centrales: En un entorno MBSE, los modelos

SysML se convierten en los artefactos centrales del proceso de desarrollo de
sistemas. Reemplazan a los documentos como la principal fuente de información
sobre el sistema.

• Trazabilidad a través de Diagramas SysML: Los diferentes diagramas SysML se

interconectan para mantener la trazabilidad entre los requisitos, el diseño, el
análisis y las pruebas. Las relaciones entre los elementos del modelo se definen
explícitamente en los diagramas, lo que permite rastrear el origen de cada
elemento y evaluar el impacto de los cambios.

• Automatización con SysML: Las herramientas de modelado SysML pueden

automatizar muchas tareas, como la generación de documentación, la
verificación de la consistencia del modelo y la ejecución de simulaciones. Esto es
posible gracias al formalismo del lenguaje SysML.

• Ejemplo: Un ingeniero de sistemas puede utilizar SysML para crear un modelo del
sistema de control de temperatura de un invernadero. El modelo incluirá
diagramas de requisitos para capturar los requisitos del sistema, diagramas de
bloques para definir la arquitectura lógica y física, diagramas de actividades para
modelar el comportamiento del sistema, y diagramas paramétricos para realizar
análisis de ingeniería. Todos estos diagramas estarán interconectados y formarán
un modelo consistente del sistema, que servirá como la fuente única de verdad
para todas las actividades de desarrollo.

2.4 Herramientas de Soporte para MBSE y SysML

La implementación efectiva de MBSE con SysML requiere el uso de herramientas de

software especializadas que faciliten la creación, gestión, análisis y visualización de los
modelos.

• Tipos de Herramientas:

o Herramientas de Modelado SysML:

▪ Funcionalidad: Estas herramientas permiten crear, editar y

visualizar diagramas SysML. Proporcionan una interfaz gráfica para
dibujar los diagramas, gestionar los elementos del modelo y definir
las relaciones entre ellos.

▪ Características Clave:

▪ Soporte completo para la especificación SysML.

▪ Interfaz gráfica intuitiva y fácil de usar.

▪ Capacidades de validación y verificación del modelo.

▪ Generación de documentación.
 ▪ Soporte para el trabajo colaborativo.

▪ Integración con otras herramientas de ingeniería.

▪ Ejemplos:

▪ Cameo Systems Modeler (No Magic, ahora parte de

Dassault Systèmes): Una herramienta comercial
ampliamente utilizada para el modelado SysML, con
capacidades avanzadas de simulación y análisis.

▪ Enterprise Architect (Sparx Systems): Otra herramienta

comercial popular que soporta SysML, UML y otros
lenguajes de modelado.

▪ Papyrus: Una herramienta de modelado de código abierto

basada en Eclipse, que soporta SysML y UML.

▪ IBM Engineering Systems Design Rhapsody: Una suite de

herramientas de ingeniería de sistemas que incluye
soporte para SysML, y análisis de trade-off, y simulación.

▪ Modelio: Otra herramienta que soporta SysML y UML, con

un enfoque en la extensibilidad y la personalización.

o Herramientas de Gestión de Requisitos:

▪ Funcionalidad: Estas herramientas permiten capturar, organizar,

gestionar y rastrear los requisitos del sistema a lo largo del ciclo de
vida del desarrollo.

▪ Características Clave:

▪ Captura de requisitos en formato estructurado.

▪ Definición de atributos de requisitos.

▪ Establecimiento de relaciones de trazabilidad entre

requisitos.

▪ Generación de matrices de trazabilidad.

▪ Gestión de cambios en los requisitos.

▪ Integración con herramientas de modelado SysML.

▪ Ejemplos:

▪ IBM DOORS Next: Una herramienta comercial

ampliamente utilizada para la gestión de requisitos en
entornos de ingeniería de sistemas.

▪ Jama Connect: Otra herramienta comercial que ofrece

capacidades robustas para la gestión de requisitos y la
colaboración.
 ▪ ReqIF Studio: Una herramienta de código abierto para la
gestión de requisitos basada en el formato ReqIF.

o Herramientas de Simulación y Análisis:

▪ Funcionalidad: Estas herramientas permiten ejecutar modelos de

simulación del sistema y realizar análisis de ingeniería, como
análisis de rendimiento, análisis de confiabilidad y análisis de
costos.

▪ Características Clave:

▪ Integración con herramientas de modelado SysML.

▪ Soporte para diferentes tipos de simulación (por ejemplo,

simulación de eventos discretos, simulación continua).

▪ Capacidades de análisis paramétrico y optimización.

▪ Ejemplos:

▪ MATLAB/Simulink: Una plataforma ampliamente utilizada

para la simulación y el análisis de sistemas dinámicos.

▪ Modelica: Un lenguaje de modelado orientado a objetos

para la simulación de sistemas físicos complejos.

▪ Ansys: Una suite de software de simulación multifísica que

se puede utilizar para analizar el comportamiento de los
sistemas en diferentes dominios (mecánico, fluido,
térmico, electromagnético).

o Herramientas de Generación de Código:

▪ Funcionalidad: Permiten generar código de software (por ejemplo,

C++, Java) o descripciones de hardware (por ejemplo, VHDL,
Verilog) a partir de modelos SysML.

▪ Beneficios: Reduce el tiempo y el esfuerzo de desarrollo, y mejora

la consistencia entre el modelo y la implementación.

o Herramientas de Gestión de Configuración:

▪ Funcionalidad: Permiten controlar las versiones de los modelos

SysML y gestionar los cambios realizados en ellos.

▪ Características Clave:

▪ Control de versiones.

▪ Gestión de cambios.

▪ Comparación de versiones.

▪ Rastreo de la historia del modelo.

▪ Ejemplos:
 ▪ Git: Un sistema de control de versiones distribuido
ampliamente utilizado.

▪ SVN (Subversion): Un sistema de control de versiones

centralizado.

• Integración de Herramientas:

o Importancia: La integración entre las diferentes herramientas es

fundamental para un flujo de trabajo eficiente en MBSE. Permite que la
información fluya sin problemas entre las diferentes etapas del desarrollo
y que los ingenieros trabajen de forma colaborativa en el mismo modelo.

o Estrategias de Integración:

▪ Intercambio de archivos: Las herramientas pueden intercambiar

información a través de archivos en formatos estándar como XMI
(XML Metadata Interchange) o ReqIF (Requirements Interchange
Format).

▪ APIs (Interfaces de Programación de Aplicaciones): Las

herramientas pueden exponer APIs que permiten a otras
herramientas acceder a sus datos y funcionalidades.

▪ Plataformas Integradas: Algunos proveedores ofrecen

plataformas integradas que combinan varias herramientas en un
único entorno.

o Ejemplo: Una herramienta de modelado SysML podría integrarse con una

herramienta de gestión de requisitos a través de ReqIF, permitiendo a los
ingenieros importar requisitos a su modelo y establecer relaciones de
trazabilidad entre los requisitos y los elementos del modelo.

Criterios para la Selección de Herramientas (Continuación):

• Soporte para SysML: La herramienta debe soportar la versión más reciente de

la especificación SysML y todos sus diagramas. Es fundamental que la
herramienta elegida maneje correctamente los nueve diagramas y permita un
modelado completo y sin restricciones dentro del estándar.

• Facilidad de Uso: La herramienta debe tener una interfaz de usuario intuitiva y

fácil de aprender, que permita a los ingenieros concentrarse en el modelado
del sistema en lugar de luchar con la herramienta. Una curva de aprendizaje
suave es esencial para una adopción exitosa.

• Capacidades de Trazabilidad: La herramienta debe permitir el

establecimiento y la visualización de relaciones de trazabilidad entre los
diferentes elementos del modelo, como requisitos, bloques, casos de uso,
etc. La trazabilidad es un aspecto crítico de MBSE.

• Integración con Otras Herramientas: La herramienta debe poder integrarse

con otras herramientas de ingeniería, como herramientas de gestión de
requisitos, simulación, análisis y gestión de configuración. La integración
fluida entre herramientas es crucial para un flujo de trabajo eficiente.
 • Escalabilidad: La herramienta debe ser capaz de manejar modelos de
sistemas grandes y complejos sin degradar su rendimiento. Debe poder
soportar el crecimiento y la evolución del modelo a lo largo del tiempo.

• Personalización y Extensibilidad: La herramienta debe permitir la

personalización de la interfaz de usuario y la extensión de sus
funcionalidades para adaptarse a las necesidades específicas del proyecto o
de la organización. La capacidad de crear perfiles y scripts personalizados es
altamente deseable.

• Soporte para Colaboración: La herramienta debe permitir que varios usuarios

trabajen simultáneamente en el mismo modelo, con mecanismos para
controlar el acceso, gestionar los cambios y resolver conflictos.

• Generación de Documentación: La herramienta debe ser capaz de generar

automáticamente documentación a partir del modelo, en diferentes formatos
(por ejemplo, HTML, PDF, Word).

• Costo: El costo de la herramienta, incluyendo las licencias, el mantenimiento

y el soporte, debe estar dentro del presupuesto del proyecto.

• Soporte y Comunidad: Es importante considerar la calidad del soporte

técnico ofrecido por el proveedor de la herramienta y la existencia de una
comunidad de usuarios activa que pueda proporcionar ayuda y compartir
experiencias.

• Reputación del Proveedor: Se debe investigar la reputación del proveedor de

la herramienta en el mercado, su experiencia en el campo de MBSE y su
compromiso con el desarrollo y la evolución de la herramienta.

Ejemplos de Flujos de Trabajo:

• Flujo de Trabajo Básico: Un ingeniero de sistemas crea un modelo SysML en

una herramienta de modelado. Los requisitos se importan desde una
herramienta de gestión de requisitos. Se establecen relaciones de
trazabilidad entre los requisitos y los elementos del modelo. Se realizan
análisis y simulaciones utilizando herramientas integradas o externas. Se
genera documentación automáticamente a partir del modelo.

• Flujo de Trabajo Avanzado: Un equipo de ingenieros trabaja

colaborativamente en un modelo SysML, utilizando una herramienta de
modelado que soporta el control de versiones y la gestión de cambios. Los
requisitos se gestionan en una herramienta especializada que se integra con
la herramienta de modelado. Se realizan simulaciones y análisis utilizando
una variedad de herramientas, y los resultados se integran de nuevo en el
modelo. Se genera código automáticamente a partir del modelo para la
implementación del sistema.

El Grid MBSE: Un Marco de Referencia Multidimensional

Este capítulo profundiza en el Grid MBSE, un marco de referencia esencial para la

implementación efectiva de la Ingeniería de Sistemas Basada en Modelos (MBSE). Se
describe en detalle su estructura, compuesta por columnas que representan los niveles
de abstracción y filas que representan los aspectos del sistema. Se explora cómo las
interconexiones y la trazabilidad entre las celdas del Grid dan lugar a un sistema
coherente y gestionable. Finalmente, se ilustra cómo navegar a través del Grid para
obtener una comprensión profunda del sistema modelado.

3.1 Estructura del Grid MBSE

El Grid MBSE es una matriz o tabla bidimensional que organiza los diferentes elementos
de un modelo de sistema de acuerdo a dos dimensiones principales: niveles de
abstracción (columnas) y aspectos del sistema (filas). Esta estructura proporciona una
forma sistemática de descomponer un sistema complejo en partes más manejables,
facilitando su análisis, diseño y desarrollo.

Concepto:

El Grid MBSE no es un diagrama SysML en sí mismo, sino una herramienta conceptual,

un marco organizativo, que ayuda a los ingenieros de sistemas a estructurar su enfoque
de modelado y a gestionar la complejidad inherente a los sistemas modernos. Actúa
como un mapa global que guía la creación, interconexión y navegación de los modelos
SysML, asegurando que todas las facetas del sistema se consideren de manera
coherente y completa.

Importancia:

• Organización: Proporciona una estructura clara para organizar los artefactos del
modelo (diagramas SysML, requisitos, documentos, etc.).

• Completitud: Ayuda a garantizar que todos los aspectos relevantes del sistema
se han considerado y modelado en el nivel de detalle adecuado.

• Trazabilidad: Facilita el establecimiento y mantenimiento de la trazabilidad entre

los diferentes elementos del modelo, permitiendo rastrear el origen de los
requisitos, evaluar el impacto de los cambios y verificar la implementación.

• Comunicación: Sirve como una herramienta de comunicación eficaz entre los

miembros del equipo y con las partes interesadas, al ofrecer una visión general
del sistema y su estructura.

• Navegación: Permite navegar por el modelo del sistema de forma intuitiva,

siguiendo hilos de pensamiento específicos (por ejemplo, un hilo de requisitos o
un hilo de funcionalidad).

• Gestión de la Complejidad: Al dividir el sistema en partes más pequeñas y

manejables (celdas del Grid), se facilita la comprensión y el desarrollo de
sistemas complejos.

3.1.1 Columnas: Niveles de Abstracción / Perspectivas

Las columnas del Grid MBSE representan los diferentes niveles de abstracción o
perspectivas desde las que se puede analizar y diseñar un sistema. Estos niveles van
desde la concepción de alto nivel, impulsada por las necesidades del negocio, hasta la
implementación física y el mantenimiento. Cada columna representa una etapa en el
proceso de refinamiento del sistema, donde los conceptos se vuelven progresivamente
más concretos.
• [Link] Necesidades del Negocio (Business Needs):

o Definición: Esta columna captura la motivación estratégica detrás del

desarrollo del sistema. Se enfoca en el "por qué" se necesita el sistema
desde una perspectiva empresarial. Aquí se definen los objetivos de alto
nivel que el sistema debe ayudar a alcanzar.

o Enfoque: Valor para el negocio, retorno de la inversión, ventaja

competitiva, oportunidades de mercado.

o Artefactos Típicos:

▪ Documento de Visión: Describe la visión general del sistema y su

contribución a los objetivos del negocio.

▪ Análisis de Mercado: Estudios de mercado, análisis de la

competencia, identificación de las necesidades del cliente.

▪ Modelo de Negocio (Ej. Business Model Canvas): Describe cómo

el sistema creará, entregará y capturará valor.

▪ Análisis de Costo-Beneficio: Evaluación de los costos y

beneficios del desarrollo del sistema.

o Ejemplo: Para un sistema de piloto automático, la necesidad del negocio

podría ser "aumentar la seguridad y la eficiencia del vuelo para reducir los
costos operativos y mejorar la satisfacción del cliente."

o Diagramas SysML Relevantes (Aunque no se modela con SysML per

se): Diagramas de contexto o casos de uso de alto nivel para representar
la interacción del negocio con sistemas externos.

• [Link] Necesidades del Interesado (Stakeholder Needs):

o Definición: Esta columna se centra en las expectativas y deseos de

todas las partes interesadas (stakeholders) que interactuarán con el
sistema o se verán afectadas por él. Se trata de entender el "qué" espera
cada stakeholder del sistema.

o Enfoque: Identificar a todos los stakeholders (usuarios finales,

operadores, administradores, reguladores, etc.) y comprender sus
necesidades y preocupaciones.

o Artefactos Típicos:

▪ Lista de Interesados: Identificación de todos los stakeholders y

sus roles en relación con el sistema.

▪ Diagrama de Contexto: Representación gráfica del sistema y su

entorno, mostrando los stakeholders como actores externos.

▪ Casos de Uso de Alto Nivel: Descripción de las interacciones

entre los stakeholders y el sistema.

▪ Tabla de Necesidades: Documentación de las necesidades de

cada stakeholder en un formato tabular.
 ▪ Entrevistas y Encuestas: Resultados de las actividades de
elicitación de necesidades.

o Ejemplo: Para el sistema de piloto automático, los stakeholders podrían

incluir pilotos, copilotos, personal de mantenimiento, pasajeros y la FAA
(Administración Federal de Aviación). Las necesidades de los pilotos
podrían incluir "controlar la aeronave de forma segura y eficiente,"
mientras que las necesidades de los pasajeros podrían incluir "viajar con
seguridad y comodidad."

o Diagramas SysML Relevantes: Diagrama de Contexto (BDD), Casos de

Uso (UC).

• [Link] Requisitos del Sistema (System Requirements):

o Definición: Esta columna traduce las necesidades de los interesados en

especificaciones técnicas precisas y medibles que definen lo que el
sistema debe hacer, bajo qué condiciones y con qué nivel de
rendimiento. Se define el "qué" técnico del sistema.

o Enfoque: Definir requisitos claros, concisos, no ambiguos, verificables y

trazables.

o Artefactos Típicos:

▪ Diagrama de Requisitos (REQ): Representación gráfica de los

requisitos y sus relaciones.

▪ Tabla de Requisitos: Documentación de los requisitos en un

formato tabular, incluyendo atributos como el identificador, la
descripción, el tipo, la prioridad, el estado, la fuente, la
justificación y los criterios de aceptación.

▪ Casos de Uso Detallados: Descripción detallada de las

interacciones entre los actores y el sistema, incluyendo el flujo de
eventos, las precondiciones y las poscondiciones.

▪ Especificación de Requisitos del Sistema (SRS): Documento

formal que contiene todos los requisitos del sistema.

o Ejemplo: Para el sistema de piloto automático, los requisitos del sistema

podrían incluir: "El sistema mantendrá la altitud con una precisión de ±10
pies," "El sistema responderá a los comandos del piloto en menos de 0.5
segundos," "El sistema operará en un rango de temperaturas de -40°C a
+85°C."

o Diagramas SysML Relevantes: Diagrama de Requisitos (REQ), Casos de

Uso (UC).

• [Link] Arquitectura Lógica (Logical Architecture):

o Definición: Esta columna describe la estructura funcional del sistema,

independientemente de la tecnología de implementación. Define los
bloques lógicos que realizan las funciones del sistema y cómo
 interactúan entre sí para cumplir con los requisitos. Se define el "cómo"
funcional del sistema.

o Enfoque: Descomposición funcional, interfaces lógicas, flujo de

información y control.

o Artefactos Típicos:

▪ Diagrama de Definición de Bloques (BDD): Representación de la

descomposición funcional del sistema en bloques lógicos.

▪ Diagrama de Bloques Internos (IBD): Descripción de las

interfaces lógicas entre los bloques lógicos.

▪ Diagrama de Actividades (ACT): Modelado del flujo de

actividades y la lógica de control dentro de cada bloque lógico.

▪ Diagrama de Secuencia (SD): Modelado de las interacciones y el

intercambio de mensajes entre los bloques lógicos.

▪ Diagrama de Máquina de Estados (STM): Modelado del

comportamiento de los bloques lógicos en términos de estados y
transiciones.

▪ Diagramas Paramétricos (PAR): Para la definición de

restricciones y análisis a nivel lógico.

o Ejemplo: Para el sistema de piloto automático, la arquitectura lógica

podría descomponerse en bloques lógicos como "Control de Navegación,"
"Control de Actitud," "Gestión de Interfaces de Usuario," y "Gestión de
Datos." Los diagramas IBD mostrarían las interfaces lógicas entre estos
bloques, como el intercambio de datos de posición, altitud, velocidad,
etc.

o Diagramas SysML Relevantes: BDD, IBD, ACT, SD, STM, PAR.

• [Link] Arquitectura Física (Physical Architecture):

o Definición: Esta columna describe la implementación física del sistema,

definiendo los componentes concretos de hardware, software y
personas que se utilizarán para realizar las funciones descritas en la
arquitectura lógica. Se define el "cómo" físico o de implementación del
sistema.

o Enfoque: Selección de componentes, interfaces físicas, asignación de

funciones a componentes, despliegue del sistema.

o Artefactos Típicos:

▪ Diagrama de Definición de Bloques (BDD): Representación de

los componentes físicos del sistema (hardware, software,
personas).

▪ Diagrama de Bloques Internos (IBD): Descripción de las

interfaces físicas entre los componentes.
 ▪ Diagramas de Despliegue: Muestran cómo se distribuyen los
componentes en el entorno de operación.

▪ Diagrama de Paquetes (PKG): Para la organización de

componentes en subsistemas físicos.

o Ejemplo: Para el sistema de piloto automático, la arquitectura física

podría especificar el uso de una computadora de vuelo específica,
sensores de altitud y velocidad, actuadores para las superficies de
control, una red de comunicación CAN bus, y el software de control de
vuelo.

o Diagramas SysML Relevantes: BDD, IBD, PKG.

• [Link] Diseño Detallado (Detailed Design):

o Definición: Esta columna proporciona las especificaciones detalladas

de cada componente del sistema, incluyendo su diseño interno,
interfaces a bajo nivel y comportamiento. Es el nivel de mayor detalle
técnico en el Grid.

o Enfoque: Especificación exhaustiva de cada componente para su

implementación.

o Artefactos Típicos:

▪ Especificaciones de interfaces a bajo nivel: Protocolos de

comunicación detallados, formatos de datos, etc.

▪ Pseudocódigo o código fuente: Para el software.

▪ Esquemas de circuitos: Para el hardware.

▪ Diagramas de clases detallados: Para el software.

▪ Modelos CAD: Para los componentes mecánicos.

o Ejemplo: Para el sistema de piloto automático, el diseño detallado podría

incluir el pseudocódigo del algoritmo de control de altitud, el esquema del
circuito del sensor de altitud, la especificación detallada del protocolo de
comunicación CAN bus, etc.

o Diagramas SysML Relevantes: Depende del componente. Pueden ser

BDDs, IBDs o incluso la evolución de diagramas de comportamiento como
SDs o STMs con un nivel de detalle de implementación.

• [Link] Verificación y Validación (Verification & Validation):

o Definición: Esta columna define cómo se verificará que el sistema

cumple con los requisitos (verificación) y cómo se validará que satisface
las necesidades de los interesados (validación). La verificación se centra
en la pregunta "¿Estamos construyendo el sistema correctamente?"
mientras que la validación se centra en "¿Estamos construyendo el
sistema correcto?".
 o Enfoque: Planificación de pruebas, definición de casos de prueba,
trazabilidad con los requisitos, análisis de riesgos.

o Artefactos Típicos:

▪ Plan de Verificación y Validación: Describe la estrategia general

de verificación y validación.

▪ Casos de Prueba: Definen los pasos específicos para verificar un

requisito o validar una necesidad.

▪ Matriz de Trazabilidad de Requisitos: Vincula los requisitos con

los casos de prueba.

▪ Informes de Pruebas: Documentan los resultados de las pruebas.

▪ Análisis de Riesgos (FMEA): Identifica los posibles fallos del

sistema y sus efectos.

▪ Resultados de Simulaciones: Que sirvan como evidencia de la

verificación de requisitos a través de modelado.

o Ejemplo: Para el sistema de piloto automático, se podrían definir casos de

prueba para verificar que el sistema mantiene la altitud con la precisión
especificada, que responde a los comandos del piloto en el tiempo
requerido, y que genera las alertas correctas en caso de fallo.

o Diagramas SysML Relevantes: Diagramas de comportamiento (ACT, SD,

STM) para modelar casos de prueba, Diagrama de Requisitos (REQ) para la
trazabilidad.

• [Link] Operaciones y Mantenimiento (Operations & Maintenance):

o Definición: Esta columna considera los aspectos relacionados con la

operación, el soporte y el mantenimiento del sistema a lo largo de su
ciclo de vida.

o Enfoque: Facilidad de uso, mantenimiento, reparabilidad,

actualizaciones, gestión de fallos.

o Artefactos Típicos:

▪ Manual de Usuario: Instrucciones para el uso del sistema.

▪ Manual de Mantenimiento: Procedimientos para el

mantenimiento preventivo y correctivo del sistema.

▪ Plan de Actualización de Software: Define cómo se actualizará el

software del sistema a lo largo del tiempo.

▪ Procedimientos de Gestión de Fallos: Describe cómo se

detectarán, diagnosticarán y resolverán los fallos del sistema.

▪ Análisis de Costos del Ciclo de Vida: Estima los costos de

operación y mantenimiento del sistema.
 ▪ Planes de Entrenamiento: Para operadores y personal de
mantenimiento.

o Ejemplo: Para el sistema de piloto automático, se podría definir un

procedimiento para la calibración periódica de los sensores, un plan para
la actualización del software de control de vuelo y un manual de usuario
para los pilotos.

o Diagramas SysML Relevantes: Depende del artefacto. Podrían utilizarse

diagramas de actividades (ACT) para modelar procedimientos de
mantenimiento o casos de uso para describir la interacción del usuario
con el sistema.

3.1.2 Filas: Aspectos del Sistema (Modelado)

Las filas del Grid MBSE representan los diferentes aspectos o perspectivas desde las
que se puede modelar un sistema. Estas filas están estrechamente relacionadas con los
tipos de diagramas SysML y proporcionan una forma de organizar los modelos de
acuerdo con la información que capturan.

• [Link] Estructura (Composición, Interfaces, Contexto):

o Definición: Esta fila se centra en la composición estática del sistema,

sus partes, sus relaciones y su entorno. Responde a preguntas como: ¿De
qué está hecho el sistema? ¿Cómo se relacionan sus partes? ¿Cómo
interactúa con su entorno?

o Composición:

▪ Enfoque: Descomposición del sistema en sus subcomponentes y

la definición de las relaciones de "todo/parte".

▪ Diagramas SysML Relevantes: BDD, PKG.

▪ Ejemplo: Descomponer el sistema de piloto automático en sus

componentes principales (computadora de vuelo, sensores,
actuadores) y luego descomponer cada componente en sus
subcomponentes.

o Interfaces:

▪ Enfoque: Definición de los puntos de interacción entre los

componentes del sistema o entre el sistema y su entorno.

▪ Diagramas SysML Relevantes: IBD.

▪ Ejemplo: Definir las interfaces entre la computadora de vuelo y los

sensores (por ejemplo, la señal analógica que representa la
altitud), o entre la computadora de vuelo y los actuadores (por
ejemplo, la señal de control que ajusta las superficies de control).

o Contexto:

▪ Enfoque: Descripción del entorno externo del sistema y cómo

interactúa con él.
 ▪ Diagramas SysML Relevantes: Diagrama de Contexto (BDD o
específico), Casos de Uso de alto nivel.

▪ Ejemplo: Mostrar el sistema de piloto automático interactuando

con los pilotos, el sistema de navegación, el control de tráfico
aéreo y el entorno físico (por ejemplo, la atmósfera).

• [Link] Comportamiento (Funcionalidad, Interacciones, Estados):

o Definición: Esta fila se centra en los aspectos dinámicos del sistema,

describiendo cómo funciona, cómo interactúan sus partes y cómo cambia
su estado a lo largo del tiempo. Responde a preguntas como: ¿Qué hace
el sistema? ¿Cómo se comunican sus partes? ¿Cómo responde a los
estímulos externos?

o Funcionalidad:

▪ Enfoque: Descripción de las acciones y procesos que realiza el

sistema o sus componentes.

▪ Diagramas SysML Relevantes: UC, ACT.

▪ Ejemplo: Modelar la función de "Mantener Altitud" del piloto

automático como un diagrama de actividades que muestra los
pasos involucrados en la lectura de la altitud actual, la
comparación con la altitud deseada y el ajuste de las superficies
de control.

o Interacciones:

▪ Enfoque: Descripción del intercambio de información, energía o

materia entre los componentes del sistema o entre el sistema y su
entorno.

▪ Diagramas SysML Relevantes: SD.

▪ Ejemplo: Modelar la secuencia de mensajes intercambiados entre

la computadora de vuelo, los sensores y los actuadores durante
una maniobra de cambio de rumbo.

o Estados:

▪ Enfoque: Descripción de los diferentes modos operativos o

condiciones del sistema y las transiciones entre ellos.

▪ Diagramas SysML Relevantes: STM.

▪ Ejemplo: Modelar los estados de la computadora de vuelo del

piloto automático (por ejemplo, "En Espera," "Ascendiendo,"
"Descendiendo," "Mantenimiento de Altitud," "Alerta") y las
transiciones entre estos estados en respuesta a eventos como
"Cambio en la Altitud Deseada," "Señal del Piloto" o "Fallo de un
Sensor."

• [Link] Requisitos (Tipos, Relaciones, Atributos):

 o Definición: Esta fila se centra en la captura, organización y gestión de los
requisitos del sistema. Responde a preguntas como: ¿Qué debe hacer el
sistema? ¿Qué restricciones se le imponen? ¿Cómo se relacionan los
requisitos entre sí?

o Tipos:

▪ Enfoque: Clasificación de los requisitos según su naturaleza

(funcionales, no funcionales, de rendimiento, de interfaz, de
diseño, etc.).

▪ Diagramas SysML Relevantes: REQ.

▪ Ejemplo: Definir requisitos funcionales (por ejemplo, "El sistema

mantendrá la altitud"), requisitos de rendimiento (por ejemplo, "El
sistema responderá a los comandos del piloto en menos de 0.5
segundos"), requisitos de interfaz (por ejemplo, "El sistema se
comunicará con el sistema de navegación a través de un bus
CAN").

o Relaciones:

▪ Enfoque: Descripción de las dependencias y relaciones lógicas

entre los requisitos (derivación, satisfacción, verificación,
refinamiento, trazabilidad).

▪ Diagramas SysML Relevantes: REQ.

▪ Ejemplo: Mostrar que el requisito de "Mantener Altitud con una

Precisión de ±10 pies" se deriva de la necesidad del interesado de
"Volar de forma segura y estable." También se puede mostrar que
un caso de prueba específico verifica el cumplimiento de ese
requisito.

o Atributos:

▪ Enfoque: Definición de los metadatos asociados a los requisitos,

como el identificador, la descripción, la prioridad, el estado, la
fuente, la justificación, etc.

▪ Diagramas SysML Relevantes: REQ (en tablas o como

propiedades de los elementos de requisito).

▪ Ejemplo: Asignar a cada requisito un identificador único, una

descripción clara, una prioridad (por ejemplo, alta, media, baja),
un estado (por ejemplo, aprobado, en revisión, implementado), la
fuente del requisito (por ejemplo, documento de especificaciones
del cliente) y una justificación.

• [Link] Paramétricos / Análisis (Restricciones, Simulación, Optimización,

Riesgos, Costos):

o Definición: Esta fila se centra en el modelado cuantitativo del sistema y

en la realización de análisis de ingeniería para evaluar su rendimiento,
 confiabilidad, costo y otros aspectos. Responde a preguntas como:
¿Cuáles son las relaciones cuantitativas entre los parámetros del
sistema? ¿Cómo se comporta el sistema bajo diferentes condiciones?
¿Cuál es el diseño óptimo?

o Restricciones:

▪ Enfoque: Modelado de las limitaciones físicas, matemáticas o de

diseño que se imponen al sistema o a sus componentes.

▪ Diagramas SysML Relevantes: PAR.

▪ Ejemplo: Modelar la restricción de que la fuerza de empuje

generada por los motores del avión no puede exceder un valor
máximo determinado.

o Simulación:

▪ Enfoque: Ejecución de modelos dinámicos del sistema para

predecir su comportamiento a lo largo del tiempo y bajo diferentes
condiciones.

▪ Diagramas SysML Relevantes: PAR (integrado con herramientas

de simulación como MATLAB/Simulink u OpenModelica).

▪ Ejemplo: Simular el comportamiento del sistema de piloto

automático durante un despegue, un aterrizaje o en condiciones
de turbulencia para evaluar su estabilidad y rendimiento.

o Optimización:

▪ Enfoque: Búsqueda del diseño óptimo del sistema que maximice

el rendimiento, minimice el costo o satisfaga otros criterios de
optimización, sujeto a las restricciones definidas.

▪ Diagramas SysML Relevantes: PAR (integrado con herramientas

de optimización).

▪ Ejemplo: Optimizar los parámetros del algoritmo de control de

altitud del piloto automático para minimizar el consumo de
combustible y maximizar la precisión del control.

o Riesgos:

▪ Enfoque: Identificación, análisis y mitigación de los riesgos

potenciales que pueden afectar al sistema.

▪ Artefactos Asociados: FMEA (Análisis Modal de Fallos y Efectos),

Árboles de Fallos, Matrices de Riesgo.

▪ Ejemplo: Realizar un análisis FMEA para identificar los posibles

modos de fallo del sistema de piloto automático, sus causas y sus
efectos, y definir acciones de mitigación para reducir la
probabilidad o el impacto de esos fallos.

o Costos:
 ▪ Enfoque: Estimación y análisis de los costos asociados al
desarrollo, producción, operación y mantenimiento del sistema.

▪ Artefactos Asociados: Modelos de Costos, Análisis de Costo-

Beneficio, Análisis del Costo del Ciclo de Vida.

▪ Ejemplo: Desarrollar un modelo de costos para estimar el costo

total de propiedad del sistema de piloto automático a lo largo de
su vida útil, incluyendo los costos de desarrollo, producción,
operación, mantenimiento y retirada.

3.2 Interconexiones y Trazabilidad en el Grid MBSE

Uno de los aspectos más poderosos del Grid MBSE es su capacidad para representar y
gestionar las interconexiones entre los diferentes elementos del modelo. Estas
interconexiones son fundamentales para mantener la consistencia del modelo, asegurar
la completitud del diseño y facilitar el análisis de impacto de los cambios. La
trazabilidad, es decir, la capacidad de rastrear las relaciones entre los elementos del
modelo, es una consecuencia directa de estas interconexiones.

• 3.2.1 Trazabilidad Horizontal:

o Definición: La trazabilidad horizontal se refiere a las conexiones entre

elementos del modelo que se encuentran en la misma fila del Grid, es
decir, que pertenecen al mismo aspecto del sistema. Estas conexiones
muestran cómo se relacionan los diferentes artefactos que describen un
mismo aspecto, por ejemplo, cómo un diagrama de actividades se
relaciona con un diagrama de secuencia que describe la misma función,
pero desde una perspectiva diferente.

o Ejemplo: En la fila de "Comportamiento" y la columna de "Arquitectura

Lógica", un diagrama de actividades (ACT) que describe el flujo de control
de la función "Mantener Altitud" se puede conectar a un diagrama de
secuencia (SD) que muestra los mensajes intercambiados entre los
bloques lógicos durante la ejecución de esa función. Esta conexión
horizontal permite comprender cómo la funcionalidad descrita en el
diagrama de actividades se implementa a través de la interacción entre
los bloques. Otro ejemplo sería en la fila de "Requisitos" donde todos los
requisitos deberían estar en una misma tabla, pero por necesidades del
proyecto, se decide separarlos en varias tablas. La trazabilidad horizontal
permite ver como un cambio en un requisito de una tabla impacta los
requisitos de las demás tablas.

o Beneficios:

▪ Consistencia: Asegura que los diferentes modelos que describen

el mismo aspecto del sistema sean consistentes entre sí.

▪ Completitud: Ayuda a identificar lagunas o solapamientos en la

descripción de un aspecto del sistema.
 ▪ Comprensión: Facilita la comprensión de cómo los diferentes
modelos se complementan entre sí para describir un aspecto del
sistema.

• 3.2.2 Trazabilidad Vertical:

o Definición: La trazabilidad vertical se refiere a las conexiones entre

elementos del modelo que se encuentran en la misma columna del
Grid, es decir, que pertenecen al mismo nivel de abstracción. Estas
conexiones muestran cómo los conceptos se refinan y se hacen más
concretos a medida que se desciende en los niveles de abstracción,
desde las necesidades del negocio hasta el diseño detallado.

o Ejemplo: En la columna de "Requisitos del Sistema", un requisito de alto

nivel como "El sistema mantendrá la altitud de la aeronave" se puede
conectar a requisitos de más bajo nivel que lo refinan, como "El sistema
controlará la altitud con una precisión de ±10 pies" y "El sistema
responderá a cambios en la altitud deseada en menos de 0.5 segundos".
Esta conexión vertical muestra cómo un requisito general se descompone
en requisitos más específicos. Otro ejemplo se puede ver en la columna
de "Arquitectura Lógica" donde un BDD de alto nivel de la arquitectura se
puede conectar a BDDs de menor nivel que lo refinan.

o Beneficios:

▪ Refinamiento Progresivo: Permite rastrear cómo los conceptos

se van refinando y detallando a medida que se avanza en el
proceso de desarrollo.

▪ Consistencia entre Niveles: Asegura que los diferentes niveles de

abstracción sean consistentes entre sí y que los niveles inferiores
implementen correctamente los conceptos definidos en los
niveles superiores.

▪ Gestión del Cambio: Facilita la evaluación del impacto de los

cambios en un nivel de abstracción sobre los demás niveles.

• 3.2.3 Trazabilidad Cruzada:

o Definición: La trazabilidad cruzada se refiere a las conexiones entre

elementos del modelo que se encuentran en diferentes filas y
columnas del Grid. Estas conexiones son las más complejas y
representan las relaciones entre diferentes aspectos del sistema y
diferentes niveles de abstracción.

o Ejemplo: Un requisito del sistema (columna "Requisitos del Sistema", fila

"Requisitos") se puede conectar a un caso de uso (columna "Requisitos
del Sistema", fila "Comportamiento") que describe cómo se utilizará el
sistema para satisfacer ese requisito. A su vez, el caso de uso se puede
conectar a un diagrama de actividades (columna "Arquitectura Lógica",
fila "Comportamiento") que describe la función del sistema que
implementa el caso de uso. Finalmente, el diagrama de actividades se
 puede conectar a un bloque lógico (columna "Arquitectura Lógica", fila
"Estructura") que realiza la función, y a un caso de prueba (columna
"Verificación y Validación", fila "Comportamiento") que verifica que el
bloque lógico cumple con el requisito. Esta conexión cruzada permite
rastrear un requisito desde su origen hasta su implementación y
verificación. Otro ejemplo es la conexión de un bloque en la arquitectura
lógica (columna "Arquitectura Lógica" y fila "Estructura") con su respectivo
bloque en la arquitectura física (columna "Arquitectura Física" y fila
"Estructura).

o Beneficios:

▪ Validación de la Arquitectura: Permite verificar que la

arquitectura del sistema satisface los requisitos y que se han
considerado todos los aspectos relevantes.

▪ Análisis de Impacto: Facilita la evaluación del impacto de los

cambios en un elemento del modelo sobre otros elementos,
incluso si pertenecen a diferentes aspectos o niveles de
abstracción.

▪ Verificación Completa: Asegura que todos los requisitos se han

implementado y verificado correctamente.

• 3.2.4 Relaciones de Satisfacción, Verificación, Derivación, Composición y

Descomposición:

o Satisfacción (Satisfy):

▪ Definición: Indica que un elemento del modelo (por ejemplo, un

bloque, un caso de uso, una actividad) cumple con un requisito.
Establece una conexión directa entre el diseño y los requisitos.

▪ Ejemplo: Un bloque lógico "Controlador de Altitud" puede

satisfacer el requisito "El sistema mantendrá la altitud de la
aeronave."

o Verificación (Verify):

▪ Definición: Indica que un caso de prueba u otro artefacto de

verificación (por ejemplo, un análisis o una inspección) verifica el
cumplimiento de un requisito o de un elemento de diseño.

▪ Ejemplo: Un caso de prueba "Prueba de Mantenimiento de Altitud"

puede verificar el requisito "El sistema mantendrá la altitud con
una precisión de ±10 pies."

o Derivación (Derive):

▪ Definición: Indica que un requisito se ha deducido o se ha

derivado de otro requisito de nivel superior o de una necesidad
del interesado.
 ▪ Ejemplo: El requisito "El sistema controlará la altitud con una
precisión de ±10 pies" puede derivarse del requisito de más alto
nivel "El sistema mantendrá la altitud de la aeronave" o de la
necesidad del interesado "Volar de forma segura y estable."

o Composición y Descomposición:

▪ Definición: Indican una relación jerárquica entre elementos del

modelo, donde un elemento se compone de otros elementos
(composición) o un elemento se descompone en otros elementos
(descomposición).

▪ Ejemplo: En la arquitectura lógica, el sistema de piloto automático

se puede descomponer en bloques lógicos como "Control de
Navegación," "Control de Actitud," etc. (descomposición). A su
vez, el bloque lógico "Control de Actitud" se puede componer de
varios sub-bloques (composición).

o Importancia: Estas relaciones son fundamentales para establecer la

trazabilidad en el modelo y para asegurar que el sistema se ha diseñado y
verificado de acuerdo con los requisitos y las necesidades de los
interesados.

3.3 Navegación a través del Grid MBSE

El Grid MBSE no solo sirve como una herramienta de organización, sino también como
una herramienta de navegación que permite a los ingenieros explorar el modelo del
sistema desde diferentes perspectivas y seguir hilos de pensamiento específicos.

• 3.3.1 Hilo de Requisitos:

o Descripción: Este hilo permite rastrear un requisito específico a través

de los diferentes niveles de abstracción y aspectos del sistema. Comienza
con la identificación de un requisito en la columna "Requisitos del
Sistema" y luego se sigue su rastro a través de las celdas del Grid para ver
cómo se implementa, se verifica y se valida.

o Navegación:

1. Origen: Comenzar con el requisito en la columna "Requisitos del

Sistema" y la fila "Requisitos."

2. Satisfacción: Identificar los casos de uso o las funciones que

satisfacen el requisito (fila "Comportamiento").

3. Implementación: Rastrear las funciones hasta los bloques lógicos

o físicos que las implementan (filas "Estructura").

4. Verificación: Identificar los casos de prueba o los análisis que

verifican el requisito (columna "Verificación y Validación").

5. Validación: Conectar con las necesidades de los interesados

(columna "Necesidades del Interesado") para asegurar que el
requisito contribuye a satisfacer esas necesidades.
 o Ejemplo: Para el requisito "El sistema mantendrá la altitud con una
precisión de ±10 pies", se puede seguir el hilo de requisitos para
identificar:

▪ Los casos de uso relacionados con el mantenimiento de la altitud.

▪ Los diagramas de actividades o de secuencia que describen la

función de control de altitud.

▪ Los bloques lógicos y físicos responsables de implementar la

función.

▪ Los casos de prueba que verifican la precisión del control de

altitud.

▪ Las necesidades de los interesados que originaron el requisito.

• 3.3.2 Hilo de Funcionalidad:

• Descripción: Este hilo permite explorar cómo una función específica del sistema
se realiza a través de los diferentes niveles de abstracción y aspectos del sistema.
Comienza con la identificación de una función en la columna "Arquitectura
Lógica" y luego se sigue su rastro a través de las celdas del Grid para ver cómo se
define, se implementa y se verifica.

• Navegación:

1. Origen: Comenzar con la función en la columna "Arquitectura Lógica" (por

ejemplo, un diagrama de actividades en la fila "Comportamiento").

2. Descomposición: Explorar cómo la función se descompone en

subfunciones o actividades más detalladas (en la misma columna o en
columnas posteriores).

3. Realización: Identificar los bloques lógicos o físicos que realizan la

función (fila "Estructura").

4. Interacciones: Examinar los diagramas de secuencia o de estados

relacionados para comprender cómo interactúa la función con otros
elementos del sistema (fila "Comportamiento").

5. Requisitos: Identificar los requisitos del sistema que son satisfechos por
la función (columna "Requisitos del Sistema").

6. Verificación: Rastrear la función hasta los casos de prueba o los análisis

que verifican su correcta implementación (columna "Verificación y
Validación").

• Ejemplo: Para la función "Mantener Altitud" del sistema de piloto automático, se

puede seguir el hilo de funcionalidad para:

o Examinar el diagrama de actividades que describe los pasos involucrados

en la función.

o Identificar los bloques lógicos, como el "Controlador de Altitud," que

realizan la función.
 o Ver los diagramas de secuencia que muestran cómo el "Controlador de
Altitud" interactúa con otros bloques.

o Rastrear la función hasta los requisitos del sistema relacionados con el

mantenimiento de la altitud.

o Identificar los casos de prueba que verifican el correcto funcionamiento

de la función.

3.3.3 Hilo de Verificación:

• Descripción: Este hilo permite examinar cómo se verifica un elemento

específico del sistema, como un requisito, un bloque o una función. Comienza
con la identificación del elemento a verificar y luego se sigue su rastro a través de
las celdas del Grid para ver qué casos de prueba, análisis o inspecciones se
utilizan para verificarlo.

• Navegación:

1. Origen: Comenzar con el elemento a verificar (por ejemplo, un requisito

en la columna "Requisitos del Sistema").

2. Verificación: Identificar los casos de prueba, análisis o inspecciones que

verifican el elemento (columna "Verificación y Validación").

3. Implementación: Rastrear el elemento hasta los bloques lógicos o físicos

que lo implementan (columnas "Arquitectura Lógica" o "Arquitectura
Física").

4. Resultados: Examinar los resultados de las pruebas o análisis para

determinar si el elemento ha sido verificado correctamente.

• Ejemplo: Para el requisito "El sistema mantendrá la altitud con una precisión de
±10 pies," se puede seguir el hilo de verificación para:

o Identificar los casos de prueba relacionados con la precisión del control

de altitud.

o Rastrear el requisito hasta los bloques lógicos y físicos que implementan

la función de control de altitud.

o Examinar los resultados de las pruebas para verificar que el sistema

cumple con el requisito de precisión.

2.0 Experimental Advanced. No tiene acceso a información en tiempo real ni a algunas

funciones de Gemini.

4. Implementación del Grid MBSE con SysML: Guía Paso a Paso

Este capítulo proporciona una guía detallada para implementar el Grid MBSE en el
desarrollo de un sistema, utilizando SysML como lenguaje de modelado. Se describen las
actividades y los artefactos a generar en cada fase del proceso, siguiendo un enfoque
iterativo e incremental. Cada fase corresponde a una o más columnas del Grid MBSE, y
para cada fase se detallan las subfases o pasos clave, los diagramas SysML relevantes y
las consideraciones importantes.

Metodología General:

La implementación del Grid MBSE con SysML se propone como un proceso iterativo e
incremental. Esto significa que no es necesario completar todas las fases de forma
secuencial y exhaustiva antes de pasar a la siguiente. En su lugar, se puede iterar sobre
las diferentes fases, refinando y completando los modelos de forma incremental. Este
enfoque permite:

• Flexibilidad: Adaptarse a cambios en los requisitos o en el entorno.

• Retroalimentación Temprana: Obtener retroalimentación temprana de los

interesados y realizar ajustes en el diseño.

• Reducción de Riesgos: Identificar y mitigar los riesgos en etapas tempranas del

desarrollo.
Aspectos del Operaciones
Necesidades Verificació
Sistema Necesidades Requisitos Arquitectura Arquitectura Diseño y
del ny
(Filas) / Fases del Negocio del Sistema Lógica Física Detallado Mantenimient
Interesado Validación
(Columnas) o

-
Especificacio
nes
- BDD detalladas de
- Documento - BDD
(Componente componentes
Estructura de Visión - Diagrama de (Descomposi
s Físicos) <br> -
<br> <br> - Contexto ción - Manual de
<br> - IBD Diagramas de
(Composición Análisis de <br> - Lista Funcional) Mantenimient
(Interfaces clases
, Interfaces, Mercado <br> de <br> - IBD o
Físicas) <br> - detallados
Contexto) - Modelo de Interesados (Interfaces
Diagramas de <br> -
Negocio Lógicas)
Despliegue Esquemas de
circuitos <br>
- Modelos
CAD

- ACT (Flujo de
- Casos de
Comportamie Actividades) - - Casos de - Manual de
- Casos de Uso - ACT
nto <br> <br> - SD Pseudocódig Prueba Usuario <br>
- Casos de Uso de Alto Detallados (refinado para
(Funcionalida (Intercambio o <br> - <br> - -
Uso de Alto Nivel <br> - <br> - HW/SW) <br>
d, de Mensajes) Especificació Informes Procedimient
Nivel Tabla de Diagrama de - SD (refinado
Interacciones <br> - STM n de de os de Gestión
Necesidades Requisitos para HW/SW)
, Estados) (Estados del protocolos Pruebas de Fallos
(funcional)
Sistema)
 - Diagrama de
Requisitos
(REQ) <br> -
Tabla de
- Matriz de
Requisitos
Trazabilida
Requisitos <br> -
d de
Especificació
Requisitos
n de
Requisitos
del Sistema
(SRS)

- Análisis
Paramétricos
de Riesgos
/ Análisis <br>
(FMEA)
(Restriccione - Análisis de - PAR - Análisis de
<br> -
s, Simulación, Costo- (Restricciones Costos del
Resultado
Optimización, Beneficio y Análisis) Ciclo de Vida
s de
Riesgos,
Simulacio
Costos)
nes

Diseño / Diseño /
Especificacio
Tipo de Especificacio Especificacio Especificacio White Box White Box Diseño / Black Box /
nes / Black
Análisis nes nes nes (según (según White Box White Box
Box
detalle) detalle)

Análisis Análisis Análisis de Verificació Análisis

Enfoque de Análisis de Análisis de Análisis de
Estructural y Estructural y Implementaci n (basado Operacional y
Análisis Negocio Necesidades Requisitos
de de ón Detallada en de
Comportamie Comportamie requisitos - Mantenimient
nto nto Detallado Black Box) o
y
Validación
(basado en
necesidad
es - Black
Box o
White Box,
según el
caso)
Fases de la Implementación:

4.1 Fase 1: Definición del Contexto y las Necesidades (Columnas: "Necesidades del
Negocio" y "Necesidades del Interesado")

Esta fase se centra en comprender el propósito del sistema, su entorno y las expectativas
de las partes interesadas. Se corresponde con las dos primeras columnas del Grid MBSE.

• 4.1.1 Identificación de las Necesidades del Negocio:

o Objetivo: Comprender la motivación estratégica detrás del desarrollo del

sistema.

o Actividades:

▪ Analizar el mercado y la competencia.

▪ Definir los objetivos de negocio que el sistema debe ayudar a

alcanzar.

▪ Evaluar la viabilidad del proyecto.

o Entregables:

▪ Documento de Visión.

▪ Análisis de Mercado.

▪ Modelo de Negocio (por ejemplo, Business Model Canvas).

▪ Análisis de Costo-Beneficio.

o Consideraciones:

▪ Enfocarse en el valor que el sistema aportará al negocio.

▪ Identificar los indicadores clave de rendimiento (KPIs) que se

utilizarán para medir el éxito del sistema.

• 4.1.2 Identificación de los Interesados y sus Necesidades (Stakeholder

Needs):

o Objetivo: Identificar a todas las partes interesadas (stakeholders) y

comprender sus necesidades y expectativas en relación con el sistema.

o Actividades:

▪ Realizar entrevistas, encuestas y talleres con los stakeholders.

▪ Analizar la documentación existente (por ejemplo, regulaciones,

estándares).

o Subfases:

▪ [Link] Identificación de Interesados:

▪ Técnicas: Brainstorming, análisis de la cadena de valor,

organigramas.
 ▪ Entregables: Lista de Interesados, con sus roles y
responsabilidades.

▪ Diagramas SysML: Diagrama de Contexto (BDD o un

diagrama de stakeholder específico).

▪ [Link] Elicitación de Necesidades:

▪ Técnicas: Entrevistas, encuestas, grupos focales,

observación, prototipado.

▪ Entregables: Tabla de Necesidades, Casos de Uso de Alto

Nivel.

▪ Diagramas SysML: Casos de Uso (UC).

▪ [Link] Análisis y Validación de Necesidades:

▪ Técnicas: Revisiones con los stakeholders, priorización de

necesidades.

▪ Entregables: Necesidades validadas y priorizadas.

▪ Diagramas SysML: Refinamiento de diagramas de casos

de uso y de contexto.

o Consideraciones:

▪ Involucrar a todos los stakeholders relevantes, no solo a los

usuarios finales.

▪ Documentar las necesidades de forma clara, concisa y no

ambigua.

▪ Validar las necesidades con los stakeholders para asegurar que se

han comprendido correctamente.

• 4.1.3 Definición del Contexto del Sistema:

o Objetivo: Definir claramente el límite del sistema y sus interfaces con el

entorno.

o Actividades:

▪ Identificar los actores externos que interactúan con el sistema.

▪ Definir las interfaces entre el sistema y los actores externos.

o Entregables:

▪ Diagrama de Contexto del Sistema.

▪ Descripción del Entorno.

o Diagramas SysML: Diagrama de Contexto (BDD), refine con casos de uso

si es necesario.

o Consideraciones:
 ▪ Establecer una clara distinción entre el sistema y su entorno.

▪ Identificar todas las interfaces relevantes, incluyendo el

intercambio de información, energía o materia.

4.2 Fase 2: Especificación de Requisitos del Sistema (Columna: "Requisitos del

Sistema")

Esta fase se centra en traducir las necesidades de los interesados en requisitos técnicos
precisos y medibles que el sistema debe cumplir.

• 4.2.1 Desarrollo de Requisitos del Sistema:

o Objetivo: Definir los requisitos funcionales, no funcionales, de

rendimiento, de interfaz y de diseño del sistema.

o Actividades:

▪ Derivar los requisitos del sistema a partir de las necesidades de

los interesados.

▪ Analizar y refinar los casos de uso de alto nivel.

▪ Descomponer los requisitos de alto nivel en requisitos de más bajo

nivel.

o Subfases:

▪ [Link] Derivación de Requisitos:

▪ Técnicas: Análisis de las necesidades de los interesados,

descomposición funcional.

▪ Entregables: Conjunto inicial de requisitos del sistema.

▪ Diagramas SysML: Diagrama de Requisitos (REQ), Casos

de Uso (UC).

▪ [Link] Refinamiento de Requisitos:

▪ Técnicas: Revisiones con expertos, análisis de casos de

uso detallados.

▪ Entregables: Requisitos del sistema refinados y

detallados.

▪ Diagramas SysML: Diagrama de Requisitos (REQ)

actualizado, Casos de Uso (UC) detallados.

▪ [Link] Especificación de Requisitos:

▪ Técnicas: Redacción de requisitos utilizando plantillas y

guías de estilo.

▪ Entregables: Tabla de Requisitos, Especificación de

Requisitos del Sistema (SRS).

▪ Diagramas SysML: Diagrama de Requisitos (REQ) final.

 o Diagramas SysML: Diagrama de Requisitos (REQ), Casos de Uso (UC)
detallados, se puede complementar con diagramas de actividades (ACT) o
de estados (STM) para el entendimiento de los requisitos.

o Consideraciones:

▪ Utilizar un lenguaje claro, conciso y no ambiguo para la redacción

de los requisitos.

▪ Asegurar que los requisitos sean verificables, es decir, que se

pueda determinar de forma objetiva si el sistema cumple o no con
el requisito.

▪ Definir criterios de aceptación para cada requisito.

▪ Clasificar los requisitos por tipo (funcional, no funcional, etc.) y

por prioridad.

• 4.2.2 Gestión de Requisitos (Atributos, Relaciones, Trazabilidad):

o Objetivo: Establecer un sistema para gestionar los requisitos a lo largo del

ciclo de vida del desarrollo.

o Actividades:

▪ Definir los atributos de los requisitos (por ejemplo, identificador,

descripción, tipo, prioridad, estado, fuente, justificación, criterios
de aceptación).

▪ Establecer relaciones entre los requisitos (por ejemplo, derivación,

dependencia, conflicto).

▪ Implementar un mecanismo de trazabilidad para vincular los

requisitos con otros artefactos del modelo (por ejemplo, casos de
uso, bloques, casos de prueba).

o Entregables:

▪ Matriz de Trazabilidad de Requisitos.

▪ Base de datos de requisitos.

o Diagramas SysML: Diagrama de Requisitos (REQ).

o Consideraciones:

▪ Utilizar una herramienta de gestión de requisitos para facilitar el

proceso.

▪ Mantener la trazabilidad actualizada a medida que el sistema

evoluciona.

▪ Gestionar los cambios en los requisitos de forma controlada.

4.3 Fase 3: Diseño de la Arquitectura Lógica (Columna: "Arquitectura Lógica")

Esta fase se centra en definir la estructura funcional del sistema, independientemente de
la tecnología de implementación.

• 4.3.1 Descomposición Funcional (BDD):

o Objetivo: Descomponer el sistema en bloques lógicos que representen

las funciones principales del sistema.

o Actividades:

▪ Identificar las funciones de alto nivel del sistema a partir de los

requisitos y los casos de uso.

▪ Descomponer las funciones de alto nivel en subfunciones más

detalladas.

▪ Definir las propiedades de los bloques lógicos (atributos,

operaciones).

o Entregables: Diagrama de Definición de Bloques (BDD) de la arquitectura

lógica.

o Diagramas SysML: BDD.

o Consideraciones:

▪ Agrupar las funciones relacionadas en el mismo bloque lógico.

▪ Mantener un nivel de abstracción adecuado, evitando detalles de

implementación.

▪ Definir claramente las responsabilidades de cada bloque lógico.

• 4.3.2 Definición de Interfaces Lógicas (IBD):

o Objetivo: Definir las interfaces entre los bloques lógicos, especificando el

tipo de información o energía que se intercambia.

o Actividades:

▪ Identificar las interfaces entre los bloques lógicos.

▪ Definir los puertos de cada bloque lógico.

▪ Especificar los flujos de ítems (información, energía o materia) que

se intercambian a través de cada interfaz.

o Entregables: Diagrama de Bloques Internos (IBD) de la arquitectura

lógica.

o Diagramas SysML: IBD.

o Consideraciones:

▪ Definir interfaces claras y concisas.

▪ Especificar el tipo de datos, la dirección del flujo y la frecuencia de

intercambio de información para cada interfaz.
• 4.3.3 Modelado del Comportamiento (ACT, SD, STM):

o Objetivo: Modelar el comportamiento dinámico de los bloques lógicos,

describiendo cómo realizan sus funciones y cómo interactúan entre sí.

o Actividades:

▪ Utilizar diagramas de actividades (ACT) para modelar el flujo de

control y de datos dentro de cada bloque lógico.

▪ Utilizar diagramas de secuencia (SD) para modelar las

interacciones entre los bloques lógicos.

▪ Utilizar diagramas de máquina de estados (STM) para modelar el

comportamiento de los bloques lógicos en términos de estados y
transiciones.

o Entregables: Diagramas de Actividades (ACT), Diagramas de Secuencia

(SD), Diagramas de Máquina de Estados (STM) para los bloques lógicos.

o Diagramas SysML: ACT, SD, STM.

o Consideraciones:

▪ Seleccionar el tipo de diagrama más adecuado para cada

situación.

▪ Mantener los diagramas simples y fáciles de entender.

▪ Validar los modelos de comportamiento mediante revisiones y

simulaciones.

• 4.3.4 Análisis Paramétricos (PAR):

o Objetivo: Modelar las relaciones cuantitativas entre los parámetros del

sistema a nivel lógico y realizar análisis de ingeniería.

o Actividades:

▪ Identificar los parámetros clave del sistema.

▪ Definir las restricciones y ecuaciones que relacionan los

parámetros.

▪ Utilizar diagramas paramétricos (PAR) para modelar estas

relaciones.

▪ Integrar los modelos paramétricos con herramientas de

simulación u optimización.

o Entregables: Diagramas Paramétricos (PAR) de la arquitectura lógica.

o Diagramas SysML: PAR.

o Consideraciones:

▪ Definir claramente las unidades de medida de cada parámetro.

 ▪ Validar los modelos paramétricos mediante pruebas o datos
históricos.

▪ Utilizar los modelos paramétricos para evaluar el rendimiento del

sistema, optimizar el diseño y realizar análisis de sensibilidad.

4.4 Fase 4: Diseño de la Arquitectura Física (Columna: "Arquitectura Física")

Esta fase se centra en definir la implementación física del sistema, seleccionando los
componentes concretos de hardware y software que se utilizarán.

• 4.4.1 Selección de Componentes (BDD):

o Objetivo: Identificar y seleccionar los componentes de hardware,

software y humanos que se utilizarán para implementar los bloques
lógicos definidos en la arquitectura lógica.

o Actividades:

▪ Evaluar las diferentes opciones de componentes disponibles en el

mercado.

▪ Seleccionar los componentes que mejor se ajusten a los requisitos

del sistema, teniendo en cuenta factores como el rendimiento, el
costo, la disponibilidad y la confiabilidad.

▪ Definir las propiedades de los componentes físicos (atributos,

operaciones).

o Entregables: Diagrama de Definición de Bloques (BDD) de la arquitectura

física.

o Diagramas SysML: BDD.

o Consideraciones:

▪ Realizar un análisis de costo-beneficio para cada componente.

▪ Considerar la posibilidad de reutilizar componentes existentes.

▪ Asegurar la compatibilidad entre los componentes seleccionados.

• 4.4.2 Definición de Interfaces Físicas (IBD):

o Objetivo: Definir las interfaces físicas entre los componentes,

especificando el tipo de conexión, el protocolo de comunicación y el
formato de los datos.

o Actividades:

▪ Identificar las interfaces entre los componentes físicos.

▪ Definir los puertos de cada componente.

▪ Especificar los protocolos de comunicación y los formatos de

datos para cada interfaz.

o Entregables: Diagrama de Bloques Internos (IBD) de la arquitectura física.

 o Diagramas SysML: IBD.

o Consideraciones:

▪ Seleccionar protocolos de comunicación estándar siempre que

sea posible.

▪ Definir claramente las características físicas de cada interfaz (por

ejemplo, tipo de conector, voltaje, frecuencia).

• 4.4.3 Modelado del Comportamiento a Nivel Físico (ACT, SD):

o Objetivo: Refinar los modelos de comportamiento de la arquitectura

lógica para adaptarlos a la arquitectura física, teniendo en cuenta las
características y limitaciones de los componentes seleccionados.

o Actividades:

▪ Adaptar los diagramas de actividades (ACT) para reflejar la

implementación física de las funciones.

▪ Refinar los diagramas de secuencia (SD) para mostrar las

interacciones entre los componentes físicos.

o Entregables: Diagramas de Actividades (ACT) y Diagramas de Secuencia

(SD) refinados para la arquitectura física.

o Diagramas SysML: ACT, SD.

o Consideraciones:

o Seguir las buenas prácticas de diseño para cada disciplina (ingeniería de

software, ingeniería electrónica, ingeniería mecánica, etc.).

o Asegurar que el diseño detallado sea consistente con la arquitectura

física.

o Realizar revisiones de diseño para detectar posibles errores o problemas.

• 4.5.2 Definición de Interfaces a Bajo Nivel:

o Objetivo: Especificar en detalle los protocolos de comunicación y los

formatos de datos utilizados en las interfaces entre los componentes.

o Actividades:

▪ Definir la estructura de los mensajes que se intercambian a través

de cada interfaz.

▪ Especificar la codificación de los datos.

▪ Definir los procedimientos para el establecimiento y la

terminación de la comunicación.

▪ Documentar cualquier restricción o limitación de la interfaz.

o Entregables:
 ▪ Especificaciones detalladas de interfaces.

▪ Documentación de protocolos de comunicación.

o Diagramas SysML: IBDs con especificación detallada de puertos y flujos.

o Consideraciones:

▪ Utilizar protocolos de comunicación estándar siempre que sea

posible.

▪ Asegurar que las interfaces estén bien documentadas y sean

fáciles de entender.

▪ Considerar la posibilidad de utilizar herramientas de simulación

para verificar el correcto funcionamiento de las interfaces.

4.6 Fase 6: Planificación de la Verificación y Validación (Columna: "Verificación y

Validación")

Esta fase se centra en definir cómo se verificará que el sistema cumple con los requisitos
y cómo se validará que satisface las necesidades de los interesados.

• 4.6.1 Estrategia de Verificación y Validación:

o Objetivo: Desarrollar un plan general para la verificación y validación del

sistema.

o Actividades:

▪ Identificar los métodos de verificación y validación que se

utilizarán (por ejemplo, pruebas, inspecciones, análisis,
demostraciones).

▪ Definir los criterios de aceptación para cada requisito.

▪ Establecer un cronograma para las actividades de verificación y

validación.

o Entregables:

▪ Plan de Verificación y Validación.

o Diagramas SysML: No se suelen utilizar diagramas SysML específicos en

esta subfase, pero se hace referencia a los requisitos (REQ) y a los
diagramas de comportamiento (UC, ACT, SD, STM) para la definición de
los casos de prueba.

o Consideraciones:

▪ Alinear la estrategia de verificación y validación con los requisitos

del sistema y las necesidades de los interesados.

▪ Considerar la posibilidad de utilizar un enfoque basado en el riesgo

para priorizar las actividades de verificación y validación.
 ▪ Asegurar que todos los requisitos sean verificables y que todas las
necesidades de los interesados sean validables.

• 4.6.2 Desarrollo de Casos de Prueba (STM, ACT, SD):

o Objetivo: Definir los casos de prueba que se utilizarán para verificar el

sistema.

o Actividades:

▪ Derivar los casos de prueba a partir de los requisitos, los casos de

uso y los modelos de comportamiento.

▪ Definir los pasos de cada caso de prueba, los datos de entrada, los
resultados esperados y los criterios de aceptación.

o Entregables:

▪ Especificación de Casos de Prueba.

o Diagramas SysML: STM, ACT, SD (para modelar el comportamiento

esperado y los escenarios de prueba).

o Consideraciones:

▪ Asegurar que los casos de prueba cubran todos los requisitos y

todos los escenarios de uso relevantes.

▪ Utilizar una variedad de técnicas de prueba (por ejemplo, pruebas

de caja negra, pruebas de caja blanca).

▪ Automatizar los casos de prueba siempre que sea posible.

• 4.6.3 Matriz de Trazabilidad de Requisitos:

o Objetivo: Vincular los requisitos con los casos de prueba para asegurar
que todos los requisitos sean verificados.

o Actividades:

▪ Crear una matriz que muestre la relación entre cada requisito y los
casos de prueba que lo verifican.

▪ Actualizar la matriz a medida que se desarrollan nuevos requisitos

o casos de prueba.

o Entregables:

▪ Matriz de Trazabilidad de Requisitos.

o Diagramas SysML: REQ (para visualizar las relaciones de verificación).

o Consideraciones:

▪ Utilizar una herramienta de gestión de requisitos para facilitar la

creación y el mantenimiento de la matriz de trazabilidad.
 ▪ Revisar la matriz de trazabilidad periódicamente para asegurar que
todos los requisitos estén cubiertos.

• 4.6.4 Análisis de Riesgos (FMEA):

o Objetivo: Identificar y evaluar los riesgos potenciales asociados al

sistema.

o Actividades:

▪ Realizar un Análisis Modal de Fallos y Efectos (FMEA) para

identificar los posibles modos de fallo del sistema, sus causas y
sus consecuencias.

▪ Evaluar la severidad, la ocurrencia y la detectabilidad de cada

modo de fallo.

▪ Definir acciones de mitigación para reducir la probabilidad o el

impacto de los fallos.

o Entregables:

▪ Informe FMEA.

▪ Plan de Mitigación de Riesgos.

o Diagramas SysML: No se suelen utilizar diagramas SysML específicos

para el FMEA, pero se puede referenciar a los diagramas de estructura
(BDD, IBD) y comportamiento (ACT, SD, STM) para identificar los modos de
fallo.

o Consideraciones:

▪ Involucrar a un equipo multidisciplinario en el análisis de riesgos.

▪ Actualizar el análisis de riesgos a medida que el diseño del sistema

evoluciona.

▪ Considerar la posibilidad de utilizar herramientas de software para

facilitar el análisis FMEA.

4.7 Fase 7: Consideraciones para Operaciones y Mantenimiento (Columna:

"Operaciones y Mantenimiento")

Esta fase se centra en la planificación de las actividades de operación, soporte y

mantenimiento del sistema a lo largo de su ciclo de vida.

• 4.7.1 Plan de Mantenimiento:

o Objetivo: Definir las actividades de mantenimiento preventivo y correctivo

que se realizarán durante la vida útil del sistema.

o Actividades:

▪ Identificar los componentes del sistema que requieren

mantenimiento.
 ▪ Definir la frecuencia y el alcance de las actividades de
mantenimiento preventivo.

▪ Establecer los procedimientos para el diagnóstico y la reparación

de fallos.

o Entregables:

▪ Plan de Mantenimiento.

o Diagramas SysML: Se pueden utilizar diagramas de actividades (ACT)

para modelar los procedimientos de mantenimiento.

o Consideraciones:

▪ Considerar la accesibilidad de los componentes para el

mantenimiento.

▪ Definir los requisitos de formación para el personal de

mantenimiento.

▪ Establecer un sistema para el registro de las actividades de

mantenimiento.

• 4.7.2 Procedimientos de Actualización:

o Objetivo: Establecer los procedimientos para actualizar el software o el

hardware del sistema.

o Actividades:

▪ Definir el proceso para la liberación de nuevas versiones de

software o hardware.

▪ Establecer los procedimientos para la instalación de las

actualizaciones.

▪ Definir los criterios de aceptación para las actualizaciones.

o Entregables:

▪ Plan de Actualización.

o Diagramas SysML: Se pueden utilizar diagramas de actividades (ACT)

para modelar los procedimientos de actualización.

o Consideraciones:

▪ Minimizar el tiempo de inactividad del sistema durante las

actualizaciones.

▪ Asegurar la compatibilidad de las actualizaciones con las

versiones anteriores del sistema.

▪ Realizar pruebas exhaustivas antes de implementar las

actualizaciones en el entorno de producción.

• 4.7.3 Gestión de Fallos:

 o Objetivo: Definir los procedimientos para detectar, diagnosticar y resolver
los fallos del sistema.

o Actividades:

▪ Establecer un sistema para el reporte de fallos.

▪ Definir los procedimientos para el análisis de la causa raíz de los

fallos.

▪ Establecer los procedimientos para la reparación o el reemplazo

de los componentes defectuosos.

o Entregables:

▪ Plan de Gestión de Fallos.

o Diagramas SysML: Se pueden utilizar diagramas de actividades (ACT) o de

secuencia (SD) para modelar los procedimientos de gestión de fallos.

o Consideraciones:

▪ Definir claramente los roles y responsabilidades del personal

involucrado en la gestión de fallos.

▪ Establecer un sistema para el seguimiento del estado de los fallos.

▪ Documentar las lecciones aprendidas de los fallos para evitar que

se repitan en el futuro.

• 4.7.4 Análisis de Costos del Ciclo de Vida:

o Objetivo: Estimar los costos totales de propiedad del sistema a lo largo de

su ciclo de vida, incluyendo los costos de desarrollo, producción,
operación, mantenimiento y retirada.

o Actividades:

▪ Identificar todos los costos asociados al sistema.

▪ Desarrollar un modelo de costos para estimar los costos futuros.

▪ Realizar análisis de sensibilidad para evaluar el impacto de

diferentes factores en los costos.

o Entregables:

▪ Informe de Análisis de Costos del Ciclo de Vida.

o Diagramas SysML: No se suelen utilizar diagramas SysML específicos

para el análisis de costos del ciclo de vida, pero se puede hacer referencia
a la información de los componentes en los diagramas de estructura
(BDD, IBD).

o Consideraciones:

▪ Utilizar datos históricos de proyectos similares para mejorar la

precisión de las estimaciones.
 ▪ Actualizar el análisis de costos del ciclo de vida a medida que el
diseño del sistema evoluciona.

▪ Considerar el valor del dinero en el tiempo al realizar las

estimaciones.

5. Ejemplo Práctico: Sistema de Monitoreo de Temperatura para un Invernadero

Este capítulo ilustra la aplicación práctica del Grid MBSE y SysML a través del desarrollo
de un ejemplo concreto: un Sistema de Monitoreo de Temperatura para un
Invernadero. Se describe cómo se completa cada celda relevante del Grid, cómo se
generan los diagramas SysML correspondientes y cómo se establece la trazabilidad entre
los diferentes elementos del modelo. Este ejemplo permitirá visualizar la metodología
explicada en los capítulos anteriores y comprender mejor su aplicación en un escenario
real.

Descripción del Sistema:

El sistema de monitoreo de temperatura para un invernadero tiene como objetivo medir

la temperatura dentro del invernadero, mostrarla en una pantalla LCD, enviarla a un
servidor remoto para su almacenamiento y visualización en una aplicación web, y
generar una alerta sonora y visual si la temperatura excede los límites superior o inferior
predefinidos por el usuario. El sistema también permitirá al usuario configurar los
umbrales de temperatura a través de una interfaz web.

Aplicación del Grid MBSE al Ejemplo:

A continuación, se describe cómo se completa cada celda relevante del Grid MBSE para
el sistema de monitoreo de temperatura, junto con los diagramas SysML
correspondientes. Se seguirá un enfoque iterativo, refinando los modelos a medida que
se avanza en las diferentes fases.

(Nota: Debido a las limitaciones de formato de texto, los diagramas SysML se

describirán textualmente. En una implementación real, se utilizarían herramientas
de modelado SysML para crear los diagramas de forma gráfica.)
 Paramétricos /
Fases (Filas) / Comportamiento Análisis
Estructura
Aspectos del (Funcionalidad, (Restricciones,
Requisitos (Composición, Tipo de Análisis / Enfoque
Sistema Interacciones, Simulación,
Interfaces, Contexto)
(Columnas) Estados) Optimización,
Riesgos, Costos)

- Documento de Visión
Necesidades del - Casos de Uso de - Análisis de Costo- Especificaciones
- Análisis de Mercado
Negocio Alto Nivel Beneficio Análisis de Negocio
- Modelo de Negocio

Necesidades del - Diagrama de Contexto - Casos Uso Alto Nivel Especificaciones

Interesado - Lista de Interesados - Tabla Necesidades Análisis de Necesidades

- Diagrama de
Requisitos (REQ)
- Casos Uso Detallado
Requisitos del - Tabla de Requisi. - Especificaciones
- Diagrama de Requis.
Sistema Especificación de Análisis de Requisitos
(funcional)
Requisitos del
Sistema (SRS)

- ACT (Flujo de
- BDD (Descomposición Actividades) Diseño / White Box (según
Arquitectura Funcional) - SD (Intercambio de - PAR (Restricciones y detalle)
Lógica - IBD (Interfaces Mensajes) Análisis) Análisis Estructural y de
Lógicas) - STM (Estados del Comportamiento
Sistema)
 - BDD (Componentes
- ACT (refinado para Diseño / White Box (según
Físicos)
HW/SW) detalle)
Arquitectura Física - IBD (Interfaces Físicas)
- SD (refinado para Análisis Estructural y de
- Diagramas de
HW/SW) Comportamiento Detallado
Despliegue

- Especificaciones
detalladas de
componentes - - Pseudocódigo Diseño / White Box
Diseño Detallado Diagramas de clases - Especificación de Análisis de Implementación
detallados protocolos Detallada
- Esquemas de circuitos
- Modelos CAD

Black Box / White Box <br>

- Análisis de Riesgos Verificación (basado en
- Matriz de - Casos de Prueba
Verificación y (FMEA) <br> - requisitos - Black Box) y
Trazabilidad de <br> - Informes de
Validación Resultados de Validación (basado en
Requisitos Pruebas
Simulaciones necesidades - Black Box o
White Box, según el caso)

- Manual de Usuario Especificaciones / Black Box

Operaciones y - Manual de - Análisis de Costos
<br> - Procedimientos <br> Análisis Operacional y de
Mantenimiento Mantenimiento del Ciclo de Vida
de Gestión de Fallos Mantenimiento

Leyenda:

• BDD: Diagrama de Definición de Bloques

• IBD: Diagrama de Bloques Internos

• PKG: Diagrama de Paquetes

• UC: Diagrama de Casos de Uso

• ACT: Diagrama de Actividades

• SD: Diagrama de Secuencia

• STM: Diagrama de Máquina de Estados

• REQ: Diagrama de Requisitos

• PAR: Diagrama Paramétrico

Desarrollo de las Celdas del Grid (Ejemplo):

Columna "Necesidades del Negocio":

• Fila "Estructura":

o Documento de Visión: "Mejorar la eficiencia y la productividad del

invernadero mediante un control preciso de la temperatura, reduciendo
costos y aumentando la calidad de los cultivos."

o Análisis de Mercado: "Existe una demanda creciente de sistemas de

automatización para invernaderos, especialmente en el sector de la
agricultura orgánica."

o Modelo de Negocio: "El sistema se venderá como un producto a los

agricultores, con un servicio opcional de suscripción para el
almacenamiento y análisis de datos en la nube."

• Fila "Comportamiento":

o Casos de Uso de Alto Nivel: "Monitorear Condiciones Ambientales,"

"Controlar Dispositivos," "Analizar Datos Históricos." (Estos casos de uso
son de alto nivel y no corresponden a un detalle de modelado del sistema
sino a una descripción de las necesidades del negocio).

• Fila "Requisitos": (No aplica directamente en esta columna)

• Fila "Paramétricos / Análisis":

o Análisis de Costo-Beneficio: "Se estima que el sistema permitirá un

ahorro de energía del 10% y un aumento de la productividad del 15%, con
un retorno de la inversión en 2 años."

Columna "Necesidades del Interesado":

• Fila "Estructura":

o Diagrama de Contexto: Un diagrama BDD que muestra el "Sistema de

Monitoreo de Temperatura" en el centro, rodeado por actores externos
como el "Agricultor," el "Invernadero" y el "Servidor Remoto."

o Lista de Interesados: "Agricultor (usuario principal), Propietario del

Invernadero, Técnico de Mantenimiento."

• Fila "Comportamiento":

o Casos de Uso de Alto Nivel: "Monitorear Temperatura," "Recibir Alertas,"

"Configurar Umbrales," "Visualizar Datos Históricos."

o Tabla de Necesidades:

▪ "El Agricultor necesita conocer la temperatura actual del

invernadero en todo momento."

▪ "El Agricultor necesita recibir alertas si la temperatura está fuera

de rango."
 ▪ "El Agricultor necesita poder configurar los umbrales de
temperatura de forma remota."

▪ "El Agricultor necesita que el sistema sea fácil de instalar y usar."

• Fila "Requisitos": (No aplica directamente en esta columna)

• Fila "Paramétricos / Análisis": (No aplica directamente en esta columna)

Columna "Requisitos del Sistema":

• Fila "Estructura":

o REQ-1: "El sistema medirá la temperatura del invernadero."

o REQ-2: "El sistema mostrará la temperatura actual en una pantalla LCD."

• Fila "Comportamiento":

o REQ-3: "El sistema generará una alerta sonora y visual si la temperatura

supera los umbrales configurados."

o REQ-4: "El sistema permitirá configurar los umbrales de temperatura a

través de una interfaz web."

o Casos de Uso Detallados: Descripción detallada de los casos de uso

"Monitorear Temperatura," "Generar Alerta" y "Configurar Umbrales,"
incluyendo el flujo de eventos, las precondiciones y las poscondiciones.

• Fila "Requisitos":

o Diagrama de Requisitos (REQ): Un diagrama que muestra todos los

requisitos del sistema y sus relaciones de dependencia, derivación y
satisfacción. Por ejemplo, REQ-3 se deriva de la necesidad del Agricultor
de "recibir alertas".

o Tabla de Requisitos: Una tabla que lista todos los requisitos del sistema,
con sus atributos (ID, descripción, tipo, prioridad, estado, fuente,
justificación, criterios de aceptación).

• Fila "Paramétricos / Análisis":

o REQ-5: "El sistema medirá la temperatura con una precisión de ±0.5°C."

o REQ-6: "El sistema enviará datos de temperatura al servidor cada 5

minutos."

Columna "Arquitectura Lógica":

• Fila "Estructura":

o BDD: Un diagrama que muestra la descomposición del sistema en

bloques lógicos: Sensor de Temperatura, Unidad de Control, Módulo de
Visualización, Módulo de Comunicación, Módulo de Alerta.
 o IBD: Un diagrama que muestra las interfaces entre los bloques lógicos.
Por ejemplo, una interfaz entre el Sensor de Temperatura y la Unidad de
Control para transmitir los datos de temperatura.

• Fila "Comportamiento":

o UC: "Monitorear Temperatura," "Generar Alerta," "Configurar Umbrales".

o ACT: Un diagrama de actividades que describe el flujo de actividades para

la función "Monitorear Temperatura": Leer Temperatura del Sensor ->
Comparar con Umbrales -> Mostrar Temperatura en Pantalla -> Enviar
Datos al Servidor.

o SD: Un diagrama de secuencia que muestra el intercambio de mensajes

entre la Unidad de Control, el Módulo de Alerta y el Módulo de
Visualización para el caso de uso "Generar Alerta".

o STM: Un diagrama de máquina de estados que describe los estados de la

Unidad de Control: "Monitoreando," "Alerta," "Configurando."

• Fila "Requisitos": (No aplica directamente en esta columna)

• Fila "Paramétricos / Análisis":

o PAR: Un diagrama paramétrico que muestra la restricción: Frecuencia de

muestreo del sensor <= Frecuencia máxima soportada por el sensor.

o Análisis: Simulación del comportamiento térmico del invernadero para

determinar la frecuencia de muestreo óptima.

Columna "Arquitectura Física":

• Fila "Estructura":

o BDD: Un diagrama que muestra los componentes físicos del sistema:

Sensor DHT22, Microcontrolador ESP32, Pantalla LCD 16x2, Módulo WiFi
ESP8266, Alarma Sonora, LED Indicador.

o IBD: Un diagrama que muestra las conexiones físicas entre los

componentes. Por ejemplo, una conexión I2C entre el Sensor DHT22 y el
Microcontrolador ESP32.

• Fila "Comportamiento":

o ACT: Refinado para incluir detalles de implementación, como la lectura

específica del sensor DHT22.

o SD: Refinado para incluir mensajes específicos del protocolo de

comunicación, como tramas de datos enviadas por WiFi.

• Fila "Requisitos": (No aplica directamente en esta columna)

• Fila "Paramétricos / Análisis": (No aplica directamente en esta columna)

Columna "Diseño Detallado":

• Fila "Estructura":
 o Especificaciones del sensor DHT22, incluyendo sus pines, protocolo de
comunicación I2C y comandos.

o Diagrama de circuito de conexión del sensor al microcontrolador.

o Especificación de la pantalla LCD, incluyendo sus comandos y protocolo

de comunicación.

• Fila "Comportamiento":

o Pseudocódigo del algoritmo de lectura del sensor DHT22.

o Pseudocódigo del algoritmo de comparación de la temperatura con los

umbrales.

o Pseudocódigo del algoritmo de envío de datos por WiFi.

• Fila "Requisitos": (No aplica directamente en esta columna)

• Fila "Paramétricos / Análisis": (No aplica directamente en esta columna)

Columna "Verificación y Validación":

• Fila "Estructura": (No aplica directamente en esta columna)

• Fila "Comportamiento":

o Casos de prueba para verificar la lectura correcta del sensor.

o Casos de prueba para verificar la visualización de la temperatura en la

pantalla LCD.

o Casos de prueba para verificar la generación de alertas.

o Casos de prueba para verificar la configuración de los umbrales de

temperatura.

• Fila "Requisitos":

o Matriz de Trazabilidad: Una tabla que vincula cada requisito del sistema
con los casos de prueba que lo verifican.

• Fila "Paramétricos / Análisis":

o Prueba de precisión del sensor utilizando un termómetro de referencia.

o Análisis de la frecuencia de envío de datos para verificar que cumple con

el requisito REQ-6.

o Análisis de Riesgos (FMEA) para identificar posibles fallos y sus efectos.

Columna "Operaciones y Mantenimiento":

• Fila "Estructura":

o Manual de instalación del sistema, incluyendo diagramas de conexión y

configuración.

• Fila "Comportamiento":
 o Manual de usuario para la operación del sistema, incluyendo la
configuración de los umbrales de temperatura y la visualización de los
datos en la interfaz web.

o Procedimientos de gestión de fallos, describiendo los pasos a seguir en

caso de que se produzca una alerta o un fallo del sistema.

• Fila "Requisitos": (No aplica directamente en esta columna)

• Fila "Paramétricos / Análisis":

o Análisis de costos de operación, incluyendo el consumo de energía y el

mantenimiento del sistema.

5.3 Demostración de la Trazabilidad y las Interconexiones:

A lo largo del desarrollo del ejemplo, se ha demostrado la trazabilidad entre los diferentes
elementos del modelo:

• Trazabilidad Vertical: Las necesidades de los interesados se han refinado en

requisitos del sistema, que a su vez se han descompuesto en funciones en la
arquitectura lógica y se han implementado en la arquitectura física.

• Trazabilidad Horizontal: Dentro de la arquitectura lógica, se han relacionado los

diagramas de actividades, de secuencia y de máquina de estados para describir el
comportamiento del sistema desde diferentes perspectivas.

• Trazabilidad Cruzada: Los requisitos del sistema se han vinculado a los casos de
uso, a los bloques lógicos y físicos, y a los casos de prueba.