AUTOSAR & modern software trends

The mission of AUTOSAR is to be a global partner-driven standardization effort in the automotive software industry. We develop and establish a standardized software framework and an open E/E (electrical/electronic) system architecture for intelligent mobility.

The objective of AUTOSAR is to enable the industry to manage complexities within vehicle networks. This includes how to integrate ECUs by specifying how they and the basic software should behave to achieve compatibility independent of the vendor or OEM involved. Another aspect of the work is the methodology, i.e. an abstract way to describe the vehicle architecture and functions and enabling machine-readable exchangeable formats to facilitate collaboration.

I’m fairly convinced the speed of innovation would be slower, more complex, and costly without the standardization framework and methodologies – independent of vehicle architecture. To my personal knowledge, 1-4 high-performance computers (HPCs) will be typical in a vehicle with 2-5 zones going forward. The sensor/actuator ECUs are “below” the zones where Autosar Classic will still run and the communication within the Zones will remain mainly signal-based. We have standardized AUTOSAR Adaptive to natively support service-oriented communication between HPCs.

Zone ECUs will need to translate between the signal and service domain. To achieve this AUTOSAR Classic and Adaptive support Some/IP and DDS (Data Distribution Service). This means that you can implement a software-defined vehicle solution based on the AUTOSAR communication infrastructure. Another big challenge in the future will be how to manage decoupling hardware lifecycles from software lifecycles similar like Android and iOS do this in the mobile industry. Additionally, looking into the future there will be a lot of data that exists in the E/E architecture that needs to be communicated to the cloud.

All these trends mean that the classical vehicle world focusing on safety and cyber security and the modern SW industry world focusing on Data-driven and Microservice based Interfaces will have to work together. AUTOSAR is therefore collaborating closely with COVESA to interface with the cloud. Combined with our knowledge of the E/E architecture, we can bridge the gap between the data coming from the vehicle and the cloud. Before cross consortia collaborations started everything was quite isolated in automotive but more interfaces due to the software-defined vehicle require more coordination between organizations. If you want to reach “code to road” within one day, then working in isolation does not work any longer. A good maturity and interfaces between standards are mandatory.

A software-defined vehicle includes several modern practices including how to integrate cloud, but also CI/CD and DevOps. All of which imply, of course, improvements and changes in AUTOSAR as a standard and as an organization too. We are doing a lot of alignment together with other organizations to make it possible to implement these principles. No organization or company will be able to solve the challenges of SDV by themself and part of AUTOSAR’s role, as a standardization organization, is to collaborate with other organization to make the Software Defined Vehicle a reality and increase productivity in the automotive industry.

If we compare this to other industries, automotive is behind in modern software practices. From an industry perspective, it is a very interesting question of how to unlock possible gains to produce code more efficiently. We can’t apply all principles and throw the classic principles of software development in automotive overboard, as with cars there are lives at stake, but we can still learn a lot including:

• A more timely feedback loop: The ability to measure your data in the field while your vehicle is active, play it back to your development team, and then you adjust the algorithm and reapply the algorithm in the field.
• In general support of a more iterative development based on continuous integration, test, and delivery. These activities are executed today but not entirely formalized, not well automated, and I would say not so tool-supported yet.

Something I observe is that the concepts that AUTOSAR has introduced are not implemented entirely in tools. A specific example is that tools are directly editing ARXML files, for example – but such files are intended for the machine-readable exchange between two departments/companies.

I think the main improvements on software development in automotive we still have in front of us. From AUTOSAR’s perspective, the whole world and all the tool suppliers are invited to embrace their own creativity to abstract from the defined exchange formats to increase usability and use the exchange format for their intended purpose – Exchange machine readable information.

*RemotiveLabs blog article E2E protection implementable with only a few json lines gains quite a few Google searches.

I’m not familiar with RemotiveLabs tooling at this point but with the E2E protection, I assume it is on the OEM side the frustration comes. If you have a violation in the end-to-end protection and you’re still in an early integration phase, you don’t know the originator of the problem. You have two sides, one providing the data and one side consuming it. If the consuming side says nope, an issue is raised, and you never know which side interpreted it wrongly. It can also be a network timing issue. It is similarly tricky to put first-time security-based cryptography on the bus level.

From a logistic point of view at an OEM, it is difficult because you need to request additional signals from your networking team. You need to request the CRC (Cyclic Redundancy Test) and you need to request the counter value. Those have to be approved and integrated into the communication matrix and this has been logistically delivered to both ECU suppliers as requirement and also integrated accordingly. With re-use of ECUs due to different variants and ECUs in different lifecycle states this also can sometimes cause challenges of integration.