AUTOSAR and Automotive Testing System|Sasken

  Jan 19, 2021 2:21:18 PM

Testing of automotive components i.e., its verification and validation has come a long way in the history of Automotive component design and integration. Verification assesses if the intended component is integral to all the necessary conditions as per the proposed specification. Validation intends to see if all the external conditions of the system satisfy the end users and stakeholders utilizing the product.

With Automotive systems becoming more Electrical and Electronic (E/E) in nature, software plays a crucial role in system design. There are several levels of testing, including the ones arising from the software industry which have impacted the Automotive testing procedures. In that sense, testing still follows the traditional right-hand side of the Automotive V-cycle as per industry standards.

AUTOSAR, the Automotive Open System Architecture, became the standard accepted paradigm for E/E architectures in the Automotive industry because of the ease in acceptance of common standard artifacts among stakeholders. This quickened the pace of products introduced into the market underpinning custom development and testing needs at the controller, sensor/actuator, Electronic Control Unit, and Applications Software. Both the classic AUTOSAR approach, and newly introduced adaptive platforms have made controller abstraction, control unit abstraction, service abstraction and application modularity development and testing, more defined and process abiding. AUTOSAR also catered to most domains in the Automotive ecosystem which includes Body Controls, HMI (Infotainment and Telematics), ADAS/Highly Automated Driving (HAD) (Safety and Security), Powertrain (Conventional and EV) and Chassis/Braking.

Starting from the basic aspect of AUTOSAR, which is the Microcontroller Abstraction Layer (MCAL) in a classic model or the HAL in an adaptive system, the underlying hardware platform is abstracted with interfaces to the middleware or the ECU/DCU/VCU software. This predominantly involves testing of the generated atomic code blocks which is white box testing. Here at a granular level the testing of software syntax, semantics, and unit testing is done to find and fix basic levels of internal behaviors in units. The MISRA compliance and the C/C++ or other programming language is strictly tested to ensure compliance with necessary coding guidelines . This is usually undertaken by a junior level AUTOSAR testing team which ensures the Controller level of correctness is ensured in the process.

The next level of functional testing is of the ECU abstraction or adaptive middleware. This ensures that the black box is tested for the upper layer functionality of transport and network layers, including compliance to the interface levels of AUTOSAR and N-PDUs. The functionality of the AUTOSAR ECUs is tested as white box of underlying hardware with interfaces like AUTOSAR, or AUTOSAR standardized interfaces being tested. The various components of black box like Controller’s action to the inputs, response time, user interfaces, and performance of the underlying controllers are tested in full as an ECU component. The low-level software requirements are also verified for compliance with PIL testing.

At the top is the Services and Management layer which caters to the Basic Software at the bottom and the Application layer at the top. Testing involves ECU/DCU/VCU compliance to management of networks, memory, communication, OS, partitioning, and others and is equivalent to SIL Testing. This ensures your ECU is integration tested with applications and interchange of proper application-level parameters are accommodated and tested before Application testing. The Application-level testing of platform and non-platform applications ensure that the interchange of communication happens seamlessly between domains and other DCUs and VCUs. This also ensures security and safe information from non-critical applications. This level of testing is done on a SIL and high-level software compliance is therefore ensured. This can also be done in a virtualized test environment given the current virtual and remote digital testing needs.

Before the final vehicle and on-road testing is ensured, MIL, HIL and simulation testing is carried out to ensure all information exchange is properly conducted in the virtual vehicle. This is the highest system level compliance testing with interchange of information between system of systems (SoS) like VCU along with DCUs and ECUs. Environmental, regulatory, and other external conditions are also simulated before putting the whole SoS in the vehicle homologation of an AUTOSAR compliant SoS. This will be packaged along with value-added mechanical, electrical, and other composite ergonomics for complete build vehicle integration, homologation, and on-road testing for final vehicle infrastructure behind the scenes.

VCUs, DCUs, and ECUs are growing in complexity and utilized in various combinations, with high-powered processors, intensive packaging, automation, and AI/ML-based testing procedures in every level of testing. There is therefore a higher demand for AUTOSAR testing and criteria of the designs being tested. The safety and security standards are also gradually going out of context because of their modularization to atomic components and then adding them in series from bottom to top. This mimics the appearance of a tree-like structure meeting all tree-leaf level testing functionalities and compliance.

Find out more about our expertise providing AUTOSAR-based software testing, verification and validation.

Posted by:
Naresh Neelakantan
Naresh Neelakantan is a senior architect (System Software) and product engineering services white papers provider from Sasken technologies limited.

Want To Know More About This Topic?

You might also like