Rethinking the SW Platform for Automotive RT-Cores: Key Design Considerations – What Must We Get Right?

?? The Hard Part: Balancing Flexibility, Safety, and Performance in a New Automotive Platform

(This article builds on [Part 1: Rethinking the SW Platform for Automotive RT-Cores: If We’re Moving On, What Can’t We Leave Behind?](here). If you haven’t read it yet, check it out!)

?? The Real Challenge Begins

In Part 1, we defined what an alternative to AUTOSAR Classic must preserve—but now comes the hard part:

?? How do we design it to meet modern demands while avoiding unnecessary complexity?

A real-time control platform must balance:

• Real-time performance
• Modularity
• Safety compliance
• Scalability and maintainability

How do we structure it effectively? Let’s explore the key design considerations that will define a future-ready platform.

?? Key Design Considerations

1?? Ensuring Real-Time Determinism Without Unnecessary Complexity

?? How do we maintain strict timing guarantees while ensuring scalability and adaptability?

• Should we stick with a static scheduling model like AUTOSAR OS or introduce more flexible scheduling mechanisms?
• How do we allow mixed-criticality scheduling without breaking determinism?
• Can we avoid overengineering safety mechanisms while keeping compliance manageable?

?? What matters: The platform should meet strict real-time constraints but also allow efficient execution of non-time-critical applications.

2?? Structuring a Future-Proof Communication Model

?? How do we modernize communication while ensuring compatibility with existing systems?

• How do we ensure CAN, LIN, and Ethernet remain well-supported while introducing modern communication stacks?
• Should communication be fully abstracted, or should we retain tighter integration for efficiency?
• How do we enable service-oriented communication without unnecessary overhead?

?? What matters: The communication model must be efficient, scalable, and flexible, allowing legacy support without blocking innovation.

3?? Functional Safety Without Slowing Development

?? How do we support ASIL-D applications while keeping development workflows efficient?

• Can we prevent safety certification from becoming a development bottleneck?
• How do we allow ASIL-D and QM applications to coexist without separate development flows?
• Can we reduce certification costs while maintaining compliance?

?? What matters: A single development process where applications can scale from QM to ASIL-D without major refactoring.

4?? Rethinking Configuration & Integration

?? How do we eliminate rigid, XML-based workflows while ensuring traceability and consistency?

• How do we move away from static XML configurations while keeping structure and traceability?
• Can we introduce runtime configurability without impacting safety?
• How do we make configurations human-readable and version-control friendly?

?? What matters: A structured yet flexible configuration model that keeps core system settings deterministic but allows adaptability when needed.

?? The Road Ahead: What Comes Next?

This article lays out the key design considerations for a next-generation real-time platform. But the real question is:

?? Which of these considerations is the most critical? What should be prioritized first?

That’s what I’ll explore in the next part of this series:

?? [Part 3: Key Building Blocks – How Do We Structure an Alternative?](Insert Link)

?? Missed Part 1? Read it here!

?? What do you think? Which design consideration is the most critical? Let’s discuss!

#AUTOSAR #FunctionalSafety #SoftwareArchitecture #RTOS #AutomotiveSoftware #MobilityInnovation #EmbeddedSystems