We wanted to do more simulations with Simulink models to help cut back on physical prototypes. We started tracking time spent to get the results of these simulations. Most of our engineers' time was spent finding the right models, setting them up, and configuring these simulations. They didn't have much time left to do modeling and testing work.
At first we just created some "Bill Of Models" to define systems and simulations. Slowly we've expanded the scope. Each BOM contains a system definition, components, subcomponents, interfaces, and some metadata. There's pointers to different repositories, parameter databases, and scripts to configure runtime environments. We have a small tool that reads BOMs and instantiates them as full simulations.
When someone wants to test a new system variant, they can usually just modify an existing BOM. If they have a new feature, BOMs give them an easy way to see and create every variant simulation to work with. We had to do a lot of standardization of our models, but that helped our efforts to move toward fully automated tests and CI/CD. We now have a web-based catalog of models and BOMs that are automatically generated, run, and tested. All of this has also helped get new people to use simulations for their work.
Thanks for the response, it is a very interesting approach, it sounds more practical than the typical MBSE way of building top down SysML diagrams and adding simulation models afterwards. Are your models liked to other product data in a PLM system or similar for traceability? I'm researching adjacent issues around the flexibility of product platforms and the integration of new technologies in later product variants and model-based approaches to decision making in that regard are fascinating.
I don't use any PLM software. Someone in the company might, but I haven't heard of any being used. All of our requirements are maintained in a company-wide tool though. Requirements get decomposed from customer requirements all the way down to subcomponent requirements. Departments/teams get requirements assigned to them. Engineers were spending too much time manually checking and signing off those requirements. Currently the model and BOM metadata includes related requirement IDs. We are working toward having generic tests for requirements. Our goal is to implement tests for a requirement and have an automated signoff of BOMs.
At this point, our group is actively pushing back on SysML, at least for our roles. Each group's system(s) has a well defined interface to the whole, and everything else is decided within the team. We've found SysML mostly just duplicated work for us. Our software is already written in Simulink so we just build models of our system in that, too. We don't get much value from SysML, and whenever someone else tries to use SysML (like an architecture team) they don't know enough of the details our system.
I don't claim to know much about this stuff, but that's been our experience. The speed and flexibility of our engineers has vastly improved. We've started catching integration issues months in advance, when they are still easily fixable.
At first we just created some "Bill Of Models" to define systems and simulations. Slowly we've expanded the scope. Each BOM contains a system definition, components, subcomponents, interfaces, and some metadata. There's pointers to different repositories, parameter databases, and scripts to configure runtime environments. We have a small tool that reads BOMs and instantiates them as full simulations.
When someone wants to test a new system variant, they can usually just modify an existing BOM. If they have a new feature, BOMs give them an easy way to see and create every variant simulation to work with. We had to do a lot of standardization of our models, but that helped our efforts to move toward fully automated tests and CI/CD. We now have a web-based catalog of models and BOMs that are automatically generated, run, and tested. All of this has also helped get new people to use simulations for their work.