2

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.

Lijin
  • 141
  • 1
  • 12

3 Answers3

4

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.

kesselhaus
  • 1,241
  • 8
  • 9
  • 1
    I always avoid telling beginners that AUTOSAR is an Architecture. I've found that if instead I tell them it is a Systems Architecture then they start asking about how is it different from plain Architecture and as a result they better understand the undelying concept. – Adam Horvath May 02 '20 at 18:02
  • 1
    Well, I guess we have more or less the same problem .. trying to spread knowledge and interest on AUTOSAR in the developement teams? I try to get them to understand the possibilities and features AUTOSAR has for SW and how to get these balconies away you mostly needed before AUTOSAR. But I also try to get our system level guys to understand vehicle level systems and subsystems and how to use AUTOSAR there too. It's a tedious thing to convince them where I feel like Don Quichote....sometimes I see some lights at the tunnel by some people. – kesselhaus May 03 '20 at 03:19
3

I created list with awesome-automotive resources, where main part is dedicated for Autosar and way of working in automotive projects.

On this list you could find numbers of publications and method of testing Autosar systems like: timing analysis, integration tests, functional tests and so on. Generally methos of testing and verification is described by ASPICE methodology and in safety project in ISO 26262.

Lets check this list and if you will have further qustion feel fry to ask.

marcin214
  • 61
  • 6
  • Nice work on https://github.com/Marcin214/awesome-automotive many crucial topics are covered. – np2807 Mar 17 '21 at 12:57
0

There's no clear answer to your questions.

AUTOSAR is only a methodology coming with standardised interfaces that members can adhere to; it enables development of software parts that work together nicely. How a concrete AUTOSAR project gets tested depends type of product being developed and what your AUTOSAR toolchain and hardware stack providers support.

If I was you, I would try to draw a detailed "V" model of the project. In what steps your project is decomposed and in what integration steps (the right half of "V" model) those steps are tested. Once you have this drawing/mapping, start Google-ing the phases and put the word AUTOSAR after them.

You will find that most of these testing techniques existed before AUTOSAR came to existance. However, a state-of-the-art software tool should be able to inspect your AUTOSAR model and support you in test-design or execution efforts.

Keep in mind that there's no "definitive" AUTOSAR modelling; some projects create detailed models others just surficially do it. Ask engineers how "well-modelled" your project is, before making a test-plan or test-tool decision. AUTOSAR is the buzzword that makes a developer/tester tool cost n-times more but their usefullness decreases dramatically if a project does not follow the standard to a very detailed level.

Adam Horvath
  • 1,249
  • 1
  • 10
  • 25