How Do You Resolve the Competing Needs of the Different Groups?

I have worked on several distributed Model-Based Design projects in my career.  In addition, I was a consultant to two large aerospace companies on three different distributed Model-Based Design projects.  In these projects, the problems always occurred when trying to integrate the subsystem models into a larger simulation.  Two of these projects had an entire team dedicated to just integrating the simulation, and I was working on integration full-time on the third project.

In these projects, the subsystem development teams would identify needed changes and negotiate with the simulation integrator to get these changes into the simulation.  If it was something like a missing signal, the simulation integrators would simply modify another team’s model to extract the needed signal, and this would result in re-work each time the simulation had to be updated.  For more complicated updates, the simulation integrators would negotiate with the other teams to get the needed changes.  This would make it difficult for the integration team to manage the various versions of the simulation through the project lifecycle.

While we were working on these projects, none of us recognized the (now obvious) root cause of the problem:  Instead of having the changes flow downstream to the integration phase, the teams should have been pushing the problem upstream to the system-level design.

By pushing the problems upstream, the system-level engineers become directly involved in resolving the differences, ensuring that they get the appropriate attention.

Also, by pushing the problems upstream they are resolved once.  Instead of updating the submitted subsystem models every time there was another iteration in the development cycle, the problem would be solved at its source just once.

Request More Information

Contact Us To Learn More