Leveraging an integrated MBSE workflow to deliver better designs

When engineering feels more like snakes and ladders… you need MBSE that works

Complex design processes involving large teams of engineers are difficult to orchestrate in an organized way. Inevitably, we fall down the trap of ‘working in silos’. Requirements are often developed in a separate environment to system architectures, and the same applies to simulation and analysis. While this might work some of the time, it can cause major headaches and re-work if something has to be changed later on (a requirement, for example). Then you are back at square one.

In a previous blog post, my colleague Mark Sampson described the value of a “start integrated and stay integrated” philosophy using MBSE. Check it out to learn how continuous integration with a PLM backbone not only helps to preserve your sanity but can offer staggering savings in time and cost.

By working with the latest releases of Teamcenter and Simcenter, we’ve made it easier to connect designs and analyses to requirements all the way from definition, through design exploration and optimization, to performance verification. In other words, turning MBSE from a vision into a reality is now easier than ever.

Watch the movie below to see how it works. You’ll find more details in the post below.

Introducing System Architecture parametric optimization

Ed, our system engineer can work in their favorite MBSE solution, System Modelling Workbench (SMW), Rhapsody or Catia Magic. Ed uses SMW to prepare system architectures for products and functions and associate each component with different MBSE parameters.

At the same time, he can associate parameterized requirements to the same system components and functions. The result is a comprehensive description of the system architecture, its parameters and the related requirements.

Since Teamcenter manages the workflow, data, and relationships, there is a robust connection between MBSE parameters, system requirements and system architecture. This enables Ed to perform system validation and verification activities or analyses by initiating a verification request.

Ed, our system engineer, can now turn requirements (e.g. maximum temperature for a brake disc) into objectives and constraints for a design optimization study. Connecting up these activities means everyone will be able to see why the optimization study has been run and whether the result is satisfactory.

Input and output parameters are expressed as variables and responses for the optimization study. Variables represent the parameters that define the design space such as number of holes or diameter. Responses represent the measured outputs such as braking distance, temperature and/or cost.

The next step is to define the MDAO study objectives and constraints. The objectives are to minimize braking distance, temperature and cost. Requirements represent constraints on the study (we do not want to consider any designs that violate one or more requirements). This way, we find the best performing design within the constraints and design space we define.

Workflows: when 1 + 1 experts = 3

Breaking down silos means effective teamwork, capturing knowledge and enabling reuse.

Using Teamcenter workflows, Ed collaborates across teams defining requirements, systems parameters and their association with a system architecture.

Ed can also ask Sam, our simulation specialist, to coordinate the creation of multiple domain specific simulation models based on different simulation tools such as Simcenter Amesim, Simcenter STAR-CCM+ or Simcenter 3D.

Sam can use Teamcenter Simulation to launch HEEDS directly and automatically import study parameters from Teamcenter.

The optimization study definition created in Teamcenter can now be shared to Sam, our simulation specialist colleague using a workflow.

Creating the simulation model is further explored by Rohan Wanchoo in his blog.

Sam can use Teamcenter Simulation to launch HEEDS directly and automatically import study parameters from Teamcenter.

Once the analysis workflow is set up, it is immediately available for all stakeholders in either Active Workspace or from the MBSE authoring tool. This means that a systems engineer or requirement engineer can also execute or re-execute the study, either on their local machine or an HPC resource, to find the best performing design parameters.

As well as methodically searching the design space and automatically selecting the best performing design, HEEDS provides valuable insight into the relative performance of design candidates and the sensitivity of responses to the design parameters. This knowledge is captured into the digital thread to inform future design cycles.

No more snakes and ladders

By leveraging an integrated MBSE workflow, Ed and Sam have a robust and repeatable process for design optimization and continuous performance targeting. They can be sure that the optimal design parameters have been selected by the optimization study (without any human bias) and all stakeholders can see that the resulting design’s performance is verified against the requirements.

But there’s a twist….

With all good stories, there is a twist. The program is reviewed and found to be running over budget. The cost of the braking system must be reduced.

It looks for a moment like all Ed and Sam’s hard work might be wasted and they need to start again, right?

Wrong!

This is where MBSE really pays dividends.

Because everything is connected, all Ed needs to do is to go back to the requirements in Teamcenter and update them with the new values. The braking system no longer passes the updated requirement for cost, but that’s no problem. After making a few changes to the input parameters, he can immediately re-execute the optimization study to obtain a new best design that satisfies all requirements.

And he doesn’t even need to both Sam with the request. Everything he needs is already there.