Real-time Ethernet Residual : A Model-Based Testing Approach for the Next-Generation In-Car Network Florian Bartols Till Steinbach Franz Korf Bettina Buth Thomas C. Schmidt florian.bartols@haw-hamburg.de October 10th, 2014 22nd International Conference on Real-Time Networks and Systems NET
Software and functions in modern cars Functions are implemented mostly in software today Utilization of software directly influences the development costs Testing in early development stages reduces these costs Distributed development makes early testing difficult 2 / 23
Complex In-Car Interconnections Front Chassis... Rear Chassis Engine Gearbox... Breakes Chassis Bus (FlexRay) Dashboard Engine Bus (High-Speed-CAN) Body Bus (Low-Speed-CAN) Central Gateway Radio/ Navi... CD/DVD Multimedia Bus (MOST) Door AC... Headlights On-Board Systems Doors (LIN) Lights (LIN) Off-Board Systems Diagnostics Bus (CAN / Ethernet) Service The complexity of current in-car interconnections is hardly manageable 3 / 23
Complex In-Car Interconnections Gearbox Engine Front Chassis Rear Chassis Rear Breakes Front Breakes Headlights Dashboard On-Board Systems RTEthernet Switch AC Radio/ Navi RTEthernet Backbone RTEthernet Switch Internet GPS Doors CD/DVD Off-Board Systems Service RT Ethernet for in-car interconnection reduces the complexity 3 / 23
Contribution Testing systems and applications in early development stages is important New applications will rely on RT Ethernet as communication technology Suitable methodology is needed to validate distributed applications RT Ethernet Residual enables early testing Combination of model-based testing principles to validate non-functional requirements 4 / 23
Agenda 1 2 3 Real-time Ethernet Residual 4 5 5 / 23
Model-based Testing Approach The automotive development process is model driven Models are utilized as specifications for Representing implementation details Modeling system requirements Test cases are systematically inherited from models Execution of cases on different test platforms MiL, SiL, PiL, HiL and Residual 6 / 23
Residual The remaining network is simulated from the viewpoint of the SUT SUT and simulator are coupled via the communication interface Behavior and network specific characteristics are realistically emulated The simulator pretends to be a physical system 7 / 23
RT Ethernet as In-Car Network Attributes of TTEthernet TTEthernet provides three different message classes Chassis TT 0 Cycle TT t TTE- Switch TTE- Switch RC 0 Headlight t TT 0 RC TT BE BE BE Cycle t Multimedia TT RC Time-Triggered Message Rate-Constrained Message 0 BE BE BE t BE Best-Effort Message Static designed routing for deterministic behavior Synchronized time base for time-triggered communication 8 / 23
Agenda 1 2 3 Real-time Ethernet Residual 4 5 9 / 23
Model-based Methodology Overview Models Require ments Test Case Generation T U Y T U Y 1s u1 = HL_OFF 1s y1 T = HL_OFF u1 = HL_OFF 1s U y1 = HL_OFF u1 = HL_OFF Y y1 = HL_OFF Test Cases Downl oad Test Case Execution Test Data Stimuli Reaction SUT Data SUT Requirements are modeled within suitable diagrams Test cases are inherited from the diagrams Test cases are executed on a suitable residual bus simulation platform 10 / 23
Modeling System Requirements UML-MARTE Classic UML is not sufficient for embedded Real-time Systems Utilization of UML-Profile Modeling and Analysis of Real-time Embedded Systems (MARTE) sd MessageProcessing <<TimedConstrained>> on = [MARTE_Library::TimedLibrary::idealClock] <<timedconstrained>> {(messagereceived - replysent) = (500,µs)} {(jitter(messagereceived - replysent)) (100,µs)} Dashboard-System @messagereceived setnewlightstatus(status) Headlight-Controller sendcurrentlightstatus(status) @replysent 11 / 23
Abstract Test Cases Definition Base Model u(t) System y(t) Extending the Model u(t) t1 Latency System t2 t3 Rate y(t) ATC FR = (T, U, Y ) Modeling specific values of inputs and outputs at specific points in time ATC NFR = (T, U, Y, L, R, L, R ) Extending with reply time (latency) & transmission rate (rate) 12 / 23
Abstract Test Cases Utilization Abstract representation of to be generated test data Modeling functional requirements with expected output Modeling non-functional requirements with expected timing constraints Utilization as simulation model to drive the simulator 13 / 23
Implementation of our Approach Requirements and Architecture Requirements TTEthernet compliant message transmission Support of timing analyzes Execution of the abstract test case model Abstract Test Case XML- Doc Ethernet Frames DPM UML-MARTE Models Configurator Residual Bus Simulator SUT 14 / 23
Agenda 1 2 3 Real-time Ethernet Residual 4 5 15 / 23
Overview of the physical system Headlight L Headlight R SuT Drive-bywire (W) Switch Switch Drive-bywire (SW) Camera Multimedia Display Multimedia Dashboard Lightcontrol Dashboard to be simulated by the residual bus simulator Light control dashboard transmits new light states Headlights reply each received light state and Periodically provide their current light state Light control dashboard presents the light state to the user 16 / 23
Validating the Headlight Controller Requirement Modelling with UML-MARTE sd MessageProcessing Dashboard-System <<TimedConstrained>> on = [MARTE_Library::TimedLibrary::idealClock] <<timedconstrained>> {(messagereceived - replysent) = (500,µs)} {(jitter(messagereceived - replysent)) (100,µs)} @messagereceived setnewlightstatus(status) sendcurrentlightstatus(status) Headlight-Controller @replysent Timing requirements of the reply message Latency: 500 µs Jitter: ± 50 µs 17 / 23
Validating the Headlight Controller Requirement Modelling with UML-MARTE sd TimedStateTransmission Headlight-Controller Repeat [ timedevent (5,ms)] <<TimedProcessing>> on = [MARTE_Library::TimedLibrary::idealClock] <<TimedConstrained>> on = [MARTE_Library::TimedLibrary::idealClock] <<timedconstrained>> {(sendstatus i - sendstatus i-1 ) = (5000,µs)} {(jitter(sendstatus i - sendstatus i-1 )) (10,µs)} updatecurrentlightstatus(status) Dashboard-System @ sentstatus i Timing requirements of the message transmission Rate: 5000 µs Jitter: ± 5 µs 18 / 23
Validating the Headlight Controller T 1 s 2 s 5 s 7 s 9 s 11 s U u 1 = HL_OFF u 1 = LED_0 u 1 = LED_100 u 1 = LED_50 u 1 = LED_101 u 1 = LED_75 Y y 1 = HL_OFF y 1 = LED_0 y 1 = LED_100 y 1 = LED_50 y 1 = LED_50 y 1 = LED_75 Y act y 1 = HL_OFF y 1 = HL_OFF y 1 = HL_OFF y 1 = HL_OFF y 1 = HL_OFF y 1 = HL_OFF L l 1(u 1, y 1) = 500 µs L j L1(l 1) 100 µs L act l 1(u 1, y 1) = 518 µs to 518 µs, MED = 518 µs, AVG = 518 µs R r 1(y 1) = 5000 µs R j R1(r 1) 10 µs R act r 1(y 1) = 4998 µs to 5002 µs, MED = 5000 µs, AVG = 5000 µs Functional requirements cannot be fulfilled Expected values are not located at the output Non-functional timing requirement are fulfilled Latency of the acknowledgement lay within the allowed range 19 / 23
Agenda 1 2 3 Real-time Ethernet Residual 4 5 20 / 23
Conclusion Residual bus simulator is directly connected with the SUT Message classes and a synchronization procedure are supported Non-functional timing requirements are modeled within UML-MARTE Abstract test case model models functional and non-functional test data Utilization of abstract test cases as simulation model Successful utilization for the validation of an RT Ethernet application 21 / 23
Outlook Investigate how AUTOSAR and EAST-ADL could co-exist with our approach Implement a RBS with a more suitable architecture without dual-port memory Analyze the real-time and performance aspects of the new architecture 22 / 23
Thank you for your attention Visit us at: https://core.informatik.haw-hamburg.de 23 / 23