Test-Driven Scenario Specification of Automotive Software Components - - PowerPoint PPT Presentation

test driven scenario specification of automotive software
SMART_READER_LITE
LIVE PREVIEW

Test-Driven Scenario Specification of Automotive Software Components - - PowerPoint PPT Presentation

Test-Driven Scenario Specification of Automotive Software Components Carsten Wiecher, Joel Greenyer, Jan Korte Carsten Wiecher 6 years job experience at Leopold Kostal GmbH & Co. KG as software engineer since 12/2018 research


slide-1
SLIDE 1

Test-Driven Scenario Specification of Automotive Software Components

Carsten Wiecher, Joel Greenyer, Jan Korte

slide-2
SLIDE 2

TDSS@MASE19 October 15, 2019

Carsten Wiecher

  • 6 years job experience at Leopold Kostal GmbH & Co. KG as software engineer
  • since 12/2018 research associate at IDiAL Institute - FH Dortmund
  • phd student at Paderborn University & FH Dortmund

2

carsten.wiecher@fh-dortmund.de

slide-3
SLIDE 3

TDSS@MASE19 October 15, 2019

3

Design Science Research

  • building and evaluating a solution-
  • assessing its actual impact in reality-

Research Context and Design

problem analysis artifact evaluation artifact construction interpretation

slide-4
SLIDE 4

TDSS@MASE19 October 15, 2019

Problem Description and Motivation for TDSS

complex automotive software systems

  • A. high contextual complexity
  • B. high dynamics in projects

costly development iterations high verification/validation effort How to support a natural and intuitive formalization of requirements with the goal to:

  • A. automatically analyze these requirements?

B.systematically work out test cases based on these requirements? reduce development costs by:

  • A. early detection of requirement inconsistencies and ambiguities

B.reusing test cases in later process steps

scenario b scenario a

4

slide-5
SLIDE 5

TDSS@MASE19 October 15, 2019

Example: Onboard Charger for electric vehicles

5

Req1: No temperature related derating of the available

  • utput power shall be commanded, if the coolant inlet

temperature sensor reads values between -40°C and 65°C. Req2: If the coolant inlet temperature sensor reads values between 65°C and 75°C, linear derating with 1/10 of maximal output power per 1°C shall be commanded. Req3: Power-down above 75°C coolant inlet temperature. Req4: Power-down if coolant inlet temperature increases more than 5°C within 5s. Req5: Power-down if PCB temperature increases more than 20°C within 3s.

slide-6
SLIDE 6

TDSS@MASE19 October 15, 2019

scenario specification

Background: Scenario Modeling Language for Kotlin (SMLK)

6

threads of behavior

  • scenarios-

scenario program scenario a scenario b scenario c scenario a scenario b scenario c

Behavioral Programming: http://www.wisdom.weizmann.ac.il/~bprogram/ Live Sequence Charts: http://wiki.weizmann.ac.il/playgo/index.php/Live_sequence_charts Scenario Modeling Language: http://scenariotools.org/scenario-modeling-language/

scenario(deratingComponent.startCycle){
 if (deratingComponent.coolantTemp in -40..65)
 request(deratingComponent.setDeratingFactor(1.0))} Req1: No temperature related derating of the available output power shall be commanded, if the coolant inlet temperature sensor reads values between -40°C and 65°C.

slide-7
SLIDE 7

TDSS@MASE19 October 15, 2019

scenario c scenario b scenario a

Background: Scenario Modeling Language for Kotlin (SMLK)

7

scenario program scenario a scenario b scenario c request wait-for forbid request(a) request(b) wait-for(c) sync point sync point scenario d interrupt request(c)

slide-8
SLIDE 8

TDSS@MASE19 October 15, 2019

Test-Driven Scenario Specification of Automotive Software Components (TDSS)

8

Test Scenario Program Scenario Program request external events (e.g. temperature values) wait for scenario program events (e.g. expected derating factor) request, wait-for, forbid, interrupt specific events to model the behavior of the software component

slide-9
SLIDE 9

TDSS@MASE19 October 15, 2019

Test-Driven Scenario Specification of Automotive Software Components (TDSS)

9

Derating Test Scenario Program

request(temperature values) request(start cycle) waitFor(derating value) waitFor(end cycle) @Test
 fun `At 66°C the DeratingFactor is 0-9`() = runTest(deratingScenarioProgram){
 deratingIOSequence(Triple(66, 66, 0.9))} cycleScenario(deratingComponent){
 if (deratingComponent.coolantTemp in 65..75)
 request(deratingComponent.setDeratingFactor( (75.0-deratingComponent.coolantTemp)/10))}

slide-10
SLIDE 10

TDSS@MASE19 October 15, 2019

write a new test case execute this new test case extend or adapt specification execute all test cases clean up

Test-Driven Scenario Specification of Automotive Software Components (TDSS)

10

test failed tests failed all tests passed all req. modeled

  • req. remain to

be modeled test passed

slide-11
SLIDE 11

TDSS@MASE19 October 15, 2019

cycleScenario(deratingComponent){
 if (deratingComponent.coolantTemp in 65..75)
 request(deratingComponent.setDeratingFactor( (75.0-deratingComponent.coolantTemp)/10)) }

scenario b scenario a

Test-Driven Scenario Specification of Automotive Software Components (TDSS)

11

slide-12
SLIDE 12

TDSS@MASE19 October 15, 2019

TDSS - Evaluation

12

Software Requirements Analysis Software Architectural Design Software Detailed Design and Unit Construction Software Unit Verification Software Integration and Integration Test Software Qualification Test

Req1: No temperature related derating of the available

  • utput power shall be commanded, if the coolant inlet

temperature sensor reads values between -40°C and 65°C. Req4: Power-down if coolant inlet temperature increases more than 5°C within 5s.

slide-13
SLIDE 13

TDSS@MASE19 October 15, 2019

TDSS - Summary

13

Test-Driven Scenario Specification of Automotive Software Components:

  • new approach for the test-driven, scenario-based requirements specification
  • combines agile practices with formal specification and analysis
  • SMLK is suited to formalize functional requirements in an intuitive way
  • immediately testing of requirements:
  • feeling of control to the requirements specification and analysis phase
  • high confidence of correctness when the final implementation is tested:

tests vs. requirements vs. implementation

slide-14
SLIDE 14

TDSS@MASE19 October 15, 2019

Outlook

14

  • 1. Combinatorial Test Design
  • 2. Transition to Design
  • 3. Transition to Validation
  • 4. Evaluation: based on DSR framework,

systematically assessing the impact in reality

Test Scenario Specification Scenario Specification XIL

experimental setting

study subjects artifacts test group control group researcher (planning) constructs, methods, models experimental results researcher (conducting)

1 2 3 4

1. 1. 1.