• Develop your business logic much faster.
  Utilize the QM domain for app development in more and more use cases.
• Reduce safety processes and costs.
  Business logic development is taken out of the functional safety (ISO 26262) process.
• Ensure consistency and completeness.
  Use a certified toolchain to design the behavior of the actuator interface.
• Attract more software engineering talents.
  The QM shift makes it easier for people to get started in the field.

Software features and updates will shape our future driving experience to a large extend – and they must adapt fast to changing needs. However, a major challenge is slowing things down: every software component that has potential access to safety-related vehicle features needs to be developed in accordance with ISO 26262 („Road vehicles – Functional safety“), which requires vehicle function developers to have profound expertise in safety design. Additionally, they need to adapt the code to hardware variances across models and brands.

Managing these complex processes does not end with the series release: it continues over the entire lifecycle of the vehicle. Vehicle apps must be prevented from disabling safety functionalities or interfering with vehicle behavior under all circumstances. Today, this requirement is usually fulfilled by completely preventing the "vehicle app" in the QM domain from having any active (write) access to the vehicle.

Safeguarded Actuator Interface from ETAS isolates the safety load, allowing the business logic to be developed in the QM domain. The safety domain stays the same for new use cases. Instead of completely blocking the access, the software provides a well-defined and safeguarded interface for a vehicle app to actuators. It ensures that no command which could potentially endanger the vehicle’s safety is forwarded to the actuator. A rule-based supervision mechanism decides when to enable the app and when, for instance, it needs to switch to a fallback function.

Safeguarded Actuator Interface is not limited to a specific use case. It is always designed for a specific actuator such as wipers, windows, mirrors, seats, trunk, etc. – and abstracts its interface. This significantly reduces the complexity and the necessity for software variants.

• Keep the vehicle in a safe state by ensuring that no safety-threatening command is forwarded.
• Use rule-based supervision to decide on the correct action like enabling an app or switching to fallback function.
• Abstract the actuator interface to limit software variants and reduce complexity in the app.
• Design the solution for a specific actuator instead of a specific use case.