Manager's guide to MBSE

The Manager’s Survival Guide to Model-Based Engineering

Menu

Model-based engineering (MBE) is where the rubber meets the road when it comes to design. With this approach, the model represents a product or system’s detailed definition; one that can be used for manufacturing. Some organizations employ model-based practices broadly to manage all the nitty-gritty details involved in design. But there are challenges involved in transitioning to an MBE approach.

The Model-Based Side of Digital Engineering

Model-based engineering immediately follows the architecture-driven engineering phase when developing electrical/electronic (E/E) systems. Design engineers extend the E/E architecture definition to encompass all functional, logical, and physical design details. This includes the specifics of any electrical distribution systems, electronic systems, and, of course, software needs. Engineers can continue to explore and iterate on the design as long as they satisfy the requirements and constraints defined in the initial E/E architecture phase.

When organizations employ an MBE approach, they can gain significant advantages and benefits. That said, this approach is not for everyone. Your organization’s people, processes, and technology determine whether it will work for you. In this post, we’ll consider these different factors, as discussed in the first post in this series, The Manager’s Survival Guide to Digital Engineering, to compare and contrast model-based engineering with the architecture-driven engineering model of design.

The Cultural Fit of Model-Based Engineering

Before adopting any new technology-led improvement effort, it is essential to consider the cultural changes required to make your new initiative successful. When you embrace model-based engineering, your employees will need to adopt new process steps, take on new responsibilities, and revamp the way they do their day-to-day work.

Compared to architecture-driven engineering initiatives, model-based engineering is generally a far easier adjustment from a cultural perspective. Many of today’s engineers are already familiar with the concept. The same fundamental definition applies to each design representation: the schematic, the diagram, and the layout. When there is a change to one aspect of the design, that change automatically propagates to all the other representations. Having an integrated, underlying definition, powers quick and easy changes and permits engineers to explore the design space with ease. They can iterate on different aspects of a product’s design until they get to a feasible plan.

That’s not to say that there won’t be a need for adjustment. With model-based engineering, engineers will have to collaborate closely with others working on other aspects of the same design, even those working within other design domains.

Traditional methods often allow engineers to work in an isolated silo, where they must resolve any requirements assigned to their specific piece of the design individually. So, they often don’t see the potential implications of specific design changes to related items or the design as a whole.

However, the MBE approach keeps all team members on the same page. They can see everyone’s changes, understand their impact, and immediately communicate that a potential issue has cropped up. While, ultimately, this saves time and costs across the product development process, it can be a difficult transition for engineers who, historically, have only had to worry about their own specific design task.

Shifting to model-based engineering benefits the entire enterprise. When engineers can get out of their silos and collaborate on design tasks–all governed by that integrated definition–organizations can avoid late-stage problems that cost significant time and resources. Engineers also avoid those scrambling, last-minute fire drills to fix big issues days before the scheduled design release.

The Change Plan for Model-Based Engineering

If model-based engineering is the next logical step in your organization’s digital engineering strategy, then you need to start planning your engineering team’s transition to this new approach. Therefore, a robust change management strategy is crucial.

First, take the time to figure out all the requisite development process changes–this is the most important piece of that strategy. It is essential that your organization understands when the plan starts and what sort of inputs it requires to be successful. Some architecture is needed upfront to begin model-based engineering, even if it doesn’t come from architecture-driven engineering processes. Determine what that definition will be.

Next, you need to understand how detailed design changes are managed from a process perspective. Model-based engineering initiates and maintains collaboration throughout the entire development process. Simulation and analysis occur early and often in design, too. That’s why it is critical to define what characteristics and traits to track as part of your MBE effort. By identifying how deeply to explore the design space for each item, perhaps even with variations depending on requirements satisfaction, you can better manage these changes moving forward.

Model-based engineering can deliver your organization significant value. If it is a good fit for your organization, be sure to have a strong plan in place so you can reap those benefits.

The Technological Changes of Model-Based Engineering

It is also important to get your technology ducks in a row before making the transition to model-based engineering. As with architecture-driven engineering, the right technology solutions are key enablers. In addition to managing the cultural and process sides of the MBE transition, organization leaders need to consider how to support MBE-related changes from the technology side of things. Model-based engineering requires model-based solutions. The many different representations or aspects of any E/E system, including electrical distribution systems, electronic systems, and software design, must be built on model-based approaches.

Selecting those technologies is much easier when you are starting from scratch. But most organizations have a large amount of legacy design data they want to leverage forward as they pursue new design projects.

It is rare to start from a completely clean sheet. Carefully assess potential solutions to make sure they will support your engineering team. Organizations need to find solutions that support the easy migration of vital legacy information into their new, model-based tools and solutions. Component libraries, reusable blocks of circuitry, simulation templates, design rule checks, and more are examples of legacy data to migrate.

Recap

In this post, we’ve highlighted the people, process, and technology considerations organizations should take before transitioning to an MBE-based approach to design and development. Manufacturing leadership must consider the cultural implications of change, create detailed change management plans, and identify technology solutions that can support model-based engineering while integrating important legacy data. This will set up the organization for success as it moves forward.

—–

For more information about digital engineering, architecture-driven engineering, and model-based engineering, visit our website or download our Digital Engineering eBook

Chad Jackson
Chad Jackson
Chief Analyst and CEO of Lifecycle Insights
Chad Jackson is the Chief Analyst and CEO of Lifecycle Insights. He leads the company’s research and thought leadership programs, attends and speaks at industry events, and reviews emerging technology solutions. Chad’s twenty-five-year career has focused on improving executives’ ability to reap value from technology-led engineering initiatives during the industry’s transition to smart, connected products.