Three Crucial Traits of Model-Based Engineering

Model-based engineering (MBE), the use of a model across the product development lifecycle, is a relatively new topic in the manufacturing industry. It’s also an intriguing idea for many organizations. And given the current adoption of different digital transformation efforts, some companies are closer to MBE than they might think.

Relying on Models for Development

Some aspects of MBE are already widespread in electrical/electronics (E/E) systems. For example, in detailed design for electrical distribution systems, many organizations rely on a model that underlies schematics, diagrams, and harnesses. In fact, the diagrams, logic, and three-dimensional assembly are interconnected through that model. To keep up with the growing complexity of new systems and products, engineers are using models more and more in software development.

However, some key traits of model-based engineering have not been broadly adopted in the product and systems development space. This post explores some of those traits and discusses why engineering organizations should consider them as they move toward MBE processes.

Smoothly Transitioning from Architecture-Driven Engineering

Organizations take different approaches to develop E/E system architecture. The necessary information may live in spreadsheets, documents, or even in an engineer’s head. That work acts as the basis for detailed design. And no matter the location of the definition, it must undergo a transformation before it can serve as the starting point for the MBE effort in detailed design.

Companies benefit when they put in the upfront work to document the architecture and then formally translate it into the necessary artifacts for detailed design tasks for electrical distribution systems, electronics systems, and software. In fact, it is crucial to do this. Otherwise, the engineering team is stuck reinventing the wheel during detailed design and is more likely to introduce human error into the process.

It is also vital to verify, from the bottom up, that the requirements assigned to each subsystem of the design are, in fact, feasible as you move into a detailed design. Too often, an ideal architecture is developed early on and then handed over to detailed design, only for the engineering team to learn late in the design cycle that it is not possible to meet key requirements. It is essential for engineers in detailed design to address all requirement targets and certify they are achievable.

Staying Connected with the Model

Another key trait of MBE is ensuring the model acts as a single source of truth to direct all tasks moving forward and across the product development timeline.

In a traditional approach to design, it is easier and faster to isolate a drawing or diagram and make a seemingly minor change there. Yet, even seemingly insignificant edits to those artifacts can lead to diverging definitions of the design. This inevitably causes errors, rework, and unnecessary waste. These so-called small changes to different deliverables also often lead to delays that may impact an organization’s ability to hit design release, product launch, and delivery deadlines.

It is essential for the entire enterprise to understand that the models used in this development phase are not just tools the engineering team uses to design and document a system. They are also critical reference artifacts providing a single source of truth on design and requirements. Engineers working on adjacent aspects of the system can rely on these models to govern their work. But a diverging definition will misinform their work, creating a trickle-down effect with more errors, rework, and waste.

Leveraging Model-Based Simulation

Finally, another oft-overlooked trait of MBE is the capability it offers to leverage simulations to make better-informed design and development decisions. You can see this applicability in multiple scenarios. It may involve using simulations to do simple design rule checks. It may be simulations to test more complex signal or power integrity analyses. Whatever the use case, all simulations need to spring from a synchronized set of models, if not from the same model. That single source of truth should guide any and all simulations, ensuring that the simulation checks the performance of the most up-to-date and accurate state of the design.

It can be tempting to try and run such checks and analyses when you can, as fast as you can—especially when the engineering team is working on a condensed schedule. However, in doing so, simulation engineers may be inadvertently introducing errors into the design. Unless the simulations work from the model, which represents the most current, accurate state of the design, their results will be inaccurate and even misleading. This can lead to your engineers making the wrong decisions based on the wrong information, once again leading to more scrap, waste, and time delays.

Preparing for MBE

As today’s products become more complex, many organizations are interested in adopting MBE to help guide product design and development. Your organization may already have the tools and know-how to leverage this powerful approach. Before starting, however, it is important to take stock of all aspects of MBE and make sure you can: smoothly transition the model from architecture-driven engineering, stay connected with the model during downstream development activities, and leverage the model for all simulation checks and analyses.

—–

For more information about digital engineering, architecture-driven engineering, and model-based engineering, visit our website or download our Digital Engineering Approach for Electrical & Electronic Design White Paper.