Frequently Asked Questions (FAQs)

Why is AUTOSAR Adaptive not considered sufficient for ADAS/AD development?

AUTOSAR Adaptive does not focus on use cases that are specific to the development of ADAS/AD applications. These use-cases are

1. problem analysis/debugging of issues that have been observed in real-world drivings
2. testing of new features or feature changes with real-world data during development
3. validation of ADAS/AD features through simulation

These specific use cases are addressed by ETAS DMS through deterministic recomputes and virtual drives.

AUTOSAR Adaptive falls short of meeting needs for several critical reasons:

• 1. High Data Bandwidth (> 10 GB/sec)
• 2. Determinism for Problem Reproduction
• 3. Simplified Development Model
• 4. Integrated Development & Validation Toolchain

1. High Data Bandwidth (> 10 GB/sec)

Issue: The primary concern lies in AUTOSAR Adaptive’s inability to efficiently process large volumes of data, such as video frames, radar, lidar, and more. In intricate setups with multiple input sensors, e.g. cameras, radars or lidars, the challenge arises in seamlessly transferring data between application components (activities). The objective is to maximize available compute power for algorithms, minimizing the need for data copying between different sections.

Details: In complex scenarios, AUTOSAR Adaptive’s Inter-Process Communication (IPC) lacks emphasis on optimizing data transfer, especially for high-bandwidth content. Unlike the Virtual Run-Time Environment (VRTE), which previously employed a shared memory implementation (IceOryx) akin to the AUTOSAR Classic Platform, this assurance is not present in the AUTOSAR Adaptive platform.

2. Determinism for Problem Reproduction

Issue: AUTOSAR Adaptive’s inadequacy extends to the realm of determinism, crucial for reproducing problems in controlled environments, such as a lab setting.

Details: Reproducing issues in a controlled setting is a fundamental aspect of development and testing. The lack of deterministic behavior in AUTOSAR Adaptive hampers the ability to reliably recreate problems in laboratory conditions, hindering efficient debugging and resolution processes.

3. Simplified Development Model vs. Service-Oriented Complexity

Issue: AUTOSAR Adaptive’s service-oriented architecture (SOA) introduces significant complexity in modeling, configuration, and development, which can slow down iterative ADAS/AD feature development.

Details: ETAS DMS provides a streamlined development model focused on Activities and Runnables, reducing complexity while maintaining necessary flexibility. The YAAA architecture-as-code approach allows developers to specify system behavior in readable YAML files, avoiding the extensive XML configuration and modeling overhead typical of AUTOSAR Adaptive. This simplification accelerates development cycles without sacrificing the robustness needed for safety-critical systems.

4. Integrated Development & Validation Toolchain for AD Cycle

Issue: AUTOSAR Adaptive provides a middleware platform but lacks an integrated toolchain specifically designed for the complete ADAS/AD development cycle - from architecture design through deployment, testing, and validation.

Details: ETAS DMS offers a comprehensive, purpose-built toolchain that seamlessly integrates:

• Architecture-as-Code (YAAA): Text-based domain-specific language for modeling AD systems, enabling version control, code review, and collaborative development
• Automated Code Generation: Middleware bindings and execution framework code generated directly from architecture models
• Built-in Measurement & Recording: Flow tracing and data recording integrated at the framework level
• Integrated Analysis & Validation Tools: RecAll Player (built on the DoL framework) for deterministic recompute and validation, directly connected to the development workflow

This end-to-end integration eliminates the need to combine multiple disparate tools and ensures consistency across the entire development process, a level of integration not provided by AUTOSAR Adaptive.