The Electronic Throttle Control (ETC) Example

NOTE: The description of this example assumes the reader is familiar with the elements of CheckMate. Some of the simpler demonstrations provide an introduction to CheckMate and the basic principles for modeling hybrid systems using the CheckMate blockset.

System description

The ETC problem is one of the challenge problems in the DARPA Mobies project. The ETC challenge problem considers the part of the power train control that replaces the mechanical link between the pedal and the throttle plate. As shown in Fig. 1, the throttle plate angle, α, determines the airflow into the combustion chamber, and thus controls thus the engine power. The task of the ETC is to control the throttle angle, based on input from the human driver.

image002
Figure 1. An automotive air-fuel mixture control system.

UCB (Paul Griffiths) provided a MATLAB/Simulink of the ETC. The system to be controlled comprises a pulse-width modulation (PWM) driver, an actuator (a DC motor), the mechanical system (the throttle and spring), and sensors. Figure 2 shows how these subsystems interact with the controller. The controller generates a desired current, which is proportional to the desired torque from the actuator. The PWM driver is designed to control the output torque of the actuator to equal the desired torque. The dynamics of the mechanical system are governed by the throttle mass, the spring constant, friction due to airflow, and the coulomb friction between the mechanical parts. The sensor measures the angle of the throttle, which is fedback to the controller.

image004
Figure 2. An automotive air-fuel mixture control system.

System requirements

According to the description on the MoBIES OEP page, there are several requirements regarding the rise and fall time, the settle time, the steady state tracking error and fault detection. In this demo consider to the rise time requirement, defined as follows: 

Rise Time is defined as the time required for the throttle plate angle response to a step change in pedal position to rise from 10% of the steady state value to 90% of the steady state value.  The rise time for step changes from closed to fully open is 100ms; and the rise time for step changes from WOT to closed is 60ms.

This requirement can be checked for any given instance of the ETC controller by simulation. One just starts at t=0 with a jump from zero to a wide open throttle (WOT) and measures the rise time according to the definition above. One might argue that there is little left for verification. However, what simulation cannot cover are situations in which the are uncertainties in the model, e.g., parameters for which only a possible range of values is known. In this demo we will obtain a parametric model of the ETC. Details on how to model the rise time requirement can be found in the section on the CheckMate model.

Simulink model

The Simulink model as distributed on the MoBIES OEP page has subsystems for the PWM driver, actuator, mechanical system, sensors, and controller. The controller has several levels of hierarchy, but its behavior is governed by a Stateflow diagram, that switches between four normal modes, two failure modes, and a startup mode. In all modes except for human and cruise control mode, the controller delivers a constant output that may depend on the mode. The underlying controller in human and cruise control mode is a sliding mode controller.

The sliding mode controller has as input the actual angle and the desired angle, and as output the desired output. The controller output (desired current) is then the max of the output from the sliding mode controller, and a constant. This constant is high if we are in cruise control mode, and low otherwise. In addition to the Stateflow model and the continuous behavior for each mode, the model includes sampling of input and output, fault detection, delays, and finally diagrams that interconnect all components.

The model of the ETC defines a nonlinear hybrid system, foremost, since the controller is both, nonlinear and hybrid. We furthermore have the driver, which produces a switched output, and plant model, that includes coulomb friction.

Towards a CheckMate model

When building the CheckMate model we have to keep in mind that we want to verify properties are that concerned with the angle of the throttle plate. In this demo we focus on how to derive a continuous-time model suitable for verification. To minimize the amount of computation required to explore and verify specifications for a system, one must decide what to include into a model and how to include it. This is not a CheckMate-specific problem, but is general to modeling. Since verification is a computationlly-expensive exercise, particular choices may have a drastic effect. Nevertheless, most issues are similar to problems one might encounter when building simulation models. In this section we want to describe in more detail how to obtain a CheckMate model for the ETC case study.

Mechanical System

The continuous behavior of the mechanical system is governed by the differential equation:

image006

The angular velocity ω depends on the Coulomb friction - Kf  sign(ω), the viscous friction - Kd  w,  the force from the spring - Kd  (α-αeq) and the input torque Kt im . Constant αeq is the spring equilibrium. The plant without Coulomb friction is a linear system with poles -0.05 ±19.75 i. When we want to model this behavior, we have to decide whether we want to include the Coulomb friction as a non-linearity, or whether we want to include it as different modes, with each of the modes governed by linear dynamics.

The sensors

The sensors are modeled as affine mapping of the plant output. When the sensor signal enters the controller, the inverse mapping is applied.  We omit sampling of the output, which removes also a delay, and replace the sensors by the identity.

Filter

The ETC uses a fifth order filter (poles -80, -80, -90, -90, -100) to smooth the input from the human driver. This means that the filter alone has more than twice as many state variables as the system itself. Since verification of hybrid systems suffers from each additional dimension, we try to reduce the order of the filter. We obtain a reduced filter using the model reduction capabilities of MATLAB's system identification toolbox. Figure 3 shows a comparison of the output of the fifth-order and a second-order filter after a step input at time 0 from zero degrees to 90 degrees.

second_order
Figure 3. Comparison of the step responses of fifth-order and second-order reference-signal filters.

The sliding mode controller

The sliding model controller applies on the different sides of a sliding surface a control that will drive the system to the sliding surface, as illustrated in Fig. 4. The ETC uses as sliding surface λ(α-uf) + (ω-u'f ). The variables uf, u'f and u''f are the output from the filter and its first and second derivative. The sliding surface is such that for a constant input the system will eventually converge towards a state were the actual angel is equal to the desired angle, and the angular velocity is zero. As soon as the controller hits the sliding surface it will (ideally) stay on it, and the behavior of the plant will be determined by the equivalent behavior on the surface. In practice the system will start chattering around the surface.

image007
Figure 4. An illustration of a sliding surface in sliding mode control.

The sliding mode controller has as input the filtered input uf, the first and second derivative of uf, the throttle position α, and the angular velocity ω. The control that is applied the different sides depends on the sign of s=λ(α-uf) + (ω-u'f ). The output current im of the sliding mode controller is defined as:

image009

As soon as the controller is close to the surface it will start chattering, and effectively behave as the equivalent controller. Variable-step integration routines however will tend to get stuck on this sliding surface. To resolve this problem, we will a technique that is also used to mitigate the chattering of physical systems. We introduce a boundary i.e. an ε neighborhood around s=0. We apply the sliding mode controller (3), if |s|≥ε, and replace the sign(s) by the s/ε, if |s|≤ε. The controller is thus equivalent to the original controller outside the layer, and there is a steep but continuous transition from one sliding mode to the other. This third intermediate mode reduces the chattering effectively, but has limited effect on the angle α as illustrated in Fig. 5, where ε is chosen to be 0.05.

boundary
Figure 5. Comparisons of the system response with chattering on the sliding surface and a boundary layer with equivalent control.

Driver and actuator

The PWM driver controls the motor torque to the desired torque. It has been observed that the driver and actuator show saturation, i.e. if the desired current is above a certain threshold, the actual torque will not increase. Figure 6 shows a comparison of the behavior of the orginal model, to what we obtain if we replace PWM and actuator by a gain and a saturation block.  As can been seen from this figure, the driver and actuator manage to realize the desired torque fairly well. The PWM-interval is just 0.0025 seconds, and the poles of the actuator are -360.5 and -1356.2. The PWM and the actuator react, therefore, much faster than all the other components in the system.

A further simplification can be made by omiting the current saturation from the model, in which case the plant dynamics are linear, since all nonlinear terms cancel each other. In this example, we retain the model of current saturation.  

PWM
Figure 6. A comparison of the system response with and without the PWM driver dynamics.

Building the CheckMate model

NOTE: At this point, the reader should open the CheckMate model for the ETC demo (file etc5d.mdl in the folder ~/demo/etc5d).

The CheckMate model includes the complete dynamics of the ETC described above, and also a model that translates the rise time requirement into a reachability question. This results in a model with five continuous state variables (four state variables for the ETC dynamics and one state varialbe - a clock - for the rise-time specification).

The user-defined m-files

The ETC model uses two user-defined m-files to define the system constants and parameters. The file etc_def.m contains the all constants of the ETC such as the motor resistance, spring constant, and maximal motor current. In it we also defined the ``thickness'' of the boundary layer layereps, the sliding mode parameters layereps and n and the matrices that define the dynamics of the second-order reference-signal filter. The structure red_fil contains the matrices Af, Bf, Cf, Df that provide the state-space representation of the reduced-order reference-signal filter.

In order to define the sliding surface we need to know the reference-signal filter output uf and its derivative. Since we are are going to consider the rise time requirement, we may assume that the actual human input u is constant after t=0. We then have that the derivatives of u are:
filterderivative
Let x1 and x2 be vectors that select the first and second state variable of the filter from the 4-dimensional state x of the complete system.

We then define the following matrices:

ufA=red_fil_c.C*[x1;x2];
ufB=red_fil_c.D *alpha_des;
ufdotA=red_fil_c.C*red_fil_c.A*[x1;x2];
ufdotB=red_fil_c.C*red_fil_c.B*alpha_des;
ufddotA=red_fil_c.C*red_fil_c.A*red_fil_c.A*[x1;x2];
ufddotB=red_fil_c.C*red_fil_c.A*red_fil_c.B*alpha_des; 
For a given state x, the filtered output is then defined by ufA*x+ufB. The derivatives of uf are obtained similarly.

The sliding surface is defined by the hyperplane surfA*x+surfB=0 with
surfA=lambda*(alpha-ufA)+(omega-ufdotA);
surfB=-lambda*ufB-ufdotB;

The second user-defined file is setup5d.m. This file defines the thresholds of the system, the analysis region, the initial set, and the parameter constraints.

The boundary layer around the sliding surface is defined by:

assignin('base','above_surf',linearcon([],[],-surfA,surfB-layereps));
assignin('base','below_surf',linearcon([],[],surfA,-surfB-layereps));
A similar surface is defined for the Coulomb friction. In a small neighborhood of ω=0 we assume that the friction is zero (ω is the fourth state variable). We distinguish between modes in which the throttle turns to the right, to the left, or is not turning. We define two hyperplanes that separte these modes:
assignin('base','turn_left',linearcon([],[],[0 0 0 1],-layereps));
assignin('base','turn_right',linearcon([],[],[0 0 0 -1],-layereps));

Next we define the 10% and 90% threshold that we need to check the rise time requirement:

assignin('base','alpha_geq90',linearcon([],[],[0 0 -1 0 ],[-0.9]*alpha_des));
assignin('base','alpha_geq10',linearcon([],[],[0 0 -1 0 ],[-0.1]*alpha_des));
A clock variable (an additional state) will be introduced to measure the rise time. We have to define for this clock the analysis region, the initial set, and a 100ms threshold:
assignin('base','clock_AR',linearcon([],[],[1;-1],[150;1]));
assignin('base','clock_ICS',{linearcon([],[],[1;-1],[0;0])});
assignin('base','clock_geq100',linearcon([],[],[-1],[-0.1]));

The remainder of the file setup5d.m defines the analysis region, the initial set, and parameter constraints of the ETC. Finally we set some global parameters of the system. To make the two user files load automatically whenever we open setup5d.m, we edit etc5d.mdl and change the field PreLoadFcn accordingly.

The discrete part of the ETC model.

The portion of the CheckMate model shown in Fig. 7 represents the switching between different modes of the sliding mode controller. We use the output of two polyhedral threshold to determine whether the system is on or off the sliding surface. The Stateflow diagram mode is also shown in Fig. 7

slidingdia modefsm
Figure 7. The discrete portion of the CheckMate model of the ETC dynamics.

The Coulomb friction is modeled similarly. A Simulink part that connects the polyhedral thresholds with the finite state machine, and the Stateflow diagram of the FSM are shown in Fig. 8.

Coulombdia Coulombfsm
Figure 8. The switching logic to model the Coulomb friction in the CheckMate model of the ETC dynamics.

The continuous part of the ETC model

The ETC model uses one SCSB to model the system's continuous dynamics. Figure 9 shows the parameters defining this SCSB (as displayed by clicking on the SCSB block in the CheckMate model).

scsb
Figure 9. Parameters for the switched continuous ETC dynamics.

The model of the ETC dynamics has no resets, but it is parametric. For this demo we assume that the spring constant Ks and the spring equilibrium αeq have an uncertainty of 20%. The SCSB has the following block parameters:

The file slidingmode uses four state variables to define the behavior, two for the filter, and two for the plant dynamics.

The SCSB has two discrete inputs, one for the mode of the sliding mode controller, and one to model the Coulomb friction. We assume for simulations that the system starts in the origin.

In addition to the fields that define a non-parametric CheckMate switched continuous system, we have two additional fields: default parameter and parameter constraint. The default parameter is [1.2,0.8], i.e. for this example, that the spring constant Ks is 20% above its nominal value, and the spring equilibrium αeq is 20% below its nominal value.

The parameter constraint is a linearcon object and is defined in the setup file along with constraints on the initial condition, and the analysis region. Due to these parameters the system is non-linear. We will thus include the saturation of the actuator as a non-linearity, rather than modeling it as different modes.

The file slidingmode.m defines the continuous behavior depending on the input from mode and . It uses four state variables, two for the filter, the third one for α and the last one for ω. The dynamics of the filter are defined by ufA*X+ufB*alpha_des, given the state vector X, and desired angle alpha_des. The derivative of the the third element of X is omega.

As shown below, the derivative of ω depends on the mode of the controller and the direction of the angular speed. The file slidingmode.m computes the sign of ω and s from input from the FSMs. Depending on whether the system is on the surface (signsurf==0) we compute the part of the control input that depends on the state (iA), and the part that is constant (iB), separately.

switch signsurf
case 0,
    iA=1/Kt*(Ks*alpha + Kd*omega + J*ufddotA-lambda*J*(omega-ufdotA))-(n/layereps)*surfA;
    iB=1/Kt*(-Ks*alpha_eq +J*ufddotB + Kf *signomega +lambda*J*ufdotB)-(n/layereps)*surfB; 
otherwise,
    iA=1/Kt*(Ks*alpha + Kd*omega + J*ufddotA-lambda*J*(omega-ufdotA));
    iB=1/Kt*(-Ks*alpha_eq + J*ufddotB + Kf *signomega+lambda*J*ufdotB)- n* signsurf; 
end;
The portion of the file slidingmode.m shown above corresponds to equation (3). However, the input current might saturate, if it is beyond a certain threshold or below zero. This saturation phenomenon is modeled by the following code:
if iA*X+iB<0
      iA=[0 0 0 0];
      iB=0;
elseif iA*X+iB>maxmotoramps
      iA=[0 0 0 0];
      iB=5.4545;
end;
The behavior of the fourth state variable is then compute as defined by equation (2), which is coded as:.
Xdot4=1/J*(-Kd*omega - Ks*p(1)*alpha + Kt*iA)*X+...   
      1/J*(-Kf*signomega + Ks*p(1)*p(2)*alpha_eq + Kt*iB);

Here we have the two parameters. Parameter p(1) is a weight on the nominal spring constant Ks, p(2) a weight on the spring equilibrium alpha_eq. We are thus modeling that the actual constants differ from the ones that are assumed by the controller.

Testing for the rise-time requirement

The rise time requirement can be converted into a simple reachability question by adding a small system that observes the ETC behavior and enters an avoid-state, as soon as the requirement is not satisfied. In order to translate the requirement that the time between crossing the 10% threshold and then the 90% threshold has to has to be smaller that 100ms, we need three thresholds, and one extra clock variable that measures the rise time.

Figure 10 shows the portion of the CheckMate model that represents this logic for the rise-time requirement.The two thresholds geq10 and geq90 take input from the SCSB that defines the behavior of the ETC. Threshold elapse100 gets input from a SCSB that implements a simple timer. The timer is non-parametric with reset. The implementation of the timer and the corresponding Stateflow diagram is straightforward.

testdia testfsm
Figure 10. The CheckMate representation of the rise-time specification.

The clock dynamics for SCSB1 in Fig. 10 is defined by:

function [xdot,type]=testclock(x,q);

type='clock';

if  q==2
    xdot=1;
else
    xdot=0;
end;
reset=0;

Hence, time elapses if the discrete input q is 2, and stops otherwise. The Stateflow block testfsm has as output 2 if the system has passed the 10% threshold but has not yet passed the 90% threshold. The system satisfies the requirement if it enters the reach state, and it violates it, if it enters the avoid state. Note that it would be sufficient to check for one of these properties.

Simulation

We simulate this model with parameter 1.7 for the weight on the spring constant. The results show (see Fig. 11) that even for a deviation of the spring constant of 70% the rise time requirement will be satisfied. But the simulation shows also that the controller is not able to keep the system on the sliding surface.

simulation
Figure 11. Simulation of the CheckMate model for the ETC exmaple (see the text for the particular operating conditions).

The results show that it is likely that one of the other requirements like settle time will not be satisfied. As a next step we are going to derive a simpler model that allows us to investigate these requirements in more detail in the demonstation example etc2d.

Results of the model exploration

Though CheckMate allows parametric verification, a complete verification for this model with 5 state variables is quite time consuming. Therefore, we use the ability to explore the system behavior using simulation with CheckMate. For this parametric system exploration means that we simulate from all vertices of the combined parameter/state space. Since we assume that the system starts in the origin, and both parameter may range over an interval we get four initial points to start from. The first result of the exploration (that is, by typing the explore -vertices command) is:
Computing specification 1 of 2 in the list 
block orders: x = [ETC testclock], q = [coulomb mode testfsm], pth = [above below elapse100 geq10 geq90 left right]

Select parameters
block ETC:   [1.2;1.2] 

Select vertices
block ETC:   [0;0;0;0] 
block testclock:   0 

t = 0.01, x = [0 0 0 0 0], q = [1 3 1], pth = [1 0 0 0 0 0 0]
  ---> ... --> null_event

For initial condition x = [0 0 0 0 0]: The system enters the state "reach".
 / specification satisfied

We started this simulation with he parameter [1.2,1.2] for the SCSB that models the ETC, i.e. both parameter are 20% beyond nominal. The SCSB that implements the timer has no parameter, hence we do not select parameter for this block. The simulation starts at t = 0.01 and we obtain that the system satisfies the requirement, since testfsm enters location reach. The simulation ended in a null_event i.e. we entered a region without any outgoing transition. Once we are such a region we know that the system will remain in this region.

The exploration results for the other vertices show the same result; the ETC ensures the rise time requirement, even if the spring constant and the spring equilibrium deviate from the nominal value with 20%.