Featured On-Demand Webinar: Accelerate Software Compliance With AI Watch Now >>
The AUTomotive Open System ARchitecture (AUTOSAR) comes from a development partnership among automotive entities. Founded in 2003, the group sought to establish standardized and open software architecture around automotive electronic control units (ECUs). It also covers semiconductors, too.
The AUTOSAR development partnership sought to enhance the effectiveness and availability of safety requirements, scalability, transferability, and sustainability throughout the product lifecycle. Though not inherently medical devices, certain aspects of automotive technology certainly fall under protective items. Product lines line airbags require technology that will accurately deploy them while systems like motor control require consistency.
More embedded electronics in automobiles also means lots of data collection, as well as data processing in real-time. Different aspects of AUTOSAR seek to address the needs of modern automotive electronics and software components.
There are two types of AUTOSAR platforms: Adaptive and Classic. Classic AUTOSAR platform does not offer the kind of flexibility and processing power that the Adaptive methodology can. The growing complexity of automotive technology requires easier reactions and quicker responses.
However, the two platforms are not rivals, but teammates. Both serve different purposes in the automotive design and development ecosystem.
|AUTOSAR Classic Platform||AUTOSAR Adaptive Platform|
|Ideal for a single or multicore architecture and deeply embedded ECUs.||Ideal for newer ECUs and intended to run on top of HPC architectures to better take advantage of them.|
|Utilizes signal-based communication with BUS networks like LIN or CAN.||Uses service-based communication with Ethernet.|
|Defines an operating system (OS).||Defines execution context, as well as an operating system interface such as PSE51.|
|Static nature with low flexibility.||Provides “planned dynamics” during application deployment with flexible integration.|
|Deadlines are more pressing due to realtime processing.||Soft realtime requirement.|
|Examples include braking systems and engine control.||Examples include sensor fusion data processing and over-the-air updates (OTA updates).|
It’s a coding standard for C++ version 14 (ISO/IEC 14882:2014) and an artifact or one of the outcomes in defining the Adaptive AUTOSAR platform which provides interface specification for APIs and services.. This section of AUTOSAR coding guidelines originally just updated MISRA C++ 2008 – an outmoded coding standard. However, MISRA and AUTOSAR announced their merger in 2019, in support of updating to C++17. Which has become the default language for many modern AUTOSAR electronic solutions.
In fact, these guidelines are so robust and optimized, they can be applied to any industry that requires embedded programming in C++.
AUTOSAR C++14 has 342 rules to help give the user a clear understanding and guidance on coding requirements. AUTOSAR C++14 coding rules are classified according to obligation level.
However, a deviation from an AUTOSAR standard, rule, or guideline can be permitted. To avoid abusing the deviation concept by developers deviating at will, sign-offs for every deviation must be included. In addition, the rules are also classified as whether they can be enforced automatically by static analysis tools.
The use of C++14 in collaboration with the AUTOSAR C++14 guidelines provides developers with the ability to use superior compilers and improved access to enhanced testing, verification, and analysis tools. It allows new development methods to be used like continuous integration/continuous delivery (CI/CD) which can detect errors sooner in the software development life cycle.
“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.
Finding the right development tools to ensure software quality is a matter of trial and error. But that doesn’t mean you need to experiment with unproven tools or strategies. Luckily, the mountain of benefits of automation in regard to testing and compliance are distinct.
Finding issues earlier can only make things easier for everyone involved in software development. From software architecture and application software to diagnostics and validation, Parasoft solutions have it all in mind.
Implement AUTOSAR C++14 compliance in delivering safe, secure, and reliable code for everlasting benefits that impact your product success and longevity while reducing labor costs and time to market.
Deploy Parasoft’s solutions to conduct static analysis of code no matter which development environment you work in.
When it comes to AUTOSAR C++14 compliance, there are several highly beneficial practices. Here’s a list of some of the methods to consider.
The open and standard software architecture features in many modern automotive software electronic systems today are being used for autonomous driving and connectivity.
Take Advanced Driver-Assistance Systems (ADAS) like LIDAR that help cars sense when they’re in danger of hitting an object. Parking assist with automated driving also relies heavily on the AUTOSAR software architecture.
These are just two use cases, but with AUTOSAR adaptive platform connectivity and internet of things (IoT) devices in vehicles becoming more common and more robust, being able to measure data in order to adapt is crucial.
Parasoft’s analytics dashboard with automated AUTOSAR compliance reporting makes it easy to provide the proof required for certification.
A great thing about proposing AUTOSAR C++14 compliance is that it can be introduced and used at any software development phase of a project. Better yet is that it’s effective even if a project or your ECU software is incomplete and partially coded.
The biggest challenge with introducing AUTOSAR C++14 compliance is that a large amount of code can produce a large number of warnings. Therefore, the focus when integrating AUTOSAR C++14 compliance into a project should be on getting the team productive as soon as possible. This will minimize opportunities for the team to get overwhelmed by static analysis warnings.
As achieving AUTOSAR C++14 compliance becomes part of each developer’s daily routine, they’ll be able to analyze results more quickly and fix bugs more efficiently.
The maturity of the product under development also matters as it impacts the way AUTOSAR C++14 compliance can be incorporated. The adoption life cycle management works as described below.
The Parasoft code analysis AUTOSAR solution, Parasoft C/C++test, detects complex AUTOSAR C++14 compliance runtime-like problems in an AUTOSAR runtime environment early in the development stage—without the need to execute costly runtime tests. This streamlines development processes in a way that benefits everyone.
C/C++test analyzes the execution paths through the code and finds AUTOSAR C++14 compliance issues like null pointer dereferencing, division by zero, and memory leaks. It also searches for security vulnerabilities such as arithmetic on a pointer operand, buffer overflows, unreachable code, and cstdlib system function
Results from C/C++test’s AUTOSAR C++14 compliance results can be viewed in Parasoft’s dynamic reporting dashboard, enabling automated post-processing and advanced reporting strategies using historical data.
It’s easy to see AUTOSAR C++14 compliance results across builds over time. This is true even when working with large codebases and legacy code where visibility into the code is typically challenging. You can quickly focus on the quality of the newly-added code.
With widgets that automatically track AUTOSAR C++14 compliance, users get a dynamic view into the compliance process, and can easily produce automatic reports for code audits and certification goals.
Basic software modules (BSW) is a collection of software files that provide certain coded functionality that runs on an ECU. These standardized software modules may support communication, I/O, memory, and more.
For example, some AUTOSAR basic software modules perform tasks like Bus mirroring, diagnostics, and even cryptography to secure data.
The three layers are:
Electronic controller unit (ECU) specific modules and generic modules are included across three sublayers including the services layer, ECU abstraction layer, and microcontroller abstraction layer (MCAL).
RTE stands for “runtime environment” and functions as a kind of middle ground between the application layer and other layers. It operates the intra-ECU and interlayer communication.
As part of the three layers, the ECU abstraction layer above the MCAL layer has hardware component drivers and components for interfaces. That means that its job is to ensure the above layer operates independently from the hardware on the ECU.
Formed in 2003, the group of OEMs and other invested parties include tons of big names like Volkswagen and Robert Bosch GmbH.
AUTOSAR C++14 does not provide any similar guidance on the process of achieving compliance, at least not directly. But given that AUTOSAR C++ guidelines are based on MISRA C++ 2008, it is reasonable to refer to the MISRA standard to look for guidance about the process of achieving compliance.
An adaptive AUTOSAR platform defines a platform for developing automotive control units that provide sophisticated functions like advanced driving assistance systems, media streaming, or software updates via the internet.
Static analysis is the process of examining source code without execution, usually for the purposes of finding bugs or evaluating code safety, security, and reliability.