Aras' Present and Future with System Engineering

At Aras’ ACE user conference, I gained a little insight into the near-term and long-term vision for systems engineering and requirements management in Innovator. In this post, I’ve expanded on the tweets I posted during the conference to give a little more context.

The Near Term

https://twitter.com/ChadKJackson/status/1118207297702858752

There are some requirements management capabilities in Innovator today. This will change in the coming years, in an interesting way. But the big focus is on expanding that to cover systems engineering.

https://twitter.com/ChadKJackson/status/1118207767238467584

Now, there are a number of specialized systems engineering tools out there. They are very capable. However, they are often disconnected from PLM solutions. This silos the work of systems engineerings, isolating them from the rest of the development process. As I have mentioned before, the MBSE models that systems engineers create should be used as the basis for trade studies throughout development, not just defining the physical architecture at the beginning of development. Democratization is needed.

https://twitter.com/ChadKJackson/status/1118213890448474118

The number of PLM solutions that offer systems engineering capabilities is increasing. PTC, Dassault Systèmes, and Siemens PLM offer this functionality. It is good to see another PLM provider join them. Again, pulling MBSE work into PLM will help with democratization.

The Long Term

https://twitter.com/ChadKJackson/status/1118571260605108224

To be clear, Innovator today does not manage requirements composed of individual parameters but that is Rob’s vision for the future.

The idea here is that the numeric aspects of requirements become individual parameters. Each is managed individually. That opens up the possibility of using those requirements parameters in a lot of interesting ways.

https://twitter.com/ChadKJackson/status/1118571747886784512

https://twitter.com/ChadKJackson/status/1118572067173978114

https://twitter.com/ChadKJackson/status/1118572479629238279

https://twitter.com/ChadKJackson/status/1118573112126128128

https://twitter.com/ChadKJackson/status/1118574732083777536

The fundamental advancement here is that those parameters can then be reused in many other places. Specifications, test documentation, simulations, and many other things can make use of those parameters. If the parameter changes, it updates everywhere, including the original requirements.

This idea of requirements parameters also opens up a world of automation. Most notably, simulation automation can be executed using these parameters as goals or constraints.

One thing, however, that can’t be lost in all of this is context. Parameters can hold values and understand units. However, the requirements will often have the context of how multiple parameters relate to one another. Many requirements act as competing constraint against one another. This is a forward-looking vision, but it will be interesting to see how Aras develops and deploys this functionality over time.