AUTOSAR Classic Platform, how standard is a standard?
AUTOSAR has been evolving and expanding to cover a wide range of Automotive Use-cases since it began in 2003. OEM’s adoption increased from version 4.0 onwards, when the standard achieved a comprehensive level of support for the needs of OEM’s at that time, as I’ve discussed previously.
The AUTOSAR standard is now mature in both its processes and documented requirements and specifications for many well proven features, resulting in highly predictable behavior from software stacks that implement the standard, and interoperability across an E/E architecture with multiple different AUTOSAR vendors utilized.
Extensions and customization
It is the nature of both standards and OEM’s that whilst most use cases are covered in a timely manner, however, there is often need for each OEM to either customize or extend the standard to support the specifics of their system design. AUTOSAR allows for this via a CDD (Complex Device Driver) which can be connected as needed to different parts of the AUTOSAR stack, usually the OEM and the AUTOSAR implementer will aim to standardize any advanced functionality into a later version of the standard if it improves the standard.
Early in development of the standard it was common to defensively include expected use-cases, however these were not always adopted by any OEM, and thus frequently the requirements were untested, and might need debugging to implement. Recently there has been more attention paid to only including use cases that are needed in an up coming implementation or application.
Experienced AUTOSAR vendors are used to this customization, and commonly have available the necessary extensions for multiple OEM’s. Many also omitting less used, or unused elements of AUTOSAR which may later be removed from the standard, if no OEM needs them.
Area’s which commonly have specific implementations and customizations include Network Management to wake and sleep ECU’s, Diagnostics, Gateways, custom Cyber Security elements and integrations, specific communication requirements relating to Functional Safety and Cyber security, and more. These enhancements can include custom configuration, complex device drivers (CDD), enhancements to the stack and/or integrations enabling expected functions for each OEM.
Capital VSTAR supports a wide range of OEM use cases, built up over many years of supporting OEM’s around the world, often via Tier 1 suppliers in multiple segments, with portings on the leading micro-controllers and increasing micro-processors.
Program risk reduction
When beginning any project a pragmatic approach to risk reduction is needed, there is always pressure on cost, and timing, and a minimum of contingency is highly desirable. Selecting components, technology and partners there can be a preference to utilize known elements from previous projects, however that can constrain projects and prevent them from benefiting from better technology supporting more efficient development, higher quality results, which may then benefit subsequent programs. Using a basic software that is highly conformant to the well proven AUTOSAR standard, combined with a high quality, developer focused software tooling can reduce program risk, rather than adding to it.
While many OEM’s have used AUTOSAR 4.0 in production, few used 4.1, more again used 4.2, but many kept a 4.0 base for some time. OEM’s often defined elements to integrated into a known base, often in an E/E architecture that is predominantly of a single version. This enabled the commodity strategy for bought in ECU’s to continue as before, rather than aligning with the E/E architecture change points. Gradually OEM’s have moved towards planned regular updates to their E/E architecture technology level and have deployed versions of AUTOSAR aligned to these generations. Multiple OEM’s following both strategies, evolution or revolution, have looked to 4.3 as a generational big step with more complete Ethernet capabilities particularly for larger data elements and cyber security extensions.
Evolution or revolution
Domain type and other high compute ECU’s connected to an Ethernet backbone or domain network tending to be first to ‘upgrade’ where the approach is evolutionary, with less sophisticated commodity ECU’s still utilizing earlier versions which can maybe be accommodated on CAN with some careful network design rules. These complexities are a situation many involved in the E/E architecture development, network design, and integration seek to break away from, and get to a consistent deployed version across the vehicle. Where OEM’s are able to predict their technological and feature roadmaps, this can often be planned, but there is often a long history of late change due to competitive pressure to potentially disrupt this careful planning. The maturity of the AUTOSAR standard, and increasing ease of updating modules also making compatibility, where it is needed, between versions easier to achieve.
Experienced AUTOSAR vendors, such as Siemens, learn these patterns, and support the OEM extensions and enhancements, providing this experience to both the OEM’s and their Tier 1 suppliers. Capital VSTAR solutions are highly mature, and offer broad support for multiple OEM requirements, commonly on the Recommended or Approved lists of the OEM’s providing confidence of successful programs.
- On-demand Webinar: Overcome the challenges in electric vehicle embedded software development
