Prácticas recomendadas para crear modelos de Simulink de gran tamaño

A medida que los sistemas crecen en escala y complejidad, los equipos de ingeniería enfrentan un conjunto de desafíos completamente nuevos que no existen en escalas más pequeñas.

Casi siempre, un aumento significativo de escala requiere un cambio de enfoque, no sólo en alcance sino en tipo. Este principio también se aplica a modelos de Simulink^® cuando se trabaja con el diseño basado en modelos. Cuando no se siguen prácticas recomendadas, comienzan a surgir una serie de problemas al pasar de modelos de prueba de concepto simples a modelos a gran escala con cientos de miles de bloques, como problemas con la arquitectura del modelo, gestión de datos, interfaces, gestión de archivos y rendimiento de la simulación. Los componentes básicos de estos modelos de gran tamaño pueden ser pequeños, a menudo desarrollados por diferentes individuos, equipos e incluso departamentos. Cuando existe estandarización y se siguen las prácticas recomendadas, estos modelos se pueden escalar sin problemas.

Este artículo describe un conjunto de prácticas recomendadas para gestionar los desafíos de trabajar con modelos de gran tamaño y complejos en Simulink. Debido a que este tema en sí es bastante amplio, el objetivo aquí no es proporcionar una guía detallada y prescriptiva, sino más bien presentar los conceptos básicos de cada práctica junto con enlaces a recursos adicionales que se pueden explorar para una comprensión más profunda.

Usar modelos de referencia para componentización de modelos

Cuando trabajamos con clientes, no es raro ver modelos de gran tamaño que carecen de componentización. Los equipos comienzan con un modelo simple para probar ideas; con el tiempo, se agregan nuevos elementos o características, y todo el trabajo se realiza en un único archivo de modelo monolítico que pronto se vuelve difícil de manejar.

En Simulink, existen varias formas de realizar componentización de modelos de gran tamaño, y el mejor enfoque dependerá del caso de uso específico. Por ejemplo, un equipo que simplemente desea organizar visualmente un grupo de bloques o componentes puede optar por un subsistema virtual dentro del modelo.Para aquellos que desean crear utilidades ampliamente utilizadas que cambian con poca frecuencia, un subsistema vinculado (o librería) es una mejor opción. Si el objetivo es desarrollar o simular un componente como un modelo independiente, entonces un modelo de referencia es el mejor enfoque.

El modelo de referencia también es clave para la componentización de modelos a gran escala. Un motivo es que el modelo de referencia de Simulink permite desarrollar componentes en paralelo como modelos independientes. Cada componente es completamente funcional y simulable, y se guarda en su propio archivo SLX para que cada equipo pueda trabajar independientemente sin interferir con el trabajo de otro equipo, lo que es prácticamente imposible de hacer cuando todo el diseño está capturado en un solo archivo. Igualmente importante es que estos modelos de referencia independientes se pueden colocar dentro de modelos más grandes para una fácil integración (Figura 1). Esta arquitectura puede reducir el tiempo de compilación utilizando instancias almacenadas en caché de modelos de referencia y compilaciones incrementales. También permite el uso de los modos Accelerator y Rapid Accelerator, que se tratan con más detalle a continuación en la sección sobre rendimiento.

Escalar la gestión de datos con diccionarios de datos

Consideremos el mismo escenario que generó problemas de componentización. Un equipo de trabajo comienza con un modelo simple como prueba inicial de concepto y continúa desarrollándolo con el tiempo. Para un modelo simple, muchos ingenieros almacenan variables, parámetros y otros datos en el área de trabajo base.Este enfoque funciona bien para flujos de trabajo informales, ajuste rápido de parámetros, prototipado rápido, proyectos de un solo desarrollador o casos de uso que requieren visibilidad global de parámetros. Sin embargo, a medida que los modelos aumentan en alcance y complejidad, confiar en el área de trabajo base para la gestión de datos tiene algunas desventajas. Por ejemplo, debido a que el área de trabajo base se borra cada vez que se cierra una sesión, debe guardarse manualmente en código de MATLAB^® (.m) o en un archivo de MATLAB (.mat).

Los diccionarios de datos son más adecuados que el área de trabajo base para gestionar datos en proyectos que involucran modelos de gran tamaño, desarrollo distribuido o datos de alcance limitado. Existen algunas razones para esto (Figura 2). La primera es la persistencia de los datos. Los datos se guardan en un formato específico en archivos de diccionario de datos (.sldd), lo que permite definir, gestionar y actualizar los datos del modelo y del área de trabajo base por separado. En segundo lugar, los equipos pueden dividir los datos en varios diccionarios para mejorar aún más la organización de los datos. En tercer lugar, los diccionarios de datos funcionan bien en los flujos de trabajo de seguimiento de cambios, en los que los equipos pueden ver qué cambios, cuándo y quién los realizó, e incluso volver a versiones anteriores cuando sea necesario.

Es importante tener en cuenta aquí que la elección entre utilizar el área de trabajo base o los diccionarios de datos no es todo o nada. Los dos enfoques pueden coexistir, por lo que un equipo puede migrar gradualmente del área de trabajo base a uno o más diccionarios de datos a lo largo del tiempo.

Simplificar interfaces con buses

Al conectar subsistemas en un modelo jerárquico componentizado, inicialmente puede parecer que el enfoque más sencillo es utilizar una línea de señal separada para cada elemento que pasa de un componente a otro. Por supuesto, esto funciona para interfaces simples, pero el enfoque puede dar lugar rápidamente a modelos más complejos, desordenados y difíciles de gestionar de lo necesario.

En Simulink, los buses pueden simplificar las interfaces y reducir el desorden al representar un conjunto de señales (o elementos) con una sola línea, de forma muy similar a varios cables agrupados. Veamos un ejemplo sencillo. Considere un componente de detección de fallos para identificar condiciones anómalas en un sistema de batería. El componente tiene 11 entradas diferentes, que incluyen voltaje de celda máximo y mínimo, temperatura de celda máxima y mínima, estados del contactor, voltaje y corriente del paquete, y límites de corriente. Si bien es posible crear el componente con 11 puertos de entrada individuales, es más organizado separar las entradas en grupos lógicos y utilizar un bus para cada grupo. Por ejemplo, debido a que las señales de voltaje y temperatura de la celda se originan en el mismo componente y están relacionadas, tiene sentido agruparlas en un solo bus de cuatro elementos (Figura 3). Claramente, este es un ejemplo relativamente trivial, pero ilustra cómo se pueden usar los buses para simplificar no sólo las interfaces de componentes sino, más ampliamente, modelos complejos.

Mejorar la gestión de archivos con proyectos

Un efecto secundario de seguir las prácticas recomendadas descritas hasta ahora es un aumento en la cantidad de archivos que deben administrarse. Cuando todo el diseño está en un solo modelo, el conjunto de archivos es relativamente pequeño, pero puede crecer rápidamente cuando se emplean activamente la componentización y los diccionarios de datos. Sin una estrategia de gestión de archivos, esta proliferación de archivos puede volverse problemática.

En Simulink, se pueden usar proyectos para ayudar a automatizar la gestión de archivos, y dedicar más tiempo al modelado, simulación y otras actividades de gran valor. Por ejemplo, al configurar un proyecto, el equipo especificará las carpetas en la ruta del proyecto. Estas carpetas se agregan a la ruta de búsqueda cuando se abre el proyecto (y se eliminan cuando se cierra el proyecto), lo que garantiza que todos los usuarios del proyecto tengan acceso a los archivos que contienen. El equipo también puede especificar archivos de inicio que automatizan la configuración del entorno para su proyecto y archivos de cierre que limpian el entorno deshaciendo los pasos de configuración, por ejemplo. Además, los proyectos se pueden configurar para abrir archivos utilizados con frecuencia al iniciarse y crear accesos directos para tareas utilizadas comúnmente.

Los proyectos también pueden ayudar a evitar errores comunes. Por ejemplo, con una jerarquía de modelos compleja, puede ocurrir que dos archivos de modelos tengan el mismo nombre en directorios diferentes. Al utilizar un proyecto, aparecerá una advertencia cuando se detecten archivos sombreados. Además, los ingenieros reciben un aviso para que guarden los cambios cuando se cierra un proyecto, lo que ayuda a evitar la pérdida de trabajo.

Finalmente, los proyectos ayudan a agilizar el control de fuente, con operaciones comunes como actualizar, confirmar, enviar, extraer, recuperar y otras operaciones accesibles directamente desde la interfaz de usuario (Figura 4).

Optimizar el rendimiento de la simulación

Las prácticas recomendadas que hemos cubierto hasta ahora se han centrado principalmente en la estructura de modelos de gran tamaño, sus datos y archivos asociados. Clientes que han implementado estas prácticas recomendadas, a menudo se preguntan cómo mejorar el rendimiento de la simulación. Con una mejor manera de crear modelos de gran tamaño, ¿cómo se pueden simular más rápido?

Existen varias herramientas disponibles para mejorar el rendimiento de la simulación. Como primer paso, recomendamos utilizar Performance Advisor, que ejecuta una serie de comprobaciones para identificar configuraciones que puedan ralentizar las simulaciones. Para modelos que incluyen código de MATLAB de inicialización (en un callback, por ejemplo), es una buena idea ejecutar la app MATLAB Profiler para identificar dónde MATLAB está invirtiendo la mayor parte del tiempo. Simulink Profiler evalúa el tiempo de ejecución del modelo e identifica problemas que pueden contribuir a un rendimiento deficiente de la simulación. Por último, si se utiliza un solver de paso variable, recomendamos ejecutar Solver Profiler, que analiza el comportamiento del solver, identifica problemas potenciales (como reinicios del solucionador o pasos de tiempo excepcionalmente pequeños) y brinda recomendaciones para resolverlos. Para orientación sobre cada una de estas herramientas, incluido cómo y cuándo utilizarlas, consulte la tabla en Troubleshoot and Speed Up Simulation Performance.

Si se ha realizado componentización en un modelo de gran tamaño, las simulaciones se pueden acelerar con el modo Accelerator o el modo Rapid Accelerator, que reemplazan el código interpretado normalmente utilizado en simulaciones de Simulink con código generado. Durante la inicialización del modelo, Simulink verifica en un caché si hay algún componente para el que ya se haya generado código. Este proceso de compilación incremental reduce en gran medida el tiempo de inicialización para modelos de gran tamaño con muchos componentes, porque solo será necesario reconstruir (y agregar al caché) aquellos componentes que hayan cambiado desde la última simulación.

Otra forma de reducir el tiempo de inicialización, específicamente cuando se simula un modelo de forma iterativa, es emplear el modo Fast Restart. Cuando un equipo realiza múltiples ejecuciones de simulación sin realizar ningún cambio estructural en el modelo, el reinicio rápido puede acelerar el proceso al realizar las simulaciones sin compilar el modelo y finalizar la simulación cada vez. En cambio, en la primera simulación se compila e inicializa el modelo y luego se captura una instantánea del punto operativo del modelo para cada simulación posterior (Figura 5).

En conclusión, a medida que los equipos de ingeniería abordan las complejidades de escalar los modelos de Simulink, adherirse a las prácticas recomendadas se vuelve esencial. En este artículo se han descrito estrategias esenciales para realizar componentización de modelos, gestión de datos y optimización del rendimiento, destacando la importancia de un enfoque estructurado para el desarrollo de modelos. Con Performance Advisor, MATLAB Profiler y Solver Profiler, los equipos pueden mejorar el rendimiento de la simulación y la productividad. Estas prácticas garantizan que los modelos a gran escala sigan siendo manejables, eficientes y adaptables. A medida que el panorama del diseño basado en modelos continúa evolucionando, estas pautas ayudarán a construir modelos sólidos que satisfagan las demandas de desafíos de ingeniería cada vez más complejos. Para una mayor exploración, recomendamos recursos adicionales y oportunidades de formación destacadas a lo largo de este documento.

El contenido de este artículo se basa en una charla “Best Practices for Building Large Models from Components to Complex Systems” (Prácticas recomendadas para crear modelos de gran tamaño, desde componentes hasta sistemas complejos) presentada en MathWorks Automotive Conference. Consulte “Más información” para ver esta charla, junto con más cursos y webinars. Como señalamos al principio, se trata de un tema muy amplio que no se puede cubrir exhaustivamente en un solo artículo o charla.