The main contributions in this chapter are a) the extension of the IP-XACT standard with timing extensions, b) the elaboration and definition of trans- formation rules from defined IP-XACT-timing-constraints to executable PSL formulas. Hereby, the transformation rules are compliant to the TADL2 se- mantic. The provided transformation rules could then be implemented by a PSL code generator, for instance.
The chosen timing constraints are originated from the Timing Augmented Description Language 2 (TADL2)(see Section 2.2.3). TADL2 is an output of the European funded research project TIMMO2USE. I was part of the project team that worked out the constraints definition and validation [82, 80]. Moreover, the focus lied here on the subset of the TADL2 timing constraints related to data transmission (send/write) and reception (receive/read). Gen- erally speaking, a timing event denotes any form of identifiable state change of a system at run-time, that can be constrained with respect to timing. These changes can occur at distinct points in time; referred to as occurrences of the event.
Since the main focus of this thesis is the data synchronization, the presented set of timing constraints are typical for the application area considered in this thesis which the design of automotive bus network.
The semantic behind the timing constraint elements defined by TADL2 is specified using a first order logic notation, which make the transformation to PSL a lot easier since PSL is a language that can be used to formulate standard temporal logics formulas [52].
As mentioned in the previous section, the verification of the timing properties takes place in the third phase of our design flow (see Chapter 4). Timing verification is a tool dependent process step. Therefore, this process step will be demonstrated in Chapter 6 using a case study. The case study discusses the verification of the SystemC model of a brake by wire system.
In the chapter we do not provide a proof of correctness of our transformation rules. Therefore the example used in Chapter 6 will also help validate our transformation rules.
Chapter 6
Verification of timing properties: case
study Brake-By-Wire
This chapter describes the timing verification approach by means of an auto- motive Brake-By-Wire example. This helps evaluate the third phase of our Restbus simulation design flow.
In order to evaluate this phase of the design flow, the model under verifica- tion will first be described. Afterward, timing requirements will be specified. Based on the specification of the timing requirements to be verified, corre- sponding PSL formulas will be derived. Finally, the results obtained after the verification process will be presented.
The system model used in this case study is a SystemC model of an auto- motive BBW application. The model was developed in C-LAB for research purposes. The application is distributed over a set of ECUs and includes ABS functionality. Using this simulation model, the following timing constraints could be specified: • RepeatConstraint • StrongDelayConstraint • RepetitionConstraint • InputSynchronizationConstraint • OutputSynchronizationConstraint • DelayConstraint
Chapter 6. EvaluationPSL
6.1
Functional decomposition of the BBW model
The control algorithms of the BBW model was modeled using MATLAB/Simulink [68]. The block diagram of the Simulink model is depicted in Figure 6.1.
Generally speaking, x-By-Wire characterizes the replacement of traditional components such as pumps, hoses, fluids, belts, vacuum servos and master cylinders with electronic sensors and actuators [16]. All brake components are electronically controlled.
A typical BBW system is composed of two main functions that are imple- mented by the Brake- and ABS-Controller. The Brake controller reads the wheel speed and brake pedal sensor data to compute the desired brake torque to be applied at the four wheels. The second functionality realized by the ABS controller is needed to adapt the brake force applied on each wheel if the speed of one wheel is significantly smaller than the estimated vehicle speed. In this case, the brake force is reduced on that wheel until it regains a speed that corresponds to the estimated vehicle speed. The ABS controller acquires wheel sensor data from each wheel and determines the estimated vehicle speed [81].
The SystemC simulation model was built from C code generated using the MATLAB tool Real-Time Workshop [69] from a Simulink model developed within the department. Basically the C code of the BBW model was wrapped into SystemC modules.
Afterward, a simulation model of the FlexRay bus communication network was added to the overall simulation model. The topology of the simulation model can is depicted in Figure 6.2.
As shown in the figure, the application is distributed over a network of five controller nodes: four ABS controllers and a so-called CarEnvModel node. Each ABS node implements the aforementioned functionality for a specific wheel. In our simulation model, the CarEnvModel node implements the Brake controller functionality for all wheels. Moreover, its functionality in- corporates both the simulation of the vehicle dynamics and a stimulus genera- tor. The Stimulus generator basically generates data representing the pressure applied on the brake and acceleration pedals.
The verification of the timing properties is an activity performed in phase 3 of the design methodology (see Chapter 4). However, the timing constraints to be verified first need to be defined, which is part of phase 2 of the design process. Since our focus lies on data synchronization, detailed knowledge about the communication matrix specifying which nodes communicate with each other and the underlying communication schedule is necessary (see Sec- tion 2.3.2).
Chapter 6. EvaluationPSL abs_asr Accel Brake ABS ze mu x Fz sx w v CAR 1 ze_FR 2 ze_FL 3 ze_RR 4 ze_RL 1 x 2 Fz 3 sx 4 ABS out ABS on/off w [rad/s] v [m/s] ABS ABS-Controller FR ABS on/off w [rad/s] v [m/s] ABS ABS-Controller FL ABS on/off w [rad/s] v [m/s] ABS ABS-Controller RR ABS on/off w [rad/s] v [m/s] ABS ABS-Controller RL 5 v out 6 w out 5 mu_FR 6 mu_FL 7 mu_RR 8 mu_RL 9 Accel 10 Brake 11 ABS on/off 12 ABS in 13 v in 14 w in w (signal 4) w (signal 2) w (signal 3) w (signal 1) ? abs_asr file:///C:/LegacyApp/MATLAB13a/R2013a_64bit/abs_asr_slwebview_files/slwebview.svg 1 of 1 21.11.2014 14:50
Chapter 6. EvaluationPSL ABS_FL ABS_FR ABS_RR ABS_RL CarEnvModel (Stimulus Generator) FlexRay Bus ABS_FL FlexRay bus Brake-By-Wire
ABS_FR ABS_RL ABS_RR
CarEnvModel (Stimulus generator)
Figure 6.2: Network topology of the functional components of the BBW model
Based on this information, timing requirements can then be derived. Ta- ble 6.1 shows the communication matrix and FlexRay schedule of the BBW simulation model. The data provided by the CarEnvModel node are wheel speed (w XX) for each wheel and the actual vehicle speed (V). These data are required by each ABS controller node to compute the actual brake torque (abs XX) to be applied on each wheel.
Moreover, the configuration of the FlexRay network was done using the FlexRay network configuration tool flexConfig [38]. The bus communica- tion cycle duration was set to one millisecond (gdCycle = 1ms) [41], which was the sampling rate of the MATLAB models.
The FlexRay communication cycle was segmented into a static segment with a duration of 400us and a Network Idle Time (NIT) with a duration of 600us. No dynamic segment nor symbol window were used1. The static segment is further subdivided into 10 communication slots.
Slots 1 2 3 4 5 6 7 8 9 10
Data V w FR w FL w RR w RL abs FR abs FL abs RR abs RL -
CAR w w w w w r r r r -
ABSCtrlFR r r - - - w - - - -
ABSCtrlFL r - r - - - w - - -
ABSCtrlRR r - - r - - - w - -
ABSCtrlRL r - - - r - - - w -
Table 6.1: BBW communication matrix
Chapter 6. EvaluationPSL