Graphic of MBSE's impact on digital transformation in electrical engineering, with icons for data, cloud, and circuits.

The role of MBSE in the Digital Transformation of Electrical and Electronic Engineering

Model and test your product and process architectures before committing to costly IT-projects
Menu

Digital Transformation is a trend that has seen growing momentum over the last decade. Today, it is adapted more and more in all areas of economy, state, society, and everyday life, and due to the current Covid-19 situation, it is experiencing a massive boost. It is therefore worthwhile to take a deeper look to understand its potential impact on the methods and processes in electrical and electronic engineering.

Whichever of the many definitions you may prefer, they all have one aspect in common: Digital Transformation should go beyond a simple mapping of analog documents and processes into the digital domain. It should explore new ways and opportunities to enhance today’s methods and processes for increased efficiency and accelerated innovation.

The Digital Twin: Revolutionizing Business and Process Innovation

In this context a wide range of innovative business and process models is currently taking shape with the spectrum ranging from value added value chain collaboration in product development, to smart sourcing and production and ultimately to products as a service. For example: customers buy a service rather than a product, such as mobility rather than a car, or production output rather than a machine. What at first glance may appear to be mere semantic quibbling, has the potential to profoundly transform established industries.

digital transformation
The Digital Twin is the enabler to a wide spectrum of business and process innovations

The common enabler to all these business and process innovations is typically considered to be the “Digital Twin” – a comprehensive digital representation of the product or service in all its metamorphoses across the product lifecycle – from requirement to as designed, as built and as delivered and serviced. This in turn requires an end-to-end digital process chain that provides the information needed in each use case in a fast, reliable and automated manner.

Maximizing Product and Process Innovation with Engineering Data

In the world of product development and engineering we already have a huge inventory of digital information that is created by a multitude of engineering applications along the engineering value chain: From requirements that describe a product’s or system’s intended behavior to functional descriptions and models, mechanical and electrical/electronic CAD data, simulation and test results, as well as operating software artefacts.

digital transformation and MBSE
A simplified representation of a typical product development IT landscape

Typically, some, but not all, of these applications are linked or connected to some sort of an information backbone (also referred to as PDM layer), which in turn interacts with enterprise level applications and environments for souring, configuration, change and release management. And, to complete the picture, we have data outputs that are passed to the shop floor to drive manufacturing and assembly (see fig 1. A typical product development IT landscape).

This diversity and heterogeneity of the data formats and structures generated by the different domains makes it not an easy undertaking to create point to point interfaces to begin with, let alone to network heterogeneous data and information to feed the various product development processes such as configuration management, change management or release to manufacturing.

The Challenge of Establishing Digital Standards in Product Development

If we look at the reality of today’s engineering applications, we find the first obstacle in the representation of an electro-mechanical (also referred to a ‘mechatronic’) product model, where consistency on a BOM level is complicated by the diversity of the data models used in MCAD and the ECAD solutions.

While in the mechanical world an assembly (e.g. a motor) may be used in several instances by simply copying it the bill of materials, in the electrical world needs use unique electrical reference designators to specify the individual assembly’s instance specific cabling, control, and protection (Note: Zuken has a solution for this common dilemma with its DS-2 domain data management technology that bridges the gap between mechanical and electrical assemblies on a BOM management level)

Info DS-2

If we go further and look at integration models that span the full product lifecycle, such as the popular V-model, we find that there is no established IT standard to support a digital process model that spans the full circle from requirements to detailed design through to manufacturing outputs.

digital product development lifecycle
The V-model is a graphical representation of a systems development lifecycle. It summarizes the main development steps in conjunction with the corresponding deliverables.

Why is that so? First of all, there is no such thing as one single product development process. What is typically referred to as “product development process” is in reality a combination of several activities and sub-processes that are carried out in parallel and frequently interact with each other, such as project management, concept development, detailed design or change and configuration management, to name just a few. The CAD system is just one element in an environment that is made up of multiple systems and processes.

Product Development is NOT a Linear Sequence of Activities

The CAD model is neither the starting point, nor the end of the product development process – it is just an embedded and integrated subsystem of the whole system of systems. And CAD itself needs to be distinguished at least between mechanical, electrical and electronic engineering disciplines.

Ideally, a new product is first described as a hierarchically organized consistent set of requirements (supporting the product mission), which are then translated into functional and logical structures which are gradually detailed down into CAD data and BOMs, as illustrated in the diagram below.

digital product development cycle
Requirement structures, functional structures and BOM cannot be related on a 1:1 basis. Source: Prof. Dr. Martin Eigner, Technical University of Kaiserslautern, Germany

Without going into excessive detail, we can observe two aspects in this illustration: firstly (moving from left to right), requirements, functions, logical elements and assemblies do not translate on a 1:1 basis as they move along the development and, secondly, physical items and assemblies (the dark blue circles) are accessed and used by multiple different processes (the light blue squares). The result is a matrix of dynamic relationships that is extremely difficult to describe in a linear evolution as suggested by the V-model.

Rethinking Digital Transformation: The Risks of a Single Source of Truth

It becomes quite evident therefore that it would be a massive undertaking to try and connect the multitude of applications and stakeholder that are employed in product development through direct interfaces in a monolithic ‘single-source-of-truth’ approach.

In addition to requiring an enormous amount of coding, the attempt to shoehorn heterogeneous applications and formats into one monolithic system inevitably involves the loss the flexibility to “plug-in” new best-in-class players and solutions that may emerge over time.

Moreover, Digital Transformation should not stop at the gates of an individual company: to maximize efficiency it must eventually include the extended supplier workbench ecosystem – and here the idea of a single-source-of-truth environment comes to a grinding halt.

From the perspective of the customer it is therefore common business sense to ensure a maximum of flexibility by avoiding dependance on one single IT supplier and a “single-source-of-truth” approach.

Embracing Flexibility: The Case for Federated Lightweight Information Systems

As an alternative to heavily integrated and inherently inflexible “single source of truth” approaches, academic thought leaders like Prof. Martin Eigner, Chair of Virtual Product Development of the Technical University of Kaiserslautern, Germany, suggest a “federated light-weight information backbone concept”.

This concept is based on a mix of light weight cross-discipline integrations, open web services, team data management applications and linked data model integrations (REST technology). In this approach the information that is needed to feed the different processes along the product development lifecycle can be extracted in a depth that is be determined by individual process needs.

The concept of federated light-weight information systems detailing digital trasnformation.
The concept of federated light-weight information systems. Source: Prof. Dr. Martin Eigner, ibd.

But how can you determine what kind and what depth of information you need to feed your product development processes, considering that there is no established industry standard?

MBSE: Mapping the Future of Digital Product Development

First of all, it is a good idea to figure out the future process and product architecture before committing to implementation. Here, Model-Based Systems Engineering or MBSE comes into the play.

Although MBSE is often associated with product and system modelling, it is also applicable to the modelling of IT and process architectures. “Model-Based Systems Engineering (MBSE) is the formalized application of digital modelling … to support system requirement, system architecture, design, analysis, verification and validation, process planning and service”, says the definition of INCOSE, the global association of systems engineers.

With the modelling and verification capabilities of MBSE it is possible to model both your idea of a future product architecture and the related engineering processes and workflows.

genesys for digital transformation diagram
MBSE helps to model and verify product and process architectures before committing to costly changes in the established IT infrastructure (image: GENESYS)

Using an MBSE tool like Zuken’s Vitech GENESYS, you can start by modelling and analyzing the status quo of your existing product and process architecture and model approaches to their transformation before laying hands on the productive environment. Both, product and process models can be simulated and validated before committing to the implementation of the digital transformation projects.

Info GENESYS

What’s next?

The digital transformation of product development is rapidly gaining momentum in the manufacturing industry, although standards are yet to emerge. To keep up with that megatrend it is time to explore innovative process and business models.

As we have seen in this article, MBSE can help to minimize the risk develop and verify digital process models and thus minimize the risk of IT implementation projects.

In this article, we have mainly focused on approaches to evolving the IT infrastructure to support the digitization of process development. In our comprehensive resource library you can find further reading on the topic of digital product development with MBSE.

Editor’s Note

This article is based on a presentation of Oliver Hechtl, Head of Data Management and Integration, Zuken Europe. A replay of this presentation can be accessed in the Zuken resource library:

Access the Webinar

 

Also see:

Klaus Wiedemann
Klaus Wiedemann
Marketing Manager Europe
Klaus Wiedemann is responsible for Marketing Communications across Europe covering web content, public relations and marketing programs. He works with customers to highlight their success through case studies and presentations for Zuken Innovation World events. Klaus is an enthusiast for two-wheeled vehicles and owns several classic bikes he likes to maintain and repair.