Software Module Test for an Electronic Steering Lock

(1)

Software Module Test for an Electronic Steering

Lock

Wolfgang Beer, Dr. Peter Jüttner, Daniel Simonis (external subcontractor), Siemens VDO Automotive AG

Siemensstr. 12

93055 Regensburg, Germany Tel.: +49(0)941-790-6601

email: [email protected] © Siemens VDO Automotive AG 2005

(2)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Overview n

Project ELV

n

SW Module Test (Theory)

n

Implementation in ELV Project

n

Lessons learned

(3)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Project ELV (1)

nELV = Elektronische Lenkradverriegelung

nBasic functions: Lock , unlock (with cryptology)

nAdditional functions: Diagnosis, Learning, Operation

Modes, Communication, Memory for Data, Errors, and Measured Values.

n8Bit Micro, 24k ROM

nEmbedded SW development with cross compiler

nObject-oriented approach for design

nImplementation in C with mapping rules OO -> C nLayer model in SW (OS, Application)

(4)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Project ELV (2) nTeam n6 Team members

n2 dedicated SW testers, one mainly for SW Module test,

one for SW Integration and SW Validation

nProject start 2003 nProject end 2005

(5)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Project ELV (3) Term. 30z Ignition Switch Term. 30 Term. 31 Power-supply Power-supply NEC 78K0 NEC 78K0 Oscillator Oscillator separate Supply separate Supply Serial Interface Serial Interface M IN µC IN µC Q1 Q3 K1 K2 "Lock" "Unlock" Sensor for Lock Sensor for Unlock

(6)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Project ELV (4) nVehicle Integration

ELV Master Bidirectional_{communication} ELV line

Engine Control CAN

(7)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary

SW Module Test (Theory) (1)

SW Requirements

SW Design

Coding SW Module Test

SW Integration Test SW Validation test against test against test against

(8)

n

Test of single SW modules in isolation

n

Test of Classes (implemented in C), i.e. test of C

functions

n

Black-Box and White Box test strategies

n

Test against SW design (Black-Box)

n

Test against structure (White-Box)

n

Test completeness criteria 100% coverage of

module requirements and 100% statement

coverage

n

Black-Box and White Box tests in combination

n

Introduced in SV C BC SW development

(9)

Benefits

n

Early error detection (errors become cheaper)

n

Less bugs in following development steps

n

Improvement of reuse

(10)

Drawbacks and prejudices in Embedded SW

development

n

SW modules are not always executable in target

or PC environment

n

Test harnesses are needed

n

Runtime behavior cannot be tested on PC

n

Test with non target compiler on PC

n

Bugs in target compiler and on HW are not found

n

Behavior of SW with different compilers is different

n

Bugs are found anyway in later test phases

(11)

BUT

n

Testing SW is the goal, not testing compiler or HW

n

There is no guarantee that later tests find the bugs

n

Later bug fix is more expensive

n

No code coverage in later test phases -> risk of

(12)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Implementation (1)

Test tool Rational Test Realtime (RTR)

supports

n

Automatic test harness generation

n

Automatic pass/fail decision

n

Structured tests

n

Test case generation

n

Comprehensive Test protocol and report

n

Black-Box and White Box Test in parallel

(13)

Source Code Test Harness

Generator PTU File

Manual Rework PTU File executable Test Harness Test Harness "Compiler" C Code C Compiler & Linker

(14)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Implementation (3) 0 Failed Tests 6 Passed Tests 6 Tests Passed Status NOT INFORMED Service Type Construct_Add_Evaluate_Clear Service Name … 00H NIL NIL Passed node[0].prev 00413028H &list ? Passed list prev 00413028H &list ? Passed list next 0 0 0 Passed k Obtained Value Expected Value Init Value Status Variable 100.0% (14/14) Statement blocks 100.0% (25/25) Functions and exits

100.0% (12/12) Functions

(15)

(16)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Lessons Learned (1)

nIntroduction in Test Process and Test Tool took 2 weeks nTotal Effort for Module Test ~ 6 MM (~ = coding effort) n1-100 test cases for a single C function

n15 000 test cases in total

nHigh effort in stub development

nMany bugs found, most of coding bugs

nBugs in target compiler found (by using a PC compiler) nSplit in responsibility (1 SW designer/coder, 1 SW module

tester) reduced timing problems

nImplicit design review

(17)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Lessons Learned (2)

nSW should be designed in ANSI C nHW abstraction is useful

nProper SW architecture and detailed design required (e.g.

encapsulation, lean interfaces, no global variables)

nSimple control structures in algorithms reduce effort nTest automation is essential

n100% code coverage is necessary but not sufficient

nEach test phase has its focus (no "competition" between test

phases)

nIntegration test could also be done partly on PC

(18)

Overview Project ELV SW Module Test (Theory) Implementation Lessons learned Summary Summary

nBy SW module test most of the bugs and inconsistencies in design and implementation of the ELV SW could be found and fixed in an early development phase

nThe effort of module testing is acceptable if automated tests

using appropriate test tools (RTR) are used

nSuccessful bug fix can be checked automatically by

regression of automated tests

nThe separation between designer/coder and tester reduces

bottlenecks in the development phase especially in tight schedules