Navigating the Software-Defined Era: Why a Holistic Systems Engineering Approach is More Critical Than Ever

By Hans-Juergen Mantsch, Siemens Digital Industries Software and Moshe Cohen, IBM Engineering

The engineering landscape is undergoing a profound transformation. From automotive to aerospace and defense, the ability to deliver differentiating value through software is increasingly defining the product. We’re seeing firsthand how crucial it is to evolve our methods and processes to harness that power. This shift presents an opportunity to expand systems engineering beyond its traditional silo into a digital thread for coherent, multi-domain, cross-discipline engineering.

The Elephant in the Room: We don’t have a Modeling problem, we have a model-usage problem

We’ve become adept at creating system models. Yet, studies (including some published in IEEE), as well as our own observations at Siemens and IBM, show that these models are rarely used past the concept phase. This represents a significant missed opportunity, especially as they become more critical to project success.

Consider the automotive industry, where software content is skyrocketing and vehicles now evolve continuously through over-the-air (OTA) updates. Every update is a system change, starting with new or revised requirements, impacting safety, interfaces, architectures, behaviors, and potentially side effects. Yet, systems engineering often remains a frontend activity even as complexity continues to grow.

The core question: How do we move systems engineering from the upfront stages to driving the entire lifecycle, from system-level architecture through downstream software, mechanical, and electrical engineering, so that companies can truly deliver software-defined products?

The Cost of Neglecting Systems Engineering

The consequences of a fragmented approach can be severe. As reported in Automotive News and other industry media, one major automotive program’s final testing phase reportedly uncovered hundreds of software defects per day, requiring thousands of technicians to triage and resolve them. This was clearly a disaster. Often, what we observe is a “wall” between requirements engineers, system architects, and downstream domain engineers: requirements teams build complex models and detailed reports, only to have them “thrown over the wall” to architects who sometimes ignore them, working instead on the assumption that “we [the downstream domain architects] know anyway what’s needed.”

This highlights a need INCOSE has already identified: systems engineering must guide and orchestrate the overall technical effort, hardware, software, testing, and other specialized disciplines, to ensure solutions meet stakeholder needs and expectations.

Bridging the Gap: The Demands of Software-Defined Products

Software-defined products fundamentally change systems engineering. Functions are no longer solely mechanical or electrical but increasingly software-driven, enabling easy behavior changes and the introduction of new features. Said differently, development never truly ends. That continuous evolution introduces immense complexity in safety, interface stability, and overall system integrity.

The story of Fisker Ocean serves as a cautionary tale. This car company, aiming to leverage software-defined capabilities, ultimately filed for bankruptcy. Industry reporting on the program’s collapse points to a pattern common to many software-defined product failures: individual software and feature teams can perform well in isolation, while a lack of ownership over the entire system, resulting in a clear lack of comprehensive systems engineering, ends up undermining or even killing the end product.

The Evolving Role of the Systems Engineer

Systems engineering teams are growing, but the ratio of model creators to model consumers is shifting dramatically. Based on what we see in our customer interactions, for every model creator, there are now 5 to 10, sometimes more, model consumers or reviewers (e.g., compliance and security officers), who use the models for their own analysis and can raise critical feedback that must be addressed swiftly.

For example, a Systems Engineer makes progress developing a model, reaching a certain milestone, and moving on. In parallel, a compliance officer checks the model for adherence to industry regulations. This requires tools that are, on one hand, powerful for the systems engineer as a model creator but yet accessible and intuitive for occasional users, like a compliance officer, who don’t have time to learn a modeling tool. And all users, models creators and occasional users, need to be able analyze models in context, often with bidirectional digital threads and integration into the rest of their respective toolchain.

Modernizing Systems Engineering Tools: Web-Native and Cloud-Native

To address these challenges, Siemens and IBM have focused on developing third-generation MBSE tools, like IBM Rhapsody System Engineering and Siemens’ Systems Modeler for SysML V2, that are web-native and cloud-native, for several reasons:

• Budget Constraints: Companies don’t want to keep funding old, complex on-premise infrastructure, as cloud-native solutions offer flexibility and a lower TCO (total cost of ownership).
• Accessibility for Consumers: Model consumers who interact with models only periodically need intuitive tools requiring minimal training. A web-native interface, accessible from any device with a browser, meets that need.
• Scalability: Cloud-native architectures scale up and down with project demand, providing agility and cost-effectiveness.
• Collaboration: Software-defined products are created in a joint effort where OEMs, suppliers, and service providers benefit from powerful ad-hoc collaboration platforms.

These tools bring essential capabilities, such as simplification, automation, and synchronized views for large, complex models. But as said earlier, the real challenge isn’t creating models; it’s ensuring they propagate and get used. And this requires capabilities that go beyond the standard.

Beyond Standard Tools: Three Key Considerations

Three considerations go beyond standard tool capabilities to unlock systems engineering’s full potential:

1. Domain-Specific Languages (DSLs): Formal languages like SysML V2 are powerful, but engineers prefer working with concepts native to their domain. An automotive DSL lets engineers describe designs in automotive terminology, making models easier to create and easier for consumers to understand. DSLs are a key enabler of SysML V2 adoption. Of course, the same applies to any other industry. And even within a given industry, and within a single enterprise, we may need multiple DSLs to address different needs. DSLs must be flexible, easy to define, share and deploy.
2. Seamless Integration Across Domains: Systems engineering can’t operate in a silo. To guide and orchestrate downstream engineering, it must integrate with other domains, extracting information from SysML V2 designs into a continuous, model-based flow downstream. Examples include auto-generating initial UML models for software teams to elaborate, or deriving electrical and communication architecture from system interfaces.
3. Methodology Guidance: Many organizations struggle to adopt modeling methodologies. While approaches vary (the “V” model, Agile-V, SAFe, Arcadia, etc.), most of them share common principles like layered abstraction and iterative refinement, as demonstrated in the “zigzag” or “ladder” process. SysML v2 adoption will not be driven by posters on the wall. It will be driven by process guidance that is built into the model itself, by being customizable, live, and responsive to actual modeling progress, thus providing process flexibility, while guiding partitioners and enforcing enterprise consistency and best practices.

Scaling Up with AI: Engineer in the Driver’s Seat

The promise of AI in engineering is immense. Reviews show that engineers spend only about 20% of their time on creative work, with the rest consumed by repetitive tasks. AI can shift that balance by automating the mundane.

But implementing AI in regulated, safety-critical industries requires a nuanced approach: keep the engineer in the driver’s seat, with AI augmenting rather than replacing human expertise. Our approach centers on an AI hub that orchestrates and interacts with agents, which decompose problems, implement methodologies, interact with Large Language Models (LLMs), and connect to tools via standard APIs.

Examples of AI application in systems engineering include:

• Smarter (and more complete) integrations between requirements and modeling.
• Augmenting, modifying, analyzing, and documenting system models.
• Early verification and validation (V&V).
• Handoffs to other engineering domains.

This topic deserves its own paper, but it’s clear that AI-assisted MBSE, in the right hands, can improve many aspects of systems engineering, especially interfacing connected engineering domains. The real challenge isn’t demonstrating ROI or turning novices into “experienced” engineers. It’s about fitting AI into regulated industries with trust, assurance, and explainability, while still meeting compliance and legal requirements.

While there is a rush to embrace AI into System Engineering, the authors of this paper recommend first operationalizing systems engineering across the entire lifecycle, then scaling up with AI.

The Siemens-IBM Partnership: A Holistic Approach

At Siemens and IBM, we believe the real benefit of systems engineering comes from connecting it to the entire engineering workflow. Combining our solutions enables an end-to-end process, from systems engineering into architectural optimization, electrical/electronic (E/E) architecture design, software development, electronics design, and network communication.

This integrated approach helps:

• Improve Traceability: Traceability across all engineering disciplines, from requirements to implementation.
• Enhance Collaboration: Breaking down silos and enabling different engineering teams to work on a common set of information.
• Accelerate Development: Simulating complete systems based on integrated information, speeding up verification and validation.
• Streamline Compliance: Automating significant portions of compliance documentation, especially with AI support.

This lets engineers across domains, such as software, electronics, electrical systems, mechanics, and simulation experts, draw from a unified source of truth in systems engineering.

The Future is Integrated and Software-Defined This too deserves its own paper but suffice it to say that the transition to software-defined products, whether in vehicles, aerospace, or defense systems, demands a sophisticated, integrated approach. Combining Siemens’ and IBM’s systems engineering capabilities empowers customers to make that transformation efficiently and at pace. Enriched with cloud technology and AI, this framework enables continuous innovation, where new software-driven features can be deployed rapidly, even after a product has shipped. We believe that once systems engineering practices are established and augmented with AI, organizations will be much better positioned to navigate the software-defined era and deliver the next generation of innovative products.

About the Authors

Sponsored Content by Siemens