[inigoalonso]

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.

[nnadams]

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.