An Investigation of the AUTOSAR Adaptive Platform from an Industry Perspective 1st Bengt Haraldsson
arXiv:2607.05227v1 [cs.SE] 6 Jul 2026
TRATON R&D AB, Södertälje Chalmers University of Technology University of Gothenburg Gothenburg, Sweden [email protected]
2nd Srijita Basu 3 Miroslaw Staron rd
Chalmers University of Technology University of Gothenburg Gothenburg, Sweden [email protected] / [email protected]
Abstract—Context: The reliance on software as a distinguishing factor in the automotive industry is increasing. With a combined reliance on vendor-supplied software and cost-effective implementation, the AUTOSAR consortium was initialized to provide standardized platform specifications that enable re-use. Specifically, the AUTOSAR Adaptive Platform (AP) specification aims to provide a high-performance service-oriented architecture. Objective: The goal of this study is to investigate what painpoints emerge when developing AUTOSAR Adaptive applications and whether they originate from the platform specification, its vendor-implementation, or its local usage. Methods: We conduct a Design Science Research study, developing a minimal AP that serves as an experimental prototype for our investigation. Results: We find that a combination of specification-inherent, implementation-based, and local practices contributes to the emergence of pain-points. Conclusions: We conclude that there are AUTOSAR specification-inherent reasons for pain-points, resulting from architectural choices and re-use goals. The implication for development organizations is the need to mitigate these effects through tooling that better supports configuration file management and reduces developer training time to properly understand the adaptive application runtime life-cycle. Index Terms—AUTOSAR Adaptive, Design Science Research, pain-points
I. I NTRODUCTION In the current landscape of automotive products, software has become an increasingly important distinguishing factor driving business success or failure [1]. With increased competition from new entrants into markets offering innovative software-based solutions, traditional Original Equipment Manufacturers (OEM) and their suppliers need to find ways to compete. In order to promote effective, efficient, safe, and secure software development the AUTOSAR Classical and AUTOSAR Adaptive Platform (AP) aim to create an open industry standard for automotive industry E/E architecture [2]. The first platform version for traditional real-time embedded systems development was released in 2005 (Classical) and the first version for service oriented architectures in 2017 (Adaptive). We have good understanding of the technical implications of The authors would like to thank TRATON R&D AB, Software Center, and VINNOVA. This study was partially funded by Software Center, an initiative of Chalmers, University of Gothenburg, 17 companies, and two universities.
4th Erika Mayer TRATON R&D AB Extra Consulting Södertälje, Sweden [email protected]
the Adaptive framework from the descriptions in the specifications, but the organizational implications in development organizations is less understood. This study aims to investigate the AP from an industry perspective. We want to know what happens in an organization when a standardized architecture framework that is specified to meet a general set of requirements is introduced in a local development context. Our investigation is based around the notion of pain-points. Inspired by Chattopadhyay et al. [3], we define the pain-points associated with AP development as; Developer-experienced difficulties (cognitive, technical, or organizational) that emerge when applying the AUTOSAR Adaptive architectural framework within safety-critical, large-scale automotive product development. In this study, pain-points refer to recurring and structurally rooted difficulties rather than incidental or individual frustrations. We associate pain-point emergence with increase of two different classes of complexity. The two classes are; 1) system internal code complexity (e.g., due to code complexity increase from local adaption of the general framework), or 2) system external complexity (e.g., due to workarounds needed in vendor provided tooling to accommodate local process requirements) [4]. However, due to the tight coupling of local processes, ways of working, vendor supplied software, and the AP specification itself, root causes of pain-points are obfuscated and not easily pinpointed in the local context. Thus, we wanted to investigate locally emergent phenomenon, but in the local context it’s not clearly observable how the phenomenon occurs. To alleviate this, we conducted a Design Science Research project together with an industrial partner. Industry data was collected from TRATON R&D AB, a European development organization that supplies original equipment manufacturers (OEMs) with hardware and software solutions. There, we developed a minimal AP-stack as a driver for experimental evaluation of the AP design specifications. We first collected qualitative data from a series of workshops to find a classification taxonomy of pain-points. We then build a minimal (prototype) AP based on the AUTOSAR specifications [2], evaluated our prototype, and had two developers perform experimental application development on the
platform. After the experimental development we collected further developer experience qualitative data from workshops to find root causes and possible technical debt. Pain-points negatively affect Developer Experience (DevEx), which in turn influences productivity and software quality [5]–[7]. Understanding their emergence is therefore critical for organizations developing software-intensive products. For this reason we conduct our study guided by the following research questions: • RQ1: What are the possible pain-points related to system development on an AUTOSAR Adaptive platform? • RQ2: Are the reasons for the presence of these painpoints inherent in the complexities introduced by the architecture proposed by AUTOSAR, and if so, what are the root causes? • RQ3: What possible negative impacts are likely to arise from these pain-points and complexities? This paper contributes 1) a taxonomy of developer painpoints in AUTOSAR Adaptive, 2) a diagnostic minimal stack to isolate specification- from implementation-induced complexity, and 3) an analysis of specification-inherent versus contextual pain-points and their organizational implications. The rest of this paper is structured as follows. Section II introduces the main concepts and structure of the AUTOSAR Adaptive platform and related work in the area. In Section III, we present the methodology of the study, and Section IV summarizes our results. We discuss the results and validity of our study in Section V. Finally, Section VI concludes the paper. II. BACKGROUND AND R ELATED W ORK The AUTOSAR Adaptive Platform [2] is an industry standard developed within the AUTOSAR consortium to address the increasing complexity of software in modern vehicles. While the AUTOSAR Classic Platform has long been used in embedded, real-time control applications (e.g., engine control units) [1], the Adaptive Platform was introduced to support new classes of applications such as advanced driver assistance systems (ADAS), autonomous driving, and connected services [2]. These applications demand significantly higher computational power, dynamic software updates, and communication with off-board cloud services. The main driver for the creation of the AUTOSAR platforms (Classical and Adaptive) has been the distributed development of software systems where OEMs integrate software and hardware from TIER1, TIER2, and TIER3 level suppliers [1]. To reduce cost of parts it was important to establish a standard where suppliers could re-use software developed for one OEM when starting new development projects targeting another OEM. However, the complexity introduced by changes to architecture in this context is hard to measure due to this ”black-box” situation in the integrated solution (i.e., on complete vehicle level) [8]. The Adaptive Platform differs fundamentally from Classic in its target environment and programming model [2]. It is
Fig. 1. Simplified visualization of adaptive applications running on ARA and the layers below.
designed for high-performance computing units (HPCs) running general-purpose operating systems such as Linux, QNX, or POSIX-compliant RTOSes [1]. Applications are developed in C++ and deployed as processes rather than statically configured tasks [2]. This enables dynamic deployment, service discovery, and update-over-the-air scenarios, which are central to current and future vehicle software architectures. Applications running on the AP are developed as one or several Software Clusters (SWCs) that run as separate processes on the Runtime for Adaptive Applications (ARA) (see Figure 1) [9]. For example, an application may compare set_speed and current_speed and emit a warning Event. Such applications depend on multiple services and subscriptions, introducing dependency and communication complexity. Key architectural elements of ARA as described in [9] include: Service-Oriented Communication (SoC) Management: Applications interact using service discovery and communication mechanisms, typically over SOME/IP (recommended by AUTOSAR [9]) or DDS bindings (see Figure 2). This design allows applications to be distributed across ECUs or integrated with external cloud services, but also require specification in AUTOSAR XML (ARXML) files that can be long and intricate to traverse. The ARXML files are normally generated from tooling. Execution Management handles application lifecycle, while Platform Services provide APIs for logging, diagnostics, and persistent storage. Safety and security considerations introduce additional constraints and trade-offs in the Adaptive architecture [9]. By providing these standardized interfaces and runtime services, the Adaptive Platform aims to decouple application development from underlying hardware and supplier implementations [2]. A. Related Work There are specific investigations relating to the AUTOSAR Adaptive specifications. For example, Menard et al. investigated determinism in the Adaptive Platform [10]. They identified three possible sources of non-determinism in the
Fig. 2. Client–server communication. Illustrated with SOME/IP since this is recommended by Autosar. Note that it is not necessarily the case that the Client SWC and Server SWC runs on the same Hardware. Here depicted so to simplify the illustration.
platform specification: 1) The suggested SWC programming model is to base them on threads; 2) the undefined order of processing for incoming messages to a SWC; and 3) the lack of a formal requirement to achieve point-to-point inorder messaging, likely due to the fact that the duration of message transfer cannot be guaranteed. The first source of nondeterminism could be considered solved by the deterministic client specification [10]. However, these requirements have been removed in later releases of the Adaptive Platform specifications (see e.g., [11]). It’s clear that special considerations will need to be taken when determinism is crucial. Another example is Bhat et al. who designed a framework for the faulttolerant execution of applications on the AP [12] and found some gaps in the AP 18.10 standard. Some authors have investigated co-operability of AUTOSAR Adaptive and other platforms or standards. For example, Hong & Moon propose an architecture for interoperability between the Robotic Operating System 2 (ROS2) and the Adaptive Platform to bridge the gap between autonomous drive experimentation—often carried out on ROS2—and industrial practice in the automotive industry [13]. Helmy et al. implemented an integration of the Service Oriented Vehicle Diagnostics (SOVD) with AP [14]. They found that this simplifies the implementation of HPC diagnostics. Related to the complexity from communication dependencies between services and applications over SOME/IP, Durisic et al. introduce a measure for coupling and cohesion complexity in automotive systems that aligns with a hierarchical and sub-contractor-based development methodology. They found that change management processes based on dependency analysis are crucial in the automotive systems domain [8]. This relates to our context because of the way AP SWCs and Applications communicate and the high degree of dependencies that need to be specified in the ARXML-files. Although related, there is no comprehensive work that answers our questions regarding the impact of introducing AUTOSAR Adaptive in a local context, leaving us confident of our study’s novelty.
Fig. 3. Showing influences on emergent pain-points in a software development context. For illustration simplicity these have been separated. However, in the local context the distinction became blurred and where one influencing factor ended and another began became hard to pinpoint.
Fig. 4. Showing the steps employed in our study process to extract a taxonomy from local pain-points, assessing the root causes of pain-point domains, and likely negative impacts from using AUTOSAR Adaptive in a development organization.
III. M ETHODOLOGY In order to investigate the origins and consequences of pain-points (see Section I for a definition) experienced by developers using a software platform based on the AP, we conduct a Design Science Research (DSR) study embedded in an industrial context [15]. We largely follow the steps described in [16], building a prototype (minimal for our experiments) of the AP in order to isolate the influence of other factors’ on identified pain-points. Figure 3 shows a depiction of factors that all affect the emergence of painpoints and who’s influence are hard to distinguish in the local context via observation alone. DSR is appropriate for this work, as it supports the creation and evaluation of artifacts (our minimal AP) that contribute both to practical problem-solving and theoretical understanding. Figure 4 shows the three-step process applied in this study. A. Industrial Context Description TRATON R&D AB supplies hardware and software systems to OEMs within the heavy vehicle segment owned by the TRATON Group. Traditionally, the company has historically developed in-house software, including real-time (RT) operating systems (OS), but recently introduced electric control units (ECU) with higher performance. Of these new high
performance ECU (HPC), some have been introduced running in-house developed platforms, and some use a supplied software platform based on AUTOSAR Adaptive. Approximately 30 teams work with AUTOSAR Adaptive related design, development, and testing. The teams are often organized per application domain (often called ”Vehicle Function” internally), and have end-to-end responsibility for their respective functionality. There are also supporting teams, such as a platform team that ensures integration of the vendor supplied platform and provides additional needed platform functionality that is too locally specific to be implemented by the vendor. Another supporting function is the modeling team that provides ARXML modeling for applications and generates service provider skeletons and client proxy implementations for new applications. There are also product managers, architects, system-level testers, and coordination support for teams. A typical development sequence for vehicle functions starts with the team understanding the requirements through stakeholder discussions. After this the platform is checked to see if there is need for any additions to the services/signals/IO. After this a model can be created and the first versions of the applications can be generated with the vendor-supplied tooling. After this, the team can implement the business logic using C++, test in simulation, on hardware rigs, or in a vehicle. This iteration persists until the desired vehicle behavior is achieved. After this, the vehicle function can be scheduled for release. 1) Problem Identification and Motivation: Through an indepth workshop series at TRATON R&D AB, we identified significant pain-points in feature development on a Tier-1supplied AUTOSAR Adaptive platform. This step was used to collect data for RQ1 and to drive the following steps in the design science process. We conducted workshops with eight software practitioners, where pain-points were collected. Also, a mapping of the precise development steps of an Adaptive Application from developers’ perspectives was constructed. The hand-offs and dependencies between teams were mapped, and the painpoints were connected to the different development steps. We also conducted an initial workshop to develop a reference mapping of workflows based on leader perceptions and the steps described in the development process documentation. The workshops’ participants and outcomes were; 1) three senior leaders and managers (project manager, product manager, line manager) mapped the reference journey based on the organization’s prescribed processes, 2) two junior feature developers mapped their journey and pain-points, 3) two senior feature developers mapped their journey and pain-points, 4) two platform developers mapped their journey and pain-points in supporting feature development, and 5) two architects were used as a reference group, adding missing parts in the complete journey that was constructed based on the input from the developers. These subjects were chosen to cover the development steps from the perspectives of all different types of roles involved
and to minimize bias from experience. For example, a major pain-point for a junior developer might not seem problematic for a senior developer, and a junior developer might not posses enough understanding to realize a global pain-point that a senior developer can point out. Through this series of initial workshops, we gathered a rich collection of data on the state of development grounded in the industry context. During our analysis of this data, pain-points were extracted and a taxonomy was defined.The results from the workshop are presented in Section IV-C1. 2) Objectives of the Solution: To disentangle the factors influencing the emergence pain-points, our objective was to construct a minimal, independently implemented AUTOSAR Adaptive platform. This artifact served as a diagnostic instrument, enabling controlled reproduction of problematic scenarios and isolating the effects of; 1) Tier-1 implementation, including deviations, extensions, or omissions, and 2) internal development processes, including architectural decisions and tooling assumptions. Since the possible influences were not distinguishable through observation of the local context alone, due to the entangled nature of the influences, this platform could reset the developers perspectives of what was local, vendor, and AUTOSAR specification specific. The artifact was designed to support reproducible experimentation on a representative target platform (i.e., it is designed to run on a POSIX OS). Experiments were run on Ubuntu Linux PCs. This research-design choice had two reasons; 1) the process of running our platform on the actual target HPC hardware would have required the platform to conform to local tooling requirements which would have entangled the prototype in local processes–leading to the reemergence of a confounding factor we wanted to isolate, 2) this allowed for fast experiment-cycles together with the developers. 3) Artifact Design and Development: We developed a lightweight AUTOSAR Adaptive platform by selectively implementing core platform services according to the AUTOSAR Adaptive Platform Specification R24-11 [9]1 . The implementation minimizes third-party dependencies and allows detailed instrumentation. Core platform Functional Clusters (FCs) are described in [9], and Figure 5 shows an overview of FCs that were (partially) implemented in the experimental platform. Communication Management handles the previously mentioned service-oriented communication (often over SOME/IP). Execution Management handles the application life cycle. Diagnostic Management provides diagnostic capabilities, often based on Unified Diagnostic Specification (UDS). Persistency Management provides persistent storage capabilities. Platform Health Management provides interfaces for the Execution Management to monitor and re-start applications in the event of failure. Log and Trace provides interfaces for logging. The core defines a set of common data types used in multiple functional clusters [22]. The Intrusion Detection System Manager 1 Available on: https://github.com/SriAbir/minimal-autosar-adaptive
5) Evaluation: We applied a multi-step evaluation strategy, including: Conformance analysis: A systematic comparison of the implemented stack against the AUTOSAR Adaptive standard requirements. We continuously developed runnable applications that used the implemented functional clusters, and confirmed their behavior with the AUTOSAR specifications. Completeness analysis: One vehicle function candidate was chosen for evaluation. The researchers implemented the application to assess the completeness of the stack (the minimal stack needed to be sufficiently large to accommodate the applications). This can be compared with the practice of static evaluation described in [30]. The vehicle function was chosen in consultation with a senior architect as small (meaning no extensive business logic), but representative of the general working of many vehicle functions as it had the characteristics of multiple dependencies both vehicle internally and externally as depicted in Figure 7. Fig. 5. Showing implemented foundational FCs from the AUTOSAR Adaptive platform specifications. Note that the minimal version of ara::diag was added after the static evaluation.
[23], Network Management [24], Time synchronization [25], Cryptography [26], Raw Data Stream [27], and Firewall [28] clusters were not implemented in the minimal stack. To allow for implementation in the allotted time for our research, some simplifications had to be made. Another reason for simplification was to avoid implementation details that might reveal confidential material. For these reasons; 1) our platform does not use the ARXML style of modeling specifications [29]. Instead, simplified JSON-based manifests and service descriptions were used to simplify the development, 2) No code generation tools were implemented. Instead, different types of templates were provided for the developers to use, replacing Service Proxy and Service Skeleton generation from a Service Interface Definition [1], and 3) selective implementation of the bare minimum for developing and running functional requirements of vehicle functions made us choose the functional clusters of ARA, as depicted in Figure 5. The selection of functional clusters to implement was initially conducted by two of the authors after close consultation of the general AP Platform Design specification [9] and iterated by consulting a development team. Final selection was not done until the Completeness Analysis in the Evaluation step in Section III-A5. 4) Demonstration: The artifact was deployed on Linux Ubuntu as it is a representative POSIX-based operating system, and continuously demonstrated via small applications running on the platform as functionality was added. Although small and simple, these applications had similar behavior as real Adaptive Applications running on the original AUTOSAR platform used by the OEMs supplied by TRATON R&D AB.
Developer familiarization: Two developers reimplemented two existing vehicle functions on the minimal platform to become familiar with its workings. The participating developers had engineering degrees, between 5–11 years of software development experience, and between 3–4 years of AUTOSAR-related experience. Developer feedback: Developers provided detailed comments on the platform and their experiences. In addition to this feedback, a workshop was held to discuss their experiences. The workshop was recorded and transcribed. This session was facilitated as a focus group in a workshop setting. As focus groups are a well-established method in software engineering research to elicit and prioritize practitioner perspectives in a structured group format [31]. This method allowed us to elicit and organize the developers’ insights and perspectives gained from using the minimal platform. The workshop transcript was thematically analyzed following Braun and Clarke’s coding approach [17]. Resulting in a set of workshop themes. Root cause analysis: Mapping observed pain-points to their probable origins (standard vs. supplier vs. internal practices) was performed using the 5-Why’s method, and these discussions were utilized in the thematic analysis to identify the root causes for the workshop themes. The evaluation results provided insight into how the structure and assumptions of the AUTOSAR Adaptive specification manifest in practice and whether specific categories of issues are systemic, implementation-induced, or organizationally situated. The systemic category contained painpoints that the developers could link directly to the insights they gained regarding how the AP is specified. Pain-points in the implementation-induced category were judged to be more closely associated with how the vendor implemented the AUTOSAR requirements. Finally, the organizationally situated pain-points were due to local practices, processes, or teamorganization.
IV. R ESULTS A. Developer pain-points (RQ1) The first workshop series identified eleven main potential developer pain-points related to AP development work and its surrounding toolchain, while adhering to local processes. By analyzing developer-supplied digital Post-It notes and workshop transcripts, our taxonomy was constructed from these pain-points. Platform and Architecture: Developers highlighted architectural rigidity and limited observability as core sources of difficulty. Strong coupling to supplier-provided frameworks or infrastructure would limit flexibility and slow down iteration. Poor system performance, e.g., for logging, would lead to inefficient trouble-shooting. Vendor supplied platforms could potentially lead to reduced visibility into runtime behavior, which would also hamper efficient development work. This domain reflects the technical boundary conditions that shape developers’ control over their work. Knowledge and Information Flow: Fragmented documentation and knowledge management practices can lead to the repeated rediscovery of solutions. Information is often stored in isolated repositories or transmitted through informal networks, making it difficult to establish a shared understanding of the intended use of the platform. Unclear or inconsistent product requirements were also mentioned as a possible contributing factor to uncertainty about purpose and verification criteria. This would result in an increase in testing time. This domain emphasizes the cognitive overhead caused by the lack or inaccessibility of organizational knowledge. Process and Workflow: Developers described repetitive manual steps, such as flashing, testing, and integration, that were only partially automated as possible pain-points. Unclear mandatory procedures and inconsistent process ownership created uncertainty about how to progress the work and who was responsible for approvals. A fragile release chain was also considered problematic, with long rebuild times and limited transparency across the CI/CD stages as a possible result. These issues point to the absence of smooth and predictable workflows for feature integration and validation. Tools and Infrastructure: If the surrounding tool landscape was fragmented and difficult to access specifically for highperformance computing environments lacking a standardized toolchain or consistent access management would lead to developer experienced pain-points. This would create waittime for permissions or licenses and encouraged the emergence of locally developed tools and scripts that would further increase divergence. Potential observability gaps, such as missing telemetry, would compound the sense of infrastructural fragility. Collaboration and Coordination: Cross-organizational communication was cited as a possible source of friction. Differences in processes, terminology, and tool usage between teams and brands would hamper coordination. Unclear ownership of interfaces and requirements would potentially add
Fig. 6. Taxonomy of pain-points from the initial workshop series.
to misalignment, causing redundant work and late integration problems. This domain captures the socio-technical coordination cost introduced by distributed development. Work Execution and Scope Management: Developers reported difficulties maintaining focus due to fragmented workdays, frequent meetings, and multi-branch maintenance as potential pain-points. In addition, if many features were scoped too broadly, reducing opportunities for incremental testing and early feedback this would also be troublesome. Although sometimes, scoping smaller features was not always possible. These factors would collectively slow down learning and increase the risk of rework. This domain reflects how local work practices and planning decisions interact with technical constraints to influence productivity. Summary: An overview of the taxonomy based on the data collected in the initial workshop series is shown in Figure 6. In order to verify the categories and ascertain the root cause of the pain-points, and how closely related they are to the AP specification, we evaluate our minimal AP stack in an effort to isolate the influence of AUTOSAR, vendor, and local complexities.
Fig. 7. Depiction of the major parts of the VehicleFunction application.
Fig. 8. Showing a comparison between the minimal and vendor supplied platforms. Lines of code in logarithmic scale to allow visualization in the same image. CC label is average cyclomatic complexity per function. Number of functions with CC > 20 shown for M=minimal and V=vendor. The logarithmic scale is used to visualize large NLOC differences. For example, the figure illustrates that while Execution Management exhibits inherent complexity in both stacks, vendor implementations accumulate substantially more complexity across multiple functional clusters.
B. Static evaluation Among the approximately 30 teams working on different aspects of AUTOSAR Adaptive development, a team responsible for a set of vehicle functions connected to the connectivityHPC was selected as a collaborator for static evaluation. The reasoning behind this choice was that one function for which the team was responsible had just the right size and complexity to constitute a realistic example of function development, while at the same time being reproducible on the new AUTOSAR Adaptive stack within a manageable time frame. The actual application chosen (called VehicleFunction in the rest of this paper) cannot be described in detail due to a Non-Disclosure Agreement with our industrial partner. Still, a sketch of the implementation is depicted in Figure 7. This application was selected as a representative for evaluation because it supports service discovery, request/response, publish/subscribe, timers, and state machines in multiple applications. It also validates error handling and degraded modes. Since the application is dependent on other implementations and external interfaces, certain simplifications were necessary. Dependencies were handled with stubs that had reduced behavior because the alternative would have been to replicate the entire system in question (a multi-year endeavor). The functional compliance between the simplified and original vehicle function was checked with the responsible development team and was deemed similar enough to ensure the completeness and conformance analysis of the platform. During the static evaluation, the researchers implemented the application to assess the stack before the developer evaluation. We found that two features of the minimal stack were missing, which we added before the developers’ evaluation; 1) Diagnostics: A small DoIP server (TCP/UDP according to ISO 13400) and ara::diag shim (Diagnostic Management [32]) that forwards a handful of UDS services, and 2) In vehicle communication: A small SocketCAN daemon that subscribes to VehicleFunction events and transmits the corresponding CAN frames.
To avoid revealing internal company implementation details, this addition was split into a public (available on GitHub) and a non-public part. It was also decided to keep stubs for cloud service communication, position information, and user interface connections non-public. We performed a lightweight static analysis of FCs in both the minimal and vendor-supplied AUTOSAR platforms, focusing on cyclomatic complexity (CC) and non-commented lines of code (NLOC). In the minimal platform, most FCs exhibited low average CC values (1–3) and no functions exceeding CC 20. The Execution Management FC had a higher average CC (≈ 12) with two high-complexity functions, consistent with the inherent coordination logic mandated by the AP specification. The vendor platform showed higher complexity across several FCs, with Communication, Diagnostics, Persistency, and Logging all containing functions above CC 20 and larger total NLOC. This indicates that while some complexity is inherent in the AP architecture (e.g., lifecycle management), a portion of the complexity experienced by developers originates from vendor-specific implementations and the requirements on automotive software requirements in general. See Figure 8 for details. C. Developer evaluation (RQ2, RQ3) The final evaluation of the minimal AUTOSAR Adaptive artifact was conducted during a workshop with two developers. The developers were chosen from teams separate from the team that supported the static evaluation. Before the workshop, the developers re-implemented two existing vehicle functions to familiarize themselves with the minimal platform. Both of these functions were representative of vehicle functions performing business logic and having multiple dependencies. One of the functions was similar to the VehicleFunction (see Figure 7) in structure and enabled users to interact with vehicle-internal functionality and vehicleexternal connected devices. In order to target a wider range
TABLE I R ESULTS FROM THE DEVELOPER WORKSHOP DURING THE EVALUATION PHASE OF OUR D ESIGN S CIENCE R ESEARCH PROJECT. Evaluation themes
Related to AP specification Yes
Vendor lock-in
Over-engineered service discovery and callbacks
Yes
Hard to learn mental model of lifecycle
Partly
Slow build / heavy code generation
Partly
Opaque ARXML and generated JSON configs
Yes
Unclear value of AUTOSAR (“what does it bring?”)
No (organizational)
Complexity added by internal modeling
No (local practice and vendor implementation) Yes
Over-specification under-guidance
and
Root cause analysis
Possible negative organizational impacts
Taxonomy reference
The Adaptive Platform is over-specified in some areas (e.g., determinism, service discovery) but vague in others, forcing vendorspecific interpretations and tooling dependencies (e.g., AMSR-SDK). SOME/IP-based service discovery and timing constraints create multiple callbacks and timers. Complexity stems from enforcing determinism and runtime flexibility simultaneously. The AUTOSAR app lifecycle (startup, shutdown, execution management) is complex and poorly documented, making it difficult for new developers to build a coherent mental model. The platform rebuilds serialization and deserialization code for all PGNs and services instead of modularizing generation. Tooling produces massive configuration files (e.g., 26k-line SOME/IP configs) that are unreadable and runtime-parsed even when known at compile time. Developers perceive AUTOSAR as a constraint rather than an enabler. The architectural rationale is poorly communicated relative to simpler OS-level service management. Internal modeling restrictions (e.g., application access requests, ARXML gating) add unnecessary complexity, blurring the line between vendor and AUTOSAR behavior.
Application code tightly coupled to vendorspecific libraries and service definitions; limited portability and increased maintenance cost .
1a , 1b
Unreadable asynchronous code scattered across applications; duplicated (cloned) callback and timer logic instead of a reusable library abstraction.
1a, 1b
High onboarding cost and defensive coding patterns; reliance on framework “magic” and avoidance of deeper refactoring.
1b, 2a, 2b
Long build times discourage experimentation and iteration; redundant code generation leads to inefficiency. Fragile configuration management, risk of runtime mismatches, and difficulty debugging service definition issues.
3c, 4a, 5a
Cultural and process debt; potential emergence of parallel “shadow stacks” to bypass the official platform.
3b, 5b, 6b
Persistent confusion about responsibility boundaries; added maintenance cost for local extensions.
2b, 3b, 5a, 5b
The AP specification attempts to cover all use cases but lacks developer-facing guidance, resulting in inconsistent interpretations and steep learning curves.
Documentation debt and fragmentation; need for internal simplifications or “teaching stacks” like the minimal platform.
1a, 1b, 2b
of functionality types, the other function that was chosen had more of a supporting role in the system, creating an isolated local environment in the communicator-HPC to run early prototype testing of applications. Similar to static evaluation, the exact functions of production-grade vehicles could not be recreated. However, the developers assessed that their experience familiarizing themselves with the experimental platform was sufficient for them to compare it with working on the existing platform. As they worked, the developers documented their experiences developing on the prototype platform in a journal . At the end of the familiarization period, they were asked to summarize their experiences and relate them to the pain-points in a workshop setting. 1) Workshop results: The group distinguishes between problems intrinsic to AUTOSAR Adaptive (service discovery, determinism, ARXML heaviness) and problems that emerge from vendor or local adaptations (tooling lock-in, model restrictions). A recurring meta-theme is that complexity has shifted from integration to comprehension: developers must either reverse-engineer vendor behavior or re-implement minimal abstractions to regain control. The main findings of the
1a, 3b
workshop are shown in Table I. The developers were asked to relay their experiences comparing their work with the minimal prototype to their experience with the currently used platform. The results are shown in Table II. V. D ISCUSSION Our findings show that many of the perceived pain-points in working with the AUTOSAR Adaptive Platform (AP) do not stem from the specification alone but from the interaction between the standard, supplier implementations, and local organizational practices. The complexity of the AP is thus both architectural and epistemic: it emerges from how knowledge about the system is distributed and mediated through tools, models, and specifications. The minimal stack was not intended as a production alternative nor as a complete AUTOSAR implementation. Its purpose was diagnostic: to isolate specification-mandated architectural mechanisms (e.g., lifecycle management, service discovery) from vendor-specific extensions and local tooling constraints. By simplifying modeling (e.g., replacing ARXML with JSON) and removing SDK dependencies, we intentionally reduced
TABLE II S HOWING THE DIRECT QUOTES FROM DEVELOPERS WHEN COMPARING THE PROTOTYPE PLATFORM WITH THE CURRENT IN - USE PLATFORM . Current Platform ”Hard to learn for new users.” ”Slower build.” ”More control over app details.” ”Easier to work with when you get familiar.” ”Feels overengineered. The whole process of discovering a service involves setting up multiple callbacks and timers, etc” ”Heavily dependent on ARXML files that are very hard for humans to read.” ”Generated files (JSON-files containing service info) are massive.” ”The model generates serialization code automatically”
accidental complexity to observe which difficulties persisted. Those that remained are strong candidates for specificationinherent complexity. A. RQ1: Developer pain-points The workshops revealed that developers experience the current platform as rigid, opaque, and slow to iterate on. While the Adaptive Platform aims to provide abstraction and safety through standardization, developers instead encounter high coupling to vendor-specific implementations and large generated artifacts (e.g., ARXML, SOME/IP JSONs). As a result, everyday tasks, such as configuring communication or debugging runtime behavior, become disproportionately effortful. These findings mirror observations in previous studies on AUTOSAR complexity and coupling [8]. However, it was clear from our results that some pain-points are inherent in the AP specification from AUTOSAR and would likely always persist. For example, developers reported uncertainty regarding when shutdown hooks are guaranteed to execute and how restart semantics interact with persistent state. This uncertainty led to defensive patterns such as redundant state validation and additional error-guarding logic, increasing code complexity. In practice, a simple client-server interaction required multiple asynchronous callbacks, timers, and state checks, even when the communication topology was static. This scaffolding often overshadowed business logic and was frequently reimplemented across applications. B. RQ2: Root causes Through the comparative evaluation of the minimal AUTOSAR stack, developers were able to distinguish which problems originate in the specification itself (presented in Table I. The key insight is that the AP specification attempts to cover a wide set of use cases but provides little developerfacing guidance on how to realize them. This is aligned with our static analysis results, where only Execution Management is inherently complex in the minimal platform, whereas the vendor platform accumulates additional complexity across several FCs. The under-specification leads to divergent vendor interpretations—particularly around service discovery and execution management—which in turn propagate to OEM-level complexity. Our result show that developers must navigate
Prototype Platform ”Easier to learn for new users.” ”Faster build.” ”Hides some important details.” ”Not sure it is gonna be easier to cope with difficulties you normally face with AUTOSAR and C++ projects.” ”Goes to the point. Allows the developer to focus on the core logic instead of boilerplate.” ”Service definitions and data types are defined in headers.” ”vsomeip/local.json is quite minimal. Of course this is a local example, but it contains all the information needed for service discovery” ”Currently, serialization must be implemented manually; this is a problem as it needs to be done carefully.”
a “stack of interpretations,” where the boundary between standard and implementation is blurred. However, it is unclear how a general specification could be achieved without similar effects. Importantly, not all identified pain-points are specific to AUTOSAR Adaptive. We distinguish between three causes: 1) specification-inherent issues (e.g., service discovery callbacks, lifecycle management complexity, ARXML-heavy configuration), 2) vendor-induced complexity (e.g., tooling lock-in, generated artifact size, SDK coupling), and 3) generic large-scale software issues (e.g., fragmented documentation, coordination overhead). Our contribution is not to claim that AUTOSAR uniquely causes all observed difficulties, but to demonstrate which difficulties are amplified or structurally shaped by specific architectural choices in the Adaptive Platform. C. RQ3: Organizational implications Several of the pain-points identified have a negative organizational impact. The reliance on vendor-specific tooling and generated artifacts introduces lock-in and hinders flexibility. The extensive callback logic and service-discovery scaffolding required to achieve determinism in SOME/IPbased communication incurs hidden maintenance costs. In addition, the limited transparency of lifecycle management encourages defensive coding and reduces changeability. These forms of architectural debt need to be actively managed to avoid negative organizational implications. D. Reflections on specification versus implementation The experimental minimal platform provided a unique lens for isolating the role of the AUTOSAR specification itself. Developers appreciated the simplicity of the minimal stack and the clarity it provided for understanding how applications start, stop, and communicate. This suggests that the complexity of the specification could be mitigated through pedagogical tools or “teaching stacks” that make life-cycle behavior explicit. Such artifacts could help organizations build shared mental models of the platform without relying solely on vendor black boxes. However, even though the minimal stack ”goes to the point” as one developer put it, it’s not clear that this sense of ease will
persist in a full-scale platform. Specification details will likely be obscured as the platform grows, and minimize the positive effects experienced by the developers. Building large-scale embedded software systems with many dependent software clusters is an essentially complex endeavor [33] and there will be trade-offs between the benefits and downsides of using a centrally specified software platform.
their relative weight may differ across organizations or different AUTOSAR Adaptive implementations. However, the results should generally hold across similar contexts. We tried to mitigate threats to external validity by including developers with a broad range of experience in both the workshop series (RQ1) and prototype evaluation (RQ2/3).
E. Implications for industrial practice
The goal of this study was to investigate the pain-points developers experience with AUTOSAR and whether they originate from the platform, its implementation, or its usage. We were interested in collecting pain-points in a local context, followed by tracing their sources and possible root causes to the AP architecture. We did this by isolating the analysis from the effects of local tooling, implementations, and practices via an experimental (minimal) AP implementation that was evaluated by developers from the local context. Developing an application on the prototype platform enabled the developers to compare their experiences from day-to-day work with a more idealized AP-setting. Our findings are that the specification of the AP may lead to; 1) vendor lock-in, that systems developed on the platform may suffer from over-engineered service discovery and callbacks, 2) have a hard to learn mental model of application life-cycle, 3) suffer from slow builds and heavy code generation, 4) need large and hard to read configuration files, and 5) reliance on requirement specifications that are over-specified while lending too little guidance. The conclusions from our DSR study are that there are complexities introduced by the AUTOSAR specifications. The main contributors are the service discovery mechanisms for managing software component dependencies. However, it is also clear from the study that large-scale embedded software development is by no means trivial. Complexities are an emergent property of the distributed nature of the products being developed. To some extent, the impact can be mitigated by education and tooling, but introducing AP technologies will require developer-time spent on building understanding and mental models for application life-cycles before development can become efficient and effective. The Adaptive Platform introduces essential complexity through architectural mechanisms required for distributed, service-oriented vehicle systems. However, our findings suggest that specification under-guidance combined with vendor interpretation amplifies this complexity beyond what is strictly necessary. In future work, we aim to extend this study with comparisons of competing frameworks such as ROS2 [13] and Eclipse S-CORE [34] to provide further illumination of the complexities inherent in the AUTOSAR Adaptive specifications. We also plan to extend the data collection with quantitative data in order to investigate performance-related findings from this study.
The results indicate that the successful adoption of the AUTOSAR Adaptive Platform depends not only on conformance to the standard but also on transparency in its interpretation. Organizations should therefore; 1) ask for clearer documentation and diagnostics from suppliers to bridge the gap between standard and implementation, 2) establish internal competence-building initiatives using simplified and instrumented stacks, and 3) treat configuration and model management as first-class development concerns rather than toolchain artifacts. In this way, industry actors can take advantage of the benefits of standardization while easing the effects of the essential complexity of large scale embedded system development by not adding accidental complexity [33]. F. Validity Considerations The validity of this study is influenced by both methodological and contextual factors. We discuss construct, internal, and external aspects in turn. Construct validity: To ensure that the collected data accurately reflect developer experience with the AUTOSAR Adaptive Platform (AP), we triangulated multiple sources: mapping of development-steps, workshop discussions, and hands-on experimentation on a minimal AP stack. Pain points were elicited using open-ended prompts and iteratively constructed in group settings to reduce researcher interpretation bias. However, since the notion of a “pain-point” is partly subjective, results may still depend on participants’ interpretation within their organizational setting. Internal validity: Pain-point identification was conducted collaboratively between two of the authors. The taxonomy was individually developed but checked by the other authors of the paper. Linking the taxonomy domains to specific root causes was done collaboratively by the workshop participants (facilitated by two of the authors) to minimize individual bias. The design-science artifact served as a control mechanism to separate the effects of the specification from those of implementation. Nonetheless, the presence of residual confounding factors remains possible since the experimental stack does not implement the full AUTOSAR standard, and simplifications may have affected the experienced comparison between the two platforms. External validity: The study was conducted within one industrial group and involves a limited number of developers who are familiar with a single vendor’s implementation. While the identified pain-point domains in the taxonomy are likely transferable to similar large-scale embedded software contexts,
VI. C ONCLUSIONS
R EFERENCES [1] Miroslaw Staron, Automotive Software Architectures. Springer, 2021.
[2] AUTOSAR Consortium. Online Resource. Accessed 2025-11-24. https://www.autosar.org/search?tx solr%5Bfilter%5D%5B0%5D= category%3AR24-11&tx solr%5Bq%5D=. [3] Chattopadhyay, S., Prasad, I., Henley, A. Z., Sarma, A., & Barik, T. (2020, April). What’s wrong with computational notebooks? Pain points, needs, and design opportunities. In Proceedings of the 2020 CHI conference on human factors in computing systems (pp. 1-12). [4] Antinyan, V. (2020). Revealing the complexity of automotive software. Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 1525–1528. https://doi.org/10.1145/3368089.3417038 [5] Palomino, P., Fonseca, M., Souza, J., Toda, A., Pereira, R. L., Cordeiro, T., & Demerval, D. (2025). Enhancing Developers Experience (DevEx) for Successful Design System Implementation. International Journal of Human–Computer Interaction, 41(1), 807-819. [6] Fagerholm, F., & Munch, J. (2012). Developer experience: Concept and definition. 2012 International Conference on Software and System Process (ICSSP), 73–77. https://doi.org/10.1109/ICSSP.2012.6225984. [7] Graziotin, D., Fagerholm, F., Wang, X., & Abrahamsson, P. (2017). What happens when software developers are (un)happy. Journal of Systems and Software (2018), 140, 32-47. [8] Durisic, D., Nilsson, M., Staron, M., & Hansson, J. (2013). Measuring the impact of changes to the complexity and coupling properties of automotive software systems. Journal of Systems and Software, 86(5), 1275-1293. [9] AUTOSAR, www.autosar.org. Explanation of Adaptive Platform Design R24-11, 2024. [10] Menard, C., Goens, A., Lohstroh, M., & Castrillon, J. (2019). Achieving determinism in adaptive AUTOSAR. arXiv preprint arXiv:1912.01367. [11] AUTOSAR, www.autosar.org. Specification of Execution Management R24-11, 2024. [12] Bhat, A., Samii, S., & Rajkumar, R. R. (2020, August). Fault-tolerance support for adaptive AUTOSAR platforms using SOME/IP. In 2020 IEEE 26th International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA) (pp. 1-6). IEEE. [13] Hong, D., & Moon, C. (2024). Autonomous driving system architecture with integrated ROS2 and adaptive AUTOSAR. Electronics, 13(7), 1303. [14] Helmy, M., Hekal, M., & Emad, Y. (2024, May). Revolutionizing Vehicle Diagnostics by New SOVD Incorporation and Development in Adaptive AUTOSAR. In 2024 14th International Conference on Electrical Engineering (ICEENG) (pp. 193-195). IEEE. [15] Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. MIS Quarterly, 28(1), 75–105. [16] Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, 24(3), 45–77. [17] Braun, V., & Clarke, V. (2019). Reflecting on reflexive thematic analysis. Qualitative research in sport, exercise and health, 11(4), 589-597. [18] AUTOSAR, www.autosar.org. Specification of Communication Management R24-11, 2024. [19] AUTOSAR, www.autosar.org. Specification of Persistency R24-11, 2024 [20] AUTOSAR, www.autosar.org. Specification of Platform Health Management R24-11, 2024. [21] AUTOSAR, www.autosar.org. Specification of Log and Trace R24-11, 2024. [22] AUTOSAR, www.autosar.org. Specification of Adaptive Health Core R24-11, 2024. [23] AUTOSAR, www.autosar.org. Specification of Intrusion Detection System Manager for Adaptive Platform R24-11, 2024. [24] AUTOSAR, www.autosar.org. Specification of Network Management R24-11, 2024. [25] AUTOSAR, www.autosar.org. Specification of Time Synchronization R24-11, 2024. [26] AUTOSAR, www.autosar.org. Specification of Cryptography R24-11, 2024. [27] AUTOSAR, www.autosar.org. Specification of Raw Data Stream R2411, 2024. [28] AUTOSAR, www.autosar.org. Specification of Firewall for the Adaptive Platform R24-11, 2024. [29] AUTOSAR, www.autosar.org. Methodology for Adaptive Platform R2411, 2024. [30] Gorschek, T., Wohlin, C., Garre, P., & Larsson, S. (2006). A Model for Technology Transfer in Practice. IEEE Software, 23(6), 88–95.
[31] Kontio, J., Lehtola, L., & Bragge, J. (2004). Using the focus group method in software engineering: Obtaining practitioner and user experiences. Proceedings of ICSE, 271–280. https://doi.org/10.1109/MS.2006. 147. [32] AUTOSAR, www.autosar.org. Specification of Diagnostics R24-11, 2024. [33] Antinyan, V., Sandberg, A., & Staron, M. (2019). A Pragmatic View on Code Complexity Management. Computer, 52(2), 14–22. [34] Eclipse Foundation AISBL. Online Resource. Accessed 2025-11-24. https://eclipse.dev/score/ https://eclipse.dev/score/