Search code examples
unit-testingtestingintegration-testingautosarautomotive

How to test an AUTOSAR project?


I am very new to AUTOSAR. Currently I am on a search to find different types of testing used in AUTOSAR projects. My aim is to gain knowledge on AUTOSAR testing area. Following are the questions which I am looking to get answered. 1. What are the different areas of AUTOSAR that can be tested? 2. How to test AUTOSAR projects practically? 3. What are the tools used for AUTOSAR based project's testing? 4. How to start learning testing of AUTOSAR project? 5. Find resources available for learning AUTOSAR testing.


Solution

  • Testing AUTOSAR projects is not much different than testing non-AUTOSAR projects. Even the tools can be mostly the same (if you tested with CANoe the communication and ECU logic using UDS or XCP protocol is same as before). You might need some new tools (or at least current version of tools) which are able to extract information out of ARXML files automatically.

    Different areas like:

    • SWCs can be tested e.g. with Unit Tests on their RTE interfaces very easily. RunnableEntities are defined and the events that trigger them, and the ports they access. (e.g. AEUnit, Dassault AUTOSAR Builder ASim, ..)

    • Integration Testing in the interfaces, including the use of e.g. the DET. e.g. missing callouts or wrong call order, parameters, states etc.

    • RPT (Rapid ProtoTyping) scenarios, which can be used for HIL/SIL testing

    • Overriding inputs/outputs temporarily with XCP or UDS Read/Write and IoControl (ShortTermAdjustments) on DIDs (DataIdentifiers) e.g. override your algo output (warning on/off) and test your control components (e.g. switch on, function on, algo warning on --> signal XXX = WARN_1 if blinker not set, or XXX = WARN_2 if blinker set, or XXX = WARN_OFF if mainswitch is OFF no matter what algo says. Or if error relevant to function exists, function state = MALFUNCTION and XXX = WARN_OFF.

    • Logging/Tracing using DLT (Diagnostic Log&Trace) logic/functional trace/log output, timing measurement output

    • ARTI for timing measurement

    • normal monitors and the reporting of DemEvents and the chain of CombinedEvents/DTCs and FunctionInihibitions and the handling by the functions (e.g. DemEventA -> FUNCA malfunction, FUNCB normal, because FUNCB not affected by rootcause reported by DemEventA)

    Regarding specific AUTOSAR tests, a lot of checks are now also done by certain AUTOSAR tools to actually also validate the ARXML files for certain constraints defined by the AUTOSAR meta-model, in order for data exchange between different tools (e.g. Authoring Tool which creates SWCD ARXMLs and the Configuration Tools that use the ARXML to configure the system (BSW & RTE)).

    One thing that makes lots if trouble usually is the usage of DBC files to configure the AUTOSAR ComStack, since DBC files are not able to express a lot of things, you could actually define by ARXNL files, or usually create even the wrong thing (due to limitations in DBC files).

    Also, lots of problems actually arise due to misunderstanding / ignoring of AUTOSAR concepts and features, and programming around AUTOSAR. Some are even related to concepts/requirements of OEMs also thinking in pre-AUTOSAR era.