As a Model-Based Developer, navigating the differences between classic and adaptive, it’s essential to understand how the role shifts across platforms. Classic expects full system modelling with tight integration into the architecture while adaptive focuses more on modular logic with communication and integration handled in C++. Knowing where to apply your modelling skills is key to work effectively across both platforms.
As a Model-Based Developer working on Automotive systems, you’ve probably encountered the term AUTOSAR (AUTomotive Open System Architecture) more times than you could count. To know more about the AUTOSAR in general, refer to the blog article on AUTOSAR Classic by Nabile Khoury and AUTOSAR Adaptive by Yatish Chitluri.
The AUTOSAR Classic Platform designed for embedded systems real-time control systems that require high reliability. It is based on a layer-based architecture that includes, Application layer, Runtime Environment layer and the Basic software layer. The classic platform is most suitable for control units in areas such as powertrain, chassis, body and safety.
The AUTOSAR Adaptive platform is introduced to address the new challenges in the modern vehicles, especially those related to autonomous driving, connected services and high-performance computing. It supports dynamic application deployment, service-oriented communication and execution on powerful processors.
As the Automotive world is shifting towards the Software Defined Vehicles (SDV), it is important to understand the difference between the AUTOSAR Classic and Adaptive. This blog article summarizes the application layer differences, particularly focusing on the communication and modelling workflows relevant to your Model-Based Development role.
Key Mindset Shift at Application Layer
From Predictable to Dynamic Behavior: In Classic, everything is defined – schedules, data flow, and integration. Adaptive requires thinking about runtime variability, and configuration updates.
From ECU to Application: Classic AUTOSAR tightly binds software to ECU configurations. In contrast, Adaptive allows applications to run independently of specific hardware, making portability and reuse easier.
From Real-Time Constraints to Performance Optimization: Classic developers often obsess over microsecond-level timing. In contrast, the challenge in Adaptive is to manage concurrency, memory usage and startup latency on multicore systems.
From Static to Evolving Systems: Classic systems are deployed once and rarely changed. In contrast, adaptive systems are designed to evolve, incorporating over-the-air updates, new features and dynamic service registration.
As Model-based Developer, this shift impacts not only what you model, but also how you integrate and deploy your models.
Modelling Workflows
In AUTOSAR Classic, the application layer modeling workflow is structured and typically follows either a top-down or bottom-up approach.
The Top-Down approach begins with functional and system-level specifications. Software Components (SWCs), interfaces and runnables are defined and modelled using the standard AUTOSAR block set.
The Bottom-Up approach starts with existing logic, which are adapted to fit into the AUTOSAR architectures by assigning interfaces and mapping to AUTOSAR constructs.
Regardless of the approach, the communication between components is modeled explicitly, making this workflow highly deterministic and suited for control-centric, real-time applications.
In the AUTOSAR Adaptive platform, modeling at the application layer is more flexible but also more decentralized. Model-Based Development can be used to develop individual algorithms, which are then exported as C++ code. However, the overall application structure, service interfaces, and communication flows are typically implemented manually in C++ using Adaptive SDK.
Instead of static integration, services are described in ARXML, and service discovery and binding happened at runtime. There is no fixed top-down or bottom-up workflow, but rather a modular and iterative development cycle, where service and application evolve independently and integrate dynamically. This is better suited for high-computing domains like autonomous driving or connected vehicle services, where runtime adaptability is essential.
The top-down approach is accompanied with ARXMLs created during the architecture specification (from the AUTOSAR-tool) to instantiate the AUTOSAR blocks in a model. When the ARXMLs are generated from the Simulink model for the first time, this is bottom-up
Communication Differences in Application Layer
In AUTOSAR Classic, depending upon the Modelling tool, communication is explicitly modelled using AUTOSAR Block set.
You define, Software components (SWC), Each SWC has,
- One or more runnables – mapped to tasks or events
- Ports – Required/Provided
- Interfaces – Sender/Receiver, Client/Server, …
- Data Elements
Everything can pre-configured in ARXML and integrated through the RTE environment, which handles the inter-component communication.
In AUTOSAR Adaptive, Communication is not modelled in the same way as you would do in the classic. In Adaptive Platform, Components are Applications that expose or consume Services. Services are dynamically discovered and bound at runtime. You use some middleware protocols such as SOME/IP and DDS protocols. Communication is not modelled statically but however its handles in C++, typically with a Service proxy and Service skeleton.
What should a Model-Based Developer focus on?
Model-based developers should focus on how their models interact with the wider system architecture. In Classic AUTOSAR, the model is fully integrated and directly influences system behavior, including communication, scheduling, and resource allocation. Therefore, attention to details in interface definitions, runnable configurations and timing constraints is essential.
While the model still plays a critical role in algorithm development in Adaptive AUTOSAR, it is more important to design clean, encapsulated logic that can be wrapped into services or used within larger C++-based applications. Developers should also become comfortable working alongside software engineers who handle service coordination, configuration files and runtime diagnostics.
Finally, irrespective of platform, focusing on traceability from Model to generated code is important. Making sure that models reflect on the systems requirements and can evolve along with the changes in service definitions, integration and hardware configurations.
Conclusion
As the Automotive industry moves towards connected, autonomous and service-driven vehicles, understanding the architectural and conceptual differences between AUTOASR Classic and AUTOSAR adaptive becomes very crucial. AUTOSAR Classic remains ideal for tightly controlled deterministic applications, where static configuration and real time performance are important. In contrast, AUTOSAR Adaptive offers, flexibility, scalability and dynamism that are essential for domains like automated driving and vehicle-to-cloud communication.
For Model-Based Developers, this shift means adapting to different workflows, communication models and integration patterns in classic modelling effort directly focuses on the software architecture in adaptive. Your focus will be more on the logical core of application with integration handled through code and runtime mechanisms.
