Continuous innovation through continuous engineering

Should I care about bridging the gap between two simulation worlds?


I have been thinking about putting my thoughts down about Continuous innovation through continuous engineering. I have been interacting with experts from two different sides of the same coin. Both are different in terms of what they do and deliver, but both are related. I want you to be the judge and decide if you think that there is a need to bridge these two sides so that people who manufacture and use complex products can get the benefits of both. If you don't agree with me, I will understand, no hard feelings.

In current product development processes, various methodologies and supporting software suites are used for system level analysis and multi-physics simulation analysis. Both are critical parts of the continuous engineering methodology, but in the past they have been carried out in silos by separate teams with minimal interaction. In this article I pose a few questions. Hopefully the answers dictate whether there is a need to connect system level analysis and multi-physics simulation or not to ensure the continuous engineering approach and encourage continuous innovation.

Does the famous 'V' model work with complex products and systems?

The V model, shown in Figure 1, is the way engineers have looked at the product development processes for many years. It starts with requirements then continues to describe the system, design the system and then the long phase of implementing the system. Traditionally, software, mechanical, and electrical engineers build prototypes. Their prototype is then run through a set of expensive tasks during the design process. It is not unusual to spend 72-90 percent of cost on the prototype testing alone. When an error is discovered you repeat the whole loop again with the addition of a complex and costly change management process.

Figure 1. The V model
the V model
the V model

These days, products are more of a cyber-physical aspect. Products aren't just mechanical anymore. They are smarter, more efficient, and are a combination of multiple engineering disciplines.

The combination of multiple engineering disciplines is great. The positive result is innovative products such as smarter devices. Unfortunately, the traditional work processes means the various types of engineers are not working together to create great products. They're working in silos, focusing on their own discipline. This solidarity creates problems when it is time to analyze the design and predict behaviors.

New technologies and processes are necessary in order to understand the cross interaction and cross dependency between what the mechanical engineer designs, what the software engineer develops, and how the system engineer sees the market.

This whole ecosystem is basically calling on us to help define new technology.

There are two main developments in the market that influence how engineers work today. One is the emergence of model-based system engineering. Model-based system engineering uses models and a set of languages to describe how the system behaves. As a result, engineers can better communicate and analyze the system to describe the requirements and how the design meets the requirements.

SysML and UML have become more common on the system engineering level in order to formalize and have more rigor in the way you specify and represent system through models. We also see a strong emphasis in engineering companies around what we call "physical simulation". Physical simulation is where you have a software capability to:

  • Analyze the physical behavior
  • Analyze the physical specification of your system
  • Predict how the system will behave adhering to the laws of physics

A systems engineer describes the system level modeling and what we call the system as a whole. The physical simulation describes different engineering aspects like electrical, mechanical, electronic, hydraulics, and thermal. Many engineering aspects can be described using system level modeling tools and physical simulation tools. However, the challenge is these two sets of tools are not connected, instead they operate in silos by different teams. This is a big gap between:

  • How you describe your system from the high-level perspective
  • The components:
    • how they interact
    • how they are structured
  • The low fidelity analysis and low fidelity physical simulation supported by tool

Both systems level modeling and physical simulation are important to the design process, but, they are more important to what is referred to as continuous verification. Even today, there is disconnect between the two. The goal is to bridge this gap and allow engineers to have productive interactions between the system level analysis and the physical level analysis. This is why there is the emergence of the new "V in V" model as shown in figure 2.

Figure 2. V in V model
continuous feedback in early systems design phases
continuous feedback in early systems design phases

What engineers do with physical simulation and analysis

In the end, it all comes down to saving time and money in the development process. New products are supposed to be more compact, more efficient, more reliable, and delivered in a flexible and timely manner. This is true for most industries, especially for manufacturers of technical systems from the automotive, energy, oil and gas, aerospace and defense, medical engineering, mining, ship building or for producers of rolling stock or of machinery, to name a few. This is where multiphysics simulation enters the scenario. Not only does virtual prototyping and testing help engineers understand the dynamic behavior of a system as a whole (including all subsystems), it saves time because there is no longer a need to create numerous prototypes. Instead of repeatedly taking measurements, model-based simulations make repetitive status more convenient and help to pin down the most optimal design.

Technology and solutions that close the gap

There are multiple approaches to close the gap between system level modeling and physical simulation For example, you can find a new language to take both these design worlds into one platform. Another alternative is to practicing and or conform to an industry standard modeling interface.

Find a new language: The new language can, and should, include everything that relates to product development. When you use that new language you can define the semantic to simulate and analyze the system. Several attempts in the past have tried to do this. It's overwhelming and complex. And unfortunately those attempts were not successful.

There is an emerging standard called Functional Mockup Interface (FMI). FMI, I believe, has the capabilities to bring systems engineering and physical simulation together. It allows information and standard interface exchange between computers. This is between what is referred to as executable units that exchange information and allow you to earn what is now called cross-simulation.

Cross-simulation is the ability to take multiple domains and mobile models that describe different aspects of the system, and run them together. You can understand the interdependencies and the emerging behavior when those interactions occur.

Why is FMI important? It is important because this is the technology that allows us to bridge this gap between systems modeling and physical modeling. Imagine the virtual product environment which is the ability to take those different models and connect them together under a single environment with a standard language like SysML that defines system bandwidth and system interaction. Now, if you can use something like FMI to create interaction between system level model and behavior and specific detailed analysis that describes in the multiphysics simulation, then you have a mechanism not just to move requirements from system level into more detailed engineering analysis, but also to have a feedback loop and understand the behavior of the system because you can simulate.

Imagine a system engineer using SysML or another system level modeling language to define:

  • A set of concepts
  • A set of components
  • The interaction
  • The high level behavior of the system

Today this is where the knowledge stops. You don't know

  • The actual physical behavior
  • The physical timing
  • How the system will behave
  • How it will perform

Today, with FMI, you can generate a set of executable units from simulation tools. You can combine this with a set of software provided by your IT department, packaged around the FMI interface. With the click of a button the system engineer can cross-simulate and understand the interdependencies and know the analysis of the system as a whole.

This is a quite an achievement from what system engineers can do today. It is progress in the way system engineering and other specific engineering disciplines interact and I already see tremendous interest in the market for those type of capabilities. IBM in partnership with ITI has developed a hybrid co-simulation platform in this space.

Benefits of a hybrid simulation solution

When system engineering is completed at an early stage it tends to be more accurate, use more rigor, and can identify design errors at the right time. Engineers have tried these techniques and as a result they've realized these benefits:

  • Reduction in development cycle time
  • Faster delivery to the market
  • Improved quality
  • Improved accuracy
  • Reduced cost
  • Reduced number of change requests over time

Accidental errors found late in the cycle are not easy to overcome. Recently these errors have cost major aircraft suppliers and aircraft OEMs delays in product delivery. The delays have lasted years and cost billions of dollars.

The hybrid co-simulation platform gives tools and technologies to engineers that allow them to be more innovative. There is no longer the need to build a costly single prototype. Instead, engineers can look at the design and evaluate different alternatives in the virtual environment. They can be more innovative in the design phase as they explore various ideas for their smarter product.

All of this, of course, translates into a reduction of costs. That's the bottom line. When you take a look at companies that have applied those techniques, where those companies are still working in the old fee discipline that I described before, we see very clear benchmark in favor of the company that is applying those new continuous methodologies and invest more on the early design phase.

With the FMI-compliant IBM® Rational® Rhapsody® Suite you can use SysML tools to generate a set of FMI specifications that allow those models to participate in the cross-simulation. Through this IBM Rational Rhapsody integrates with ITI's SimulationX. Together they form the hybrid platform that gives you the ability to run both system level modeling and simulation together in an integrated environment. You can try this tested solution yourself with the free trial for Rational Rhapsody. Be sure to download the trial version of SimulationX, too.

I will be more than happy to receive your feedback and suggestions on this article. You can reach me at

Downloadable resources

Related topic


Sign in or register to add and subscribe to comments.

ArticleTitle=Continuous innovation through continuous engineering