[PPT] - DATA CONSISTENCY TEST TOWARDS SYSTEMATIC REQUIREMENTS ELICITATION IN PowerPoint Presentation

SLIDE 1

DATA CONSISTENCY TEST

TOWARDS SYSTEMATIC REQUIREMENTS ELICITATION IN AUTOMOTIVE MULTI-CORE APPLICATIONS

ERTS 2020 Toulouse, 30.01.2020 Ralph Mader Vitesco Technologies GmbH Wolfgang Pree University of Salzburg and Chrona.com Public

SLIDE 2

DATA CONSISTENCY TEST – TOWARDS SYSTEMATIC REQUIREMENTS ELICITATION

1 MULTI CORE SOFTWARE FOR POWERTRAIN 2 WHAT IS DATA CONSISTENCY 3 IDENTIFICATION OF CONSISTENCY REQUIREMENTS 4 SUMMARY AND OUTLOOK

2

SLIDE 3

MULTI-CORE SOFTWARE FOR POWERTRAIN

WHERE IS MULTI-CORE IN USE?

3

Combustion Engine Transmission Control Domain Controller HV Inverter DC/DC Converter

SLIDE 4

MULTI-CORE SOFTWARE FOR POWERTRAIN

PROJECT VERSUS PLATFORM DEVELOPMENT

4

Platform of re-usable elements  Core independent

Function A Function B Function C Function D Function E Function F Function G Function H Function I Function J Function K Function L Function M Function N Function O Function P

Project A – 2 Core Micro Controller

Function A Function B Function C Function D Function E Function K

Project B – 4 Core Micro Controller

Function A Function B Function E Function F Function H Function I Function J Function K Function N Function O

Project N – 3 Core Micro Controller

Function C Function E Function F Function G Function H Function I Function J Function K

…

> Platform solution must be independent from core partitioning in project

SLIDE 5

MULTI-CORE SOFTWARE FOR POWERTRAIN

TYPES OF SOFTWARE USED

5

> Multi Core Layer is generated based on data protection needs in project

Legacy Engine Drivers (CDD) RTE OEM ASW - Non AUTOSAR OEM ASW - AUTOSAR 4.3.1 System Services Memory Stack Communication Stack IO HW abstraction OS Legacy IF

PowerSAR CDD‘s

Microcontroller Abstraction - Drivers Multicore Microcontroller IF’s Vitesco Technologies ASW - AUTOSAR 4.3.1 Vitesco Technologies ASW - Non AUTOSAR

Multi Core PDA Layer

SLIDE 6

DATA CONSISTENC TEST – TOWARDS SYSTEMATIC REQUIREMENTS ELICITATION

1 MULTI CORE SOFTWARE FOR POWERTRAIN 2 WHAT IS DATA CONSISTENCY 3 IDENTIFICATION OF CONSISTENCY REQUIREMENTS 4 SUMMARY AND OUTLOOK

6

SLIDE 7

WHAT IS DATA CONSISTENCY?

DATA CONSISTENCY = DATA STABILITY & DATA COHERENCY

7

> For proper functional behavior, both stability and coherency have to be ensured

Stability Coherency

SLIDE 8

MEANS TO ENSURE DATA CONSISTENCY

BUFFERING OR LOGICAL EXECUTION TIME (LET)

8

> Ensuring data consistency generates overhead > Below you find two means how to ensure data consistency in Multi-Core Systems Logical Execution Time (LET) Buffering of Data

Task R 1 R 2 R 3 R 2 R 3 R 2 R 3 Task individual buffer Global Data RAM R N R 4 R 5 R N R 4 R 5

Fill buffer Flush buffer

Task 1 Core 1

time time

Rp LET 01 LET 02 LET 01 LET 02 Rc Task 2 Core 0

Global Data RAM

Task LET 01 LET 02

SLIDE 9

DATA CONSISTENCY WITH MINIMAL OVERHEAD

SHORTCOMINGS OF REQUIREMENTS ELICITATION

9

> Ensuring data consistency should minimize the overhead > Functions are designed mostly by mechanical engineers > Design object reviews are used today for identifying consistency requirements > Quality of requirements is based on the multi-core background of the reviewers Status Quo > Missing Requirements could generate sporadic functional issues (sleeping issues) > Non-maintained Requirements could lead to miss data protection > Useless Requirements consume resources and add validation & maintenance effort Consequences

SLIDE 10

DATA CONSISTENCY TESTING – TOWARDS SYSTEMATIC REQUIREMENTS ELICITATION

1 MULTI CORE SOFTWARE FOR POWERTRAIN 2 WHAT IS DATA CONSISTENCY 3 IDENTIFICATION OF CONSISTENCY REQUIREMENTS 4 SUMMARY AND OUTLOOK

10

SLIDE 11

TIMING IS EVERYTHING ...

SAMPLE STABILITY VIOLATION

11

a b global variables a, b

milliseconds

SLIDE 12

TIMING IS EVERYTHING ...

SAMPLE STABILITY VIOLATION

12

98 a 3 b global variables a, b

Provider component (PRV) writes values to a, b 2 milliseconds

SLIDE 13

TIMING IS EVERYTHING ...

SAMPLE STABILITY VIOLATION

13

98 a 3 b global variables a, b

Provider component (PRV) writes values to a, b 3 milliseconds Module under Test (MUT) reads variables a, b as inputs

core 1 core 2 void f(void) { ... if (a > b) { ... ... // use a, b for calc. ... } } if (98 > 3)

SLIDE 14

TIMING IS EVERYTHING ...

SAMPLE STABILITY VIOLATION

14

98 a 3 b global variables a, b

Provider component (PRV) writes values to a, b 5 milliseconds Module under Test (MUT) reads variables a, b as inputs

core 1 core 2 void f(void) { ... if (a > b) { ... ... // use a, b for calc. ... } } if (98 > 3)

SLIDE 15

TIMING IS EVERYTHING ...

SAMPLE STABILITY VIOLATION

15

1 a 3 b global variables a, b

Provider component (PRV) writes values to a, b 8 milliseconds Module under Test (MUT) reads variables a, b as inputs

core 1 core 2 void f(void) { ... if (a > b) { ... ... // use a, b for calc. ... } } if (98 > 3)

SLIDE 16

TIMING IS EVERYTHING ...

SAMPLE STABILITY VIOLATION

16

1 a 3 b

global variables a, b

Provider component (PRV) writes values to a, b 9 milliseconds Module under Test (MUT) reads variables a, b as inputs

core 1 core 2 void f(void) { ... if (a > b) { ... ... // use a, b for calc. ... } } a= 1, b= 3 if (98 > 3)

SLIDE 17

All would have been fine if: > MUT would have executed a bit faster (eg, shorter waiting time for bus communication resource), or > PRV would have executed a bit slower (eg, longer interrupt by another task function on core 2) TIMING IS EVERYTHING ...

SAMPLE STABILITY VIOLATION

17

void f(void) { ... if (a > b) { ... ... // use a, b for calc. ... } } (98 > 3) a= 98, b= 3 void f(void) { ... if (a > b) { ... ... // use a, b for calc. ... } } if (98 > 3) a= 1, b= 3

we call this a Problematic Access Pattern (PAP)

SLIDE 18

> maximize occurrences of violations by manipulating execution times of code fragments to achieve ”bad” interleaving of MUT and PRV executions > PAP coverage (as many different PAPs as possible ) > filter by assessing the effect of certain PAPs on the outputs > basis for consistency testing: Validator simulator: a platform-aware Software-in- the-Loop (SiL) simulation > execution of application software is interleaved with simulation of a virtual platform model

BY VARYING THE EXECUTION TIMES OF TASK FUNCTIONS WITHIN WCET LIMITS

CORE CONCEPT: ADVERSARIAL TESTING

18

SLIDE 19

>a (typically a reduced) set of data protection requirements >documented exceptions with reproducible tests

ADEQUATE SET OF VARIABLES THAT NEED TO BE BUFFERED

RESULTS OF CONSISTENCY TESTING

19

SLIDE 20

SOLID FORMAL BASIS

 

. : . . . . | . . W Entry vVS vVS C v CS vVS C fat v pat     

* .

/ (arg min . );

P v PS

P P net 





 

. . vVS v CS 

Init CheckPRV

   

/ . . . . | . . t pEt vVS vVS C v CS vVS C fat v pat      

Final

 

* * *

. / ( ); max , . ;

M

P net t exec P pEt t P net      

*. M

P net t     

Wait4PRV

. .

min .

C v CS v VS C fat



 

      

: ; Entry resume

. : . , . min( . , ); W Exit C v CS C fat C fat t   

. : W During

FINITE STATE MACHINES > THUS, CONSISTENCY/COHERENCY TESTING CAN BE FORMALLY VERIFIED

SLIDE 21

TOOL USAGE

IMPROVES SOFTWARE QUALITY AND REDUCES RESOURCE CONSUMPTION

21

> batch mode as part of a daily build (continuous integration) > interactively with UI seamlessly integrated in Matlab/Simulink and Eclipse

SLIDE 22

DATA CONSISTENC TEST - TOWARDS SYSTEMATIC REQUIREMENT ELICITATION

1 MULTI CORE SOFTWARE FOR POWERTRAIN 2 WHAT IS DATA CONSISTENCY 3 IDENTIFICATION OF CONSISTENCY REQUIREMENTS 4 SUMMARY AND OUTLOOK

22

SLIDE 23

SUMMARY AND OUTLOOK

WHEN TO PERFORM THE CONSISTENCY TEST?

23

Consistency stress test will complement the SIL test as a formal way to prove data consistency

Functional Model Implementation model C-Code

(s-function in model)

≈ =

Result Result Result ACG

MIL Model in the Loop SIL Software In the Loop

Scaling

Functional Requirements

≈

Modeling Test cases Expected Values Model Coverage Code Coverage

C-Code

(compiled for µC- Target) Result

PIL Processor In the Loop

=

Consistency Stress Test Validator Configuration Producer Event DB Chrona Validator Validator Test Trace Runtime DB Configure Validator YPDAs Projects YPDAs Projects Project Archite ctures Test Result Summary

SLIDE 24

> Test is based on a formal method to identify consistency requirements > It works in context of a project > Extension to platform approach is possible by batch processing of different scenarios > Piloting Phase within Vitesco Technologies is started

SUMMARY AND OUTLOOK

24

SLIDE 25

QUESTIONS?

SLIDE 26

ANNEX

EXAMPLE AND CASE STUDY ENGINE CONTROL FUNCTION – FOR SELF STUDY

SLIDE 27