The SystemBlend™ Solution

This is a follow-up to my previous posts, What is Distributed Model-Based Engineering? and What are the Problems With Distributed Model-Based Engineering?.

I have encountered a variety of significant problems while working on several distributed Model-Based Engineering project.  This frustrated me so much that I began looking for a solution.

As I described in my previous blog posts, the difficulties were always encountered when trying integrate the components submitted by other groups.  I could not make any progress on a solution until I realized that the integration issues are not the root problem.  Instead, they are symptoms of deeper problems:  poor communication and coordination at the system level.  When I looked at the problem from this perspective, I looked at existing tools to find a solution.  I found many ways to address the technical details of integration, but none that focused on the communication and coordination needed to solve the root problem.

In analyzing the difficulties I encountered on various distributed Model-Based Engineering projects, I realized we were not able to recognize the root problem because our solution was not properly oriented.  The root problems occurred upstream as components were negotiated and implemented, and the problems flowed downstream to the integration effort.  We were addressing the integration problems as part of the integration effort, when we should have been pushing the problem back upstream.  If the problems could be addressed in the design and the implementation, they could be solved with dramatically less difficulty or even eliminated.

In my post What are the Problems with Distributed Model-Based Engineering?, I showed how the integration problems were magnified over time because they were repeated with each iteration as the simulation increased in complexity and fidelity.  In all of these projects, we used traditional software version control systems, but coordinating this across multiple groups proved to be problematic.  In particular, an update involving only one or two subsystems had to be coordinated across all contributors, and required an incremental build to update the simulation.  To fully address distributed Model-Based Engineering, I realized I needed to streamline project evolution in a different way.

SystemBlend™ introduces two innovations:

1. A unique workflow that ensures the integration problems are identified and resolved early without allowing them to flow downstream, and
2. A simple and novel versioning facility that addresses the unique needs of distributed Model-Based Engineering.

Workflow

A distributed Model-Based Engineering project is typically structured with one ‘sponsoring’ organization and other groups supplying subsystem models:

With this structure:

1. The sponsoring group designs the simulation and forwards the specifications to the groups implementing the subsystem models,
2. The subsystem groups implement the subsystem models, and
3. The subsystem groups send the models to the sponsoring organization and integrate them into the system simulation.

The SystemBlend™ application suite automates and accelerates this workflow, and adds techniques to avoid problems.  It includes one application for each phase of the development cycle:

• SystemDesigner:  The sponsoring group uses SystemDesigner to graphically specify the components and their connectivity.
• ComponentGuide:  The subsystem groups use ComponentGuide to guide the development of the subsystem models and ensure compliance with the specifications.
• IntegrationMaster:  The sponsoring group uses IntegrationMaster to automatically integrate the components into a working simulation.

SystemBlend™ adds these improvements to the above workflow:

• Design details are fully specified in SystemDesigner.  Instead of writing up specifications for the simulation from scratch, SystemDesigner guides the designers through the details in a natural, intuitive, and graphical fashion.  This eliminates ambiguity and incompleteness in the specification.
• ComponentGuide ensures the component exactly matches the specification.
• If the subsystem modeling group discovers they need a change to the specification, the issue is solved by pushing the problem upstream to SystemDesigner, instead letting the problem flow downstream to the integration engineers.
• Updating the system design database is easy and intuitive because of SystemBlend’s unique versioning facility.
• Because updates are negotiated in the design instead of resolved in integration, problems are solved once, instead of repeatedly when integrating each update to the simulation.
• When integration group receives the components, they can be sure that the subsystem models fully comply with the specifications.
• The information in the design database, coupled with metadata automatically included with each component, is used by IntegrationMaster to automate the integration effort.  This accelerates the process from days or weeks to minutes.