Times are changing for 1D modeling. With an influx of software and electronics into traditionally mechanical products, more and more organizations are turning to 1D simulations, both from a systems perspective and from an embedded software perspective. There’s an opportunity for these perspectives on 1D simulations to converge, but first there are some cultural challenges to overcome.

What’s 1D Modeling and Simulation?

If you’re new to the party, here’s a little orientation.

A 1D model is something akin to a block diagram, except that the blocks have equations and formulas behind them. Each block represents some kind of behavior, whether that is logical or physical, of different items such as mechanical components, electrical processing, or embedded software code. Outputs from one block are sent as an input to other blocks. Connect all of them up and you can run a simulation by feeding it inputs from another source, say sensor data.

Now, let’s talk about applications.

System Engineering Applications

Why do system engineers use 1D models and simulations?

Because they are the most streamlined, and accessible, means of analyzing system behavior early in the design cycle. Remember, system engineers often develop architectures of products, across mechanical, electrical, embedded software, and IoT domains, long before any detail work is done. They go through their flow down process, where they break down requirements, assign them to newly created functions, develop logical representations, and allocate them to items. That Requirements-Functional-Logical-Physical (RFLP) process is supported by Model-Based System Engineering. It is a great and thorough way to design.

However, this RFLP model doesn’t let those system engineers test behavior. That is where 1D modeling and simulation comes into play. Engineers can mock up the system with all discipline-specific designs, abstracted back to equations and formulas. This lets them run trade studies, varying parameters of those equations, to understand what variables are crucial to performance.

Most importantly, and remember this, this analysis happens very early in design, a good bit before detailed design.

Embedded Software Applications

Why do software engineers use 1D modeling and simulation?

Coders like to use 1D Modeling and Simulation as a means to ensure their software will run on the target electronic hardware while fulfilling requirements as a control system. You might wonder, why is that hard? Well, modern products often use custom or configured processors, like FPGAs or ASICs, that are essentially programmed for certain uses. And even in the case where off-the-shelf electronics is used, there’s no guarantee that your code will run error-free on those processors. You have to test it. You have to fix it.

Unfortunately, in the case of custom or configured electronics, it might be a while before you get to prototype electronic hardware. If you wait to start testing when you have that on your hands, you’re asking for trouble. Run into errors and an entire development project can be put at risk.

Instead, embedded developers hook their software model, and then their compiled code, to a model of the electronic hardware, as well as the mechanical hardware side of things. This way they can virtually test the fact that the code runs on the electronics with the right control. The progression runs from Model-in-the-Loop to Software-in-the-Loop, to Processor-in-the-Loop, to Hardware-in-the-Loop.

While this can be started fairly early, this process occurs right in the middle of software development. It is a means to verify performance. This isn’t like Simulation Driven Design with mechanical design where it drives key decisions. Instead, this process is a way to validate that things are going according to plan.

Opportunities and Barriers

So there’s an opportunity here, right?

The opportunities for merging these efforts include:

  • System engineers do a lot of this work early in design. There is an opportunity for software engineers to reuse their work in their models.
  • There is an opportunity for consistency and accuracy. If both teams can leverage each other’s strengths in terms of specialized skills to model these items and components, then everyone benefits.

Yet, there are some challenges, including:

  • System engineers do their work early. Software engineers do their work later. By the time a software engineer gets to work on a project, the system engineers may have moved on to the next project.
  • The scope and objectives of these two groups are very different. System engineers are looking to predict performance, perform trade studies and develop architectures. Software engineers are looking to validate that their code works on the target electronic hardware. Such differences could lead to conflict about how to model and what detail to model.

Looking at these issues, I think it makes sense to have some kind of core competency for 1D modeling and simulation that could be leveraged by both groups. Perhaps their responsibility is to model blocks that most accurately represent items, maintaining the library everyone uses.

Those are my ideas, folks. I’m interested to get your thoughts in the comments.