Why a “Shift-Left” Simulation Approach Demands Better Separation of Concerns

Today, I came across a post from Michael Entner-Gómez?? (see reference below) on LinkedIn about simulation in the automotive industry. His viewpoint on why simulation keeps failing—mainly due to late integration and a misunderstanding of AI-driven models—really resonates with my own experience. There’s a lot of talk about adopting a “shift-left” approach to catch problems earlier and cut costs, but many organizations are missing a crucial element: proper separation of concerns within software architectures. When simulation is done right, it doesn’t have to be a gargantuan (and expensive) effort of retrofitting or running massive cloud-based test suites. Instead, it becomes a flexible, early-stage design tool.

The Core Problem: Simulation as an Afterthought

According to Michael’s post, automakers often treat simulation like a late-stage validation tool, rather than an integral part of the development process. This results in:

1. Expensive rework late in the product cycle.
2. Excessive computing costs due to brute-force, cloud-based simulations.
3. Fragmentation and complexity introduced by multiple tools and AI/physics models.

Yet, as he points out, automakers aren’t the only ones at fault. Tool fragmentation, outdated frameworks, and the sheer complexity of advanced models also play a role.

Why Separation of Concerns Matters for Effective Simulation

1. Transport Layer vs. Application Layer

One of the first principles of good software architecture is the separation of transport logic from application logic. In other words:

• Transport Layer: Handles the communication (e.g., reading from sensors, network streams, or file inputs).
• Application Layer: Focuses on the core functionality (e.g., decision-making algorithms, data processing, or user-facing logic).

By abstracting these layers properly, the application doesn’t need to worry about how data arrives. It simply consumes the data from a well-defined interface. This makes simulations much easier because you can inject data from alternative sources—like recorded logs or test files—without having to refactor the entire application.

Autosar Classic vs. ROS

While AUTOSAR Classic has been a staple in the automotive world, its structure can be cumbersome for rapid simulation and early testing. Its tight coupling often forces teams to rely on the actual hardware or integrated environment, which is expensive to set up and maintain.

By contrast, frameworks like ROS (Robot Operating System) have a more modular messaging system, allowing developers to easily replace the “transport” component with test data streams. Want to use a file-based simulation? Just point your ROS node to that file. Want to go back to real sensor data? Switch back to the live feed—no rewriting of core logic required.

Real-World Examples of Flexible Simulation

1. Digital TV Middleware Testing

In my past experience working with digital TV systems, we had to test middleware that handled file downloads over an RF signal using the DSM-CC standard. We didn’t have a tuner on our PC, so to validate our implementation, we simply recorded MPEG-TS data and injected it into the middleware from a file. This approach was incredibly flexible:

• We could replay scenarios anytime without needing the broadcast signal.
• We could test edge cases (like noisy signals or packet loss) by manipulating files.
• We avoided the cost and complexity of specialized hardware setups for every test.

2. Thin Transport Layer at Bosch

Similarly, when working on certain projects at Bosch, we created a “thin” transport layer that allowed us to decouple our main application logic from the real-world transport mechanism. We could run the same software on a standard PC, injecting test data from logs or files, all without needing the actual target hardware. This let us simulate, iterate, and fix bugs quickly—long before moving to hardware-in-the-loop or real-world tests.

The Shift-Left Imperative

Moving simulation earlier in the design cycle—“shifting left”—can save billions in development costs. However, this strategy only works if the architecture supports modular testing and data injection. Without separation of concerns, teams end up performing monolithic simulations that require all components—including transport, application logic, and hardware drivers—to be present and functional.

How to Start Shifting Left

1. Refactor for Modularity: Break down tightly coupled systems. Define clear interfaces between transport and application layers.
2. Adopt Flexible Middleware: Consider more modern middleware solutions (like ROS) that simplify messaging and allow for easy data injection.
3. Automate Early Testing: Don’t wait for full system integration. Run file-based or synthesized data simulations from day one.
4. Document & Educate: Make sure every team member—from software engineers to safety experts—understands how and why simulation is shifting left.

Conclusion: Time Is Running Out

The auto industry faces mounting pressure to bring products to market faster, safer, and at lower cost. Late-stage simulation is no longer viable. A shift-left simulation approach is the answer—but only if backed by strong software architecture principles. By separating transport from application, engineering teams can easily inject data from multiple sources, run meaningful tests early, and iterate quickly.

In short, let’s take a page from successful, flexible projects—like those in digital TV middleware or the thin transport layers I worked on at Bosch—and apply it to automotive. The key to unlocking faster, cheaper, and more reliable simulation lies in thoughtful system design. Embrace separation of concerns, adopt (or adapt) modern middleware frameworks, and ensure that both your testing and development pipelines align with a shift-left mindset.

Michael’s LinkedIn post is a timely reminder that we can’t keep throwing massive cloud resources at a problem that might be fundamentally architectural. If we want to stay ahead—and keep costs and complexity in check—we need to get the architecture right and bring simulation into the design process from day one.

#Simulation #Automotive #ShiftLeft #SoftwareArchitecture #SDV #SoftwareEngineering #EmbeddedSystems #AUTOSAR #ROS #DigitalTwin #DevOps #Middleware #CloudComputing #AI #Testing #Validation #FutureOfMobility #Innovation

Author’s Note: I’ve seen firsthand the power of a well-structured transport layer abstraction in both consumer electronics (digital TV) and automotive environments. Let’s not let legacy frameworks and outdated assumptions hold us back. Embrace modern practices, and make sure your simulation strategy starts at day one—where it can make the biggest difference.

Reference: https://www.dhirubhai.net/posts/mikeentner_the-hidden-challenges-of-vehicle-simulation-activity-7291514677522558977-D1LX?utm_source=share&utm_medium=member_desktop