Keynote Martin Eigner: Developing mechanics, electronics and software together

Prof. Dr. Martin Eigner gave the keynote speech at this year's ALM Future. Eigner is one of the most influential personalities in German-speaking systems engineering and has been involved in the development of PLM and engineering methods for decades. There was no question that I had to listen to this, especially as the event was only ten minutes away from my office.

His keynote address posed a central question: How is software changing product development and what role does Application Lifecycle Management (ALM) play in this?

Martin Eigner

Martin Eigner is one of the pioneers of product lifecycle management. He was a professor at the TU Kaiserslautern and founded the Institute for Virtual Product Engineering (VPE). Much of his work has shaped the understanding of integrated engineering processes across disciplinary boundaries.

Eigner became involved in the integration of mechanics, electronics and software at an early stage. His research focuses on PLM architectures, model-based development and end-to-end engineering processes. A central concern is the combination of methods, tools and organizational structures. These are all topics that I have been working on at SE-Trends for over ten years.

From product to service

A central theme of the keynote was the change in business models. In traditional industries, companies sold a product and then largely lost contact with the customer. Maintenance or spare parts were the only remaining interactions.

Digital products are fundamentally changing this model. Networked systems remain permanently connected to the manufacturer. Software updates, usage data and digital services are creating new value chains.

Eigner described this development using the automotive industry as an example. Vehicles are increasingly developing into platforms for digital services. Functions can be activated retrospectively or used for a limited time. Customers no longer just pay for the product itself, but for its use or additional functions. Some manufacturers assume that a significant proportion of vehicles will be operated in the sharing model in future.

This business model is changing the role of product development. Products remain part of a digital system throughout their entire life cycle. Development, operation and service are merging.

Cybertronic products

Eigner describes modern technical systems as cybertronic products. They consist of three components: mechanics, electronics and software. Software acts as a catalyst. It connects the individual disciplines and enables new functions. At the same time, this significantly increases the complexity of the systems.

Many innovations today are the result of electronics and software. Mechanical innovations continue to play a role, but the majority of new functions are created by digital components.

This development leads to a close coupling between engineering disciplines. Mechanics, electronics and software must be developed together. Traditional organizational structures with separate departments are reaching their limits.

System-of-Systems

With increasing networking, another level is emerging: system-of-systems. Individual products no longer act in isolation, but as part of larger systems.

One example is the infrastructure of a Smart City. Transportation systems, energy networks, buildings and communication systems are all interlinked. Each individual system functions independently, while at the same time creating a higher-level interaction.

This means new requirements for development. Products must not only function within their own system. They must be interoperable with other systems.

This perspective shifts the focus from individual products to Platforms and ecosystems.

The challenge of complexity

The integration of several disciplines and systems leads to a drastic increase in complexity. Eigner illustrates this using modern driver assistance systems. An Advanced Emergency Braking System comprises numerous levels, from requirements, functions, mechanics, electronics and software to simulations, tests and production data.

Each of these levels is managed in different tools and data models. Requirements are often stored in ALM systems, hardware data in PLM systems and production information in ERP or manufacturing systems. A complete view of the system can only be achieved by integrating these data sources.

Limits of the „single source of truth“

The term single source of truth crops up in many discussions about engineering tools. Providers of PLM, ALM or ERP systems often use it as a central sales argument.

Eigner expressed a clear position on this. No single system can contain all of a product's information. Different domains require different tools and data models.

PLM is talking about the single source of truth. ALM is talking about the single source of truth. But even the Pope is not the single source of truth.

Martin Eigner

Instead of a single data source, you need an integrated data model across multiple systems. Only this integration enables consistent decisions.

The V-model rethought

Eigner criticizes the classic interpretation of the V-model. The model was originally developed in software engineering (which I personally do not agree with). It describes a linear development of specification, implementation and testing (here, too, I have a slightly different opinion).

Be that as it may, this model is not sufficient for cybertronic products. Mechanical and electronic systems require different development processes. Simulation plays a central role and takes place very early on in the process.

To take this into account, Eigner adds additional elements to the V-model:

• Early simulations at system level
• Virtual tests with digital models
• Physical tests in later phases

This creates an iterative development process that combines simulation and real tests.

The role of ALM

Application Lifecycle Management plays a special role in this architecture. ALM forms the backbone of software development and links several phases of the life cycle, from requirements to operation. Software tools already support this process very well today. Developers can link requirements directly with code, tests and releases.

This kind of end-to-end integration has hardly existed for hardware to date. This creates a gap between software and hardware development.

Requirements across disciplines

One example of these differences is the handling of requirements. In software projects, there is often a direct relationship between a requirement, a software module and a test.

This model does not work in hardware development. Tests there usually relate to functions or system behavior, not to individual components. (I don't entirely agree with him here either: Here a lot is changing at the moment)

This is why interdisciplinary development requires a system architecture that combines requirements with functions and physical architecture. Only this architecture enables consistent traceability.

Versions, changes and configuration

Another problem arises with version management. Software usually uses Semantic versioning with major, minor and patch versions. Hardware, on the other hand, uses other concepts such as revisions or iterations. These differences make the integration of PLM and ALM systems more difficult.

When software and hardware changes interact, versions must be synchronized. Without coordinated configuration management, inconsistencies arise between software versions and physical hardware.

Eigner views change management as a crucial process in complex development environments. Changes arise in all disciplines and must be evaluated across system boundaries. The most difficult step remains the impact analysis. Changes rarely only affect a single system. They affect functions, software modules, hardware components and tests simultaneously.

Without end-to-end traceability, this relationship can hardly be analyzed.

Challenges of the digital transformation

Technical integration alone is not enough. Many problems arise from organizational structures and corporate culture. Disciplines often work in separate departments with their own tools and processes. These silos make collaboration difficult.

It's not only to connect hardware with software. There are different tools, different methods, different processes, and different speed. So this is not only a technical problem - it is a cultural one.

Martin Eigner

ALM and PLM implementations therefore rarely fail because of the technology. The more difficult part lies in the change management of the organization. Eigner identifies several risks for companies developing cybertronic products:

• Increasing system complexity
• Skills shortage in systems engineering
• Security risks of networked systems
• Regulatory requirements

Networked products open up new business models, but at the same time create new areas of attack. Security and compliance aspects must therefore be considered early on in the development process.

Conclusion

Martin Eigner drew a clear picture of the current transformation at ALM Future. Products are developing into networked cybertronic systems. Software is becoming the central driver of innovation. Many of the challenges are not new. However, he presented them well for the event's target audience and illustrated the scale of the challenges

ALM and PLM are important components of this transformation. However, their success depends on more than just tools. Integrated data models, end-to-end traceability and functioning interdisciplinary processes are crucial. Eigner is thus pointing out precisely the challenges associated with Product Velocity can be solved.

At the event, I had the opportunity to talk to Martin Eigner and, in particular, to show him the Velocity Loop to the public. The presentation met with a positive response, especially as business is explicitly included as an important discussion partner.

We agreed that the central challenge remains organizational: companies must learn to develop complex systems together. This is the only way to take advantage of the opportunities offered by digital products without failing due to their complexity.