Model-based Development of an Embedded Steering-by-wire System Khaled Chaaban∗ , Nassim Rizoug † , Bertrand Barbedette† and S´ebastien Saudrais∗ ∗ Embedded Systems Laboratory, ESTACA † Mechatronics Laboratory, ESTACA Rue Georges Charpak BP 76121 - 53061 Laval, France Contact:
[email protected]
Abstract—AUTOSAR standard has been introduced by automotive manufacturers, suppliers and tool developers to define an open automotive software architecture. This paper proposes a framework for automotive model-based design by mapping AUTOSAR concepts with a common model-based design of a steering-by-wire system. It explores how AUTOSAR rules and interfaces can be used to design and build a safety-critical mechatronics system like the steering-by-wire system. The system should be modeled from a system (e.g. controllers, network) and behavioral (e.g. Matlab/Simulink) point of view and both the functional and non-functional requirements should be verified in this model.
Embedded system
Electromechanical system Road wheels subsystem
Controllers
DC Motor + chopper
Road wheels + transmission
Driver
DC Motor + chopper
I. I NTRODUCTION In the automotive domain, the trend to replace mechanical and hydraulic systems by electronic systems exists from several decades and is growing quickly during the last years. The use of software functions corresponding to these physical equipments has also increased. Model-based design helps designers to develop such functions at a higher level of abstraction with the use of methods and tools. The abstract representation needs to represent the relation between the components, the architecture and the way they react to outside stimuli and their behaviour. The embedded architecture usually depends on the physical components needed to develop the new functionality like ECU, buses, etc. The behaviour part needs an expertise of the reaction of the real components and is expressed with models. These models concern the desired functionality and its environment. The construction of models often requires multiple iterations to obtain an accurate and correct model corresponding to the real behaviour of the components. The design of the architecture and the behaviour models are often done in parallel without defined relations between them. These absences of relations do not ease the combination of the models and the architecture to test and simulate the system with the use of different tools and methods and increase the time of development. The paper proposes a framework to develop embedded functions. The approach is illustrated with the development of a steering-by-wire system. By using a model-based approach, the framework regroups system design, network design, test, simulation and validation. The first step of the process is to define a basic architecture regrouping the embedded system c 978-1-4673-0862-5/12/$31.00 2012 IEEE
Steering wheel subsystem
Fig. 1.
Subsystems of a steering-by-wire system
and the electromechanical system. The two systems are then designed in parallel and then recombined to be tested, simulated and validated. The embedded system is designed following AUTOSAR standard. Matlab/Simulink is used jointly with dSPACE tools to design the electromechanical system. The integration of these systems is facilitated using well-defined interfaces. The rest of the paper is organized as followed. Section 2 introduces the steering-by-wire basic architecture. In section 3 the electromechanical system design is exposed. Section 4 presents the embedded system design. Section 5 describes the simulation and validation and finally section 6 concludes the work. II. S TEERING -B Y-W IRE S YSTEM A RCHITECTURE In a steering-by-wire system, sensors will be required for steering position at both steering wheel side and road wheels side. Torque measurements will be also required for the road wheels as well as the steering wheel if a feedback force is required. Controllers permit to connect sensors/actuators to the electromechanical system and to communicate between the steering wheel and the road wheels subsystems using communication bus (Fig. 1). From the functional point of view, a steering-by-wire system must provide two main services: the control of the steer motor torque and the road wheel control (Fig. 2).
Duty cycle Steering wheel
Steer motor torque
Steer angle
Vehicle speed
Steer angle Road torque
FlexRay bus
Steering Controller
Duty cycle Road Controller
Road wheels
Road motor torque Road torque, Road wheel angle, Vehicle speed
Embedded system
Fig. 2.
Electromechanical system
Basic architecture of a steering-by-wire system
The road wheel control is the main system service permitting to turn the road wheels according to the driver request. On the other hand, the control of the steer motor torque provides a feedback effort to the steering wheel while stilling consistent with the driving situation of the vehicle. Each service is implemented in an Electronic Controller Unit (ECU). The communication between the two ECUs is made through the FlexRay bus. FlexRay is a deterministic bus allowing a timetriggered data transmission, high bandwidth of 10 Mb/s and fault-tolerant and management capabilities [1].
Fig. 4. The choice of this model permits to simulate some technological components, like the angle and torque sensors, and the actuators. This planar model (longitudinal, lateral and yaw motions) represents the contact of the two road wheels linked by a rigid beam. The front wheel has one rotation degree of freedom, perpendicular to the plane. The rear wheel is blocked. Moreover, for writing the behaviour equations, the working hypotheses are taken as follows: • small variations are considered • the longitudinal velocity is constant • the vehicle does not slip Table I summarizes the description of used symbols and their corresponding values. With this description, the dynamic equations are: ˙ Fyf cos(δ)) − Fxf sin(δ) + Fyr = m((v˙ y ) + v˙ x ψ)
(1)
lf Fyf cos(δ) − lr (Fxf sin(δ) + Fyr ) = Iz ψ˙
(2)
By taking into account the non-holomic kinematic constraints, the slip angles of the tires are given as: vy + lf ψ˙ αf = tan−1 ( )−δ (3) vx lr Fyr
III. M ODELING OF THE E LECTROMECHANICAL S YSTEM As illustrated in Fig. 2 the electromechanical system can be divided into two subsystems: Steering wheel and Road wheels. Road wheels subsystem is controlled by the road controller through the chopper (Fig. 3) and the steering wheel subsystem is controlled via another chopper. Fig. 3 presents the architecture of the first subsystem (Road wheels) and its inputs/outputs. The second subsystem (Steering wheel) can be represented just by a chopper and a DC motor. The load torque in this case is generated by the driver.
lf
vr OR
αr
OG
Fxr
v
ψ
Fyf
αf
vf
β
δ
Fxf OF
y x Fig. 4.
Description of the bicycle model
TABLE I D ESCRIPTION O F S YMBOLS A ND VARIABLES
A. Vehicle Model The physical model used for testing the steering architecture is the well-known bicycle model [2] [3] which is shown in
Symbols
Description
OG , OR , OF
Point marked the center of gravity, the center of rotation for the rear wheel and the center of rotation for the front wheel Distance between OG and OF (OG and OR ) Total mass of the vehicle Inertia along z axis Rear (or front) lateral wheel force Front longitudinal wheel force Front wheel steering angle Cartesian component of vehicle velocity vector Front (or rear) tire side slip angle Slip angle at the vehicle center of gravity Lateral stiffness of front (or rear) tire yaw angle vehicle yaw rate
To Road Controller
lf (lr ) Vehicle speed v
Motor current Duty cycle (from Road Controller2)
Road wheels angle δ
Voltage Chopper
DC Motor Motor torque
+ -
Wheels model Front lateral wheel force Fyf
Feedback torque Transmission
1 J.s 1 s
Fig. 3.
Motor angle
Detailed architecture of the road wheels subsystem
m Iz Fyr (Fyf ) Fxf δ vx (vy ) αf (αr ) β Cf (Cr ) ψ ψ˙
Value and unity
1.5 m 1000 kg 800kg.m2 N N rad m.s−1 rad rad N/rad rad rad.s−1
αr = tan−1 (
vy − lr ψ˙ ) vx
Considering the force generated by the wheels as linearly proportional to the slip angle, the lateral forces are defined as: Fyf = −Cf αf Fyr = −Cr αr
(5)
The set of those equations gives the model of the vehicle where the front wheel steering angle is the input and the yaw rate is the primary output. With this output, the lateral forces are deduced (Fig. 5(a)). The transmission model in this case is represented just by the ratios between the inputs and the outputs (Fig. 5(b)): θM KT
δ=
Tf eedback =
(6)
Fyf .R KT
(7)
where, θM : Motor angle KT : Transmission ratio R: Wheels radius The DC motor (Fig. 5(c)) is represented by the electrical equation and the motor torque formula according to the current: V = Ri + L
IV. M ODELING OF THE E MBEDDED S YSTEM
(4)
di + Kv ΩM dt T M = Kv i
(8)
where, V : Motor voltage R, L and Kv : electrical motor parameters ΩM : Motor velocity TM : Motor torque For the chopper modeling (Fig. 5(d)), the high frequency harmonic due to the PWM is neglected. So, the supplying voltage is represented by their average value which depends on the duty cycle: V = (2α − 1)E
This section describes the embedded system architecture used to implement the steering-by-wire system. The chosen hardware architecture is firstly presented and then a detailed section presents the software architecture development using AUTOSAR methodology. A. Safety-critical Hardware Architecture The hardware architecture of the steering-by-wire system must support certain mechanisms of fault-tolerance and recoverability in order to achieve the fail-safe requirements [4] [5]. To do this, we have chosen the hardware architecture depicted in Fig. 6. In this architecture, controllers and actuators are duplicated when the sensors are tripled at both steering wheel and road wheels sides. Each actuator is connected to one ECU. Thus, the target hardware architecture is composed of four ECUs. At the steering wheel side, we have three steering sensors (SS) connected to two steering ECUs, a FlexRay network with two duplicated channels (channel A and channel B), two wheel ECUs connected to three wheel sensors (WS). Steering ECUs are also connected to two steering actuators for the feedback torque, and wheel ECUs are connected to two wheel actuators to turn the wheels. B. AUTOSAR Methodology AUTOSAR (AUTomotive Open System ARchitecture) is an established standard for the development of automotive software [6]. It addresses the easy integration and reuse of software components provided by different suppliers in order to reduce cost and time of the development cycle and to improve software quality. AUTOSAR concept is based on
(9)
where E is the battery voltage and α is the duty cycle.
Road wheels angle δ Vehicle speed
Wheels model
v
Front long. wheel force Fxf
Voltage
Front lateral wheel force Fyf
Motor torque
(c)
(a) Front lateral wheel force Fy
Road wheels angle δ
Transmission
Motor angle
(b) Fig. 5.
Motor current
DC motor
Duty cycle
Chopper
Voltage
Feedback torque
(d)
Models of some electromechanical system elements
Fig. 6.
Hardware architecture of the embedded steering-by-wire system
SWC1
SWC2
SWC3
SWC4
Virtual Functional Bus (VFB)
Mapping of SWCs to ECUs
ECU 2
ECU 1 SWC1
SWC3
ECU 3 SWC4
SWC2
RTE
RTE
RTE
BSW
BSW
BSW
HW
HW
HW
CAN, FlexRay
Fig. 7.
AUTOSAR methodology
a model-driven approach where the software and hardware architecture are designed according to formal meta-model describing all the elements from architecture to integration. According to AUTOSAR and as illustrated in Fig. 7, a functional software consists of a set of software components (SWCs) communicating through a Virtual Functional Bus (VFB) whose main objective is to abstract software high layer from hardware/software low layers and to validate the interaction between SWCs before implementation. Then these SWCs are mapped to available ECUs of the underlying hardware architecture. RTE (Run Time Environment) ensures the interaction between SWCs inside one ECU (intra ECUs) or among several ECUs (inter ECUs). RTE may be considered as an instance of VFB per ECU. The communication between SWCs is performed using ports. Each port is defined by a port interface. A port may be one of the three types: sender/receiver (S/R), client/server (C/S) or calibration port (CA). A port contains typed data elements and the connections between ports may be of 1:1 or 1:n data connection type. Further, a SWC may be a Sensor/Actuator component or an Application component. A SWC is defined regardless of the underlying hardware architecture and ECU location. The internal behaviour of a SWC is defined as a set of runnable entities which are executed at runtime. A runnable represents the C code that will be executed on the target. A runnable is mapped to an OS task. Runnables exchanges information using inter-runnables variables instead of global variables which is not permitted in the AUTOSAR standard. The last step of AUTOSAR methodology is the configuration of Basic SoftWare (BSW) modules. BSW modules make the link between RTE and all hardware features of the ECU. Examples of BSW modules are OS, FlexRay, CAN, Memory, ADC, PWM, etc. C. Software Architecture Development Using AUTOSAR In this section, the software architecture of our steering system is described using AUTOSAR methodology. As cited before, from a functional point of view the steering-by-wire
system provides two main functions: rack torque function and feedback torque function. In order to implement these functions a set of software components is defined and illustrated in Fig. 8. Only functional connections are illustrated to avoid a highly connected figure. Interconnections between components are also omitted (Inter ECUs connections) for simplification. Based on the hardware architecture described before (Fig. 6), the software architecture contains one SWC per sensor and per actuator. The application components (SteerManager and WheelManager) are duplicated at both steer and wheel sides. These components implements the steering functions controllers and dependability functions. The ports used are of sender/receiver type. This kind of communication is suitable for data-flow paradigm. The data is acquired at the sensor component and then transferred to the actuator component through several application components. Let’s note that non-functional functions, e.g. fault-tolerant functions and sensors arbitration algorithm are not presented in this paper. These topics have been addressed and published in [7]. Fig. 9 shows the simplified signal flow and involved components of the rack torque function. It has been identified that the signal path of execution will affect four components. The SteerSensor component acquires the steering sensor physical data and passes it to the application software component SteerManager for signal. Afterwards the signal is sent to the application software component WheelManager for order computation until it is finally send to the actuator via the WheelActuator component. At this level, we neglect the physical distribution of components and the underlying network and thus allowing a
SteerSensor1:: SA_SteerSensor SteerSensor
SteerSensor2:: SA_SteerSensor SteerSensor
SteerSensor3:: SA_SteerSensor SteerSensor
VehicleSpeedSensor:: SA_Speed SpeedVehicule
SteerManager1:: AP_SteerManager
SteerActuator1:: SA_SteerActuator
SteerSensor1_data SteerSensor2_data
FeedBackTorque
SteerSensor3_data
InterECU_SM_to_WM
FeedBackTorque
InterECU_WM_to_SM SpeedVehicule
SteerManager2:: AP_SteerManager
SteerActuator1:: SA_SteerActuator
SteerSensor1_data SteerSensor2_data
FeedBackTorque
SteerSensor3_data
InterECU_SM_to_WM
FeedBackTorque
InterECU_WM_to_SM SpeedVehicule
WheelSensor1:: SA_WheelSensor WheelSensor
WheelSensor2:: SA_WheelSensor WheelSensor
WheelSensor3:: SA_WheelSensor
WheelManager1:: AP_WheelManager
WheelActuator1:: SA_WheelActuator
WheelSensor1_data WheelSensor2_data
FeedBackTorque
WheelSensor3_data
InterECU_WM_to_SM
FeedBackTorque
InterECU_SM_to_WM
WheelSensor
WheelManager2:: AP_WheelManager WheelSensor1_data WheelSensor2_data WheelSensor3_data
WheelActuator1:: SA_WheelActuator FeedBackTorque
InterECU_SM_to_WM InterECU_WM_to_SM
Fig. 8.
Software architecture
FeedBackTorque
SteerSensor:: SA_SteerSensor
SteerSensor
SteerManager1:: AP_SteerManager InterECU_SM_to_WM SteerSensor1_data
WheelManager1:: AP_WheelManager RackTorque
WheelActuator:: SA_WheelActuator RackTorque
InterECU_SM_to_WM
VFB bus From steer sensor (I/O)
To wheel actuator (I/O)
Fig. 9.
VFB view of the rack torque function
logical representation of the entire system with validation of functional features of main functions. Fig. 10 shows a simplified schema of the internal behaviour of the SteerManager1 component. The SWC is composed of a set of runnables. A runnable may be triggered by a periodic event like Run Sensors and Run Command with a period of 5ms. It may be also triggered by the data reception on one of its ports like the Run InterECU Wheel1 runnable that are triggered by the reception of FlexRay bus message. Let’s note that there are additional runnables for the nonfunctional functions, e.g. ECU status management, Sensors state management, etc. that are not illustrated in this figure for simplification. An AUTOSAR software component must be independent from any ECU. In contrast sensor and actuator software components are bound to an ECU, exactly to that ECU where the sensor or the actuator is connected to (Fig. 11). For simplification, Fig. 11 illustrates the allocation of basic software components to only primary ECUs. So we must have the same allocation of other replicated components on the duplicated ECUs. The last step of the AUTOSAR software development is the configuration of BSW including OS, communication, I/O units, etc. For example and during OS configuration of SteerManager1 component, we have defined one task per runnable with a high priority (priority=14) assigned to Task1 which is linked to FlexRay bus (Fig. 10). Tasks mapping and priorities assignment are based on engineering knowledge of the designer. For the communication services, we configure the interECU communication, independently of the possible low level bus (CAN/FlexRay or LIN). In our case, the SteerManager1 SWC has to collect angle and torque signals (4 bytes length) from each steering sensor, group them into signal group,
Fig. 10. Internal behaviour of the SteerManager1 component and mapping of runnables to tasks
Fig. 11.
SWCs mapping
packing them into PDU (protocol data unit). Then a PDU router distributes PDU into specific protocol frame (FlexRay frame here) with packing/unpacking service. V. S IMULATION A ND VALIDATION M ETHODS A. Simulation The hardware and software architectures of the steering embedded system have been simulated using Davinci Developer and CANoe simulator from Vector.The first step of this simulation phase is the software design of each ECU using Davinci Developer tool. Now the software design is done the behaviour of each SWC and its inside runnables is tested under Davinci (Debugging C Code) before the test of the whole ECU software for the final code generation. Then, a DLL file per ECU is generated by building the ECU generated software. Then these DLL files are imported in CANoe to simulate the networked system using the FlexRay bus. Sensors and actuators are simulated in CANoe as environment variables. Let’s note that Davinci developer permits to develop one ECU at each time. For this reason CANoe is used to simulate the whole interconnected system.
Fig. 12.
Simulation results of the road angle control
The electromechanical system is simulated using Matlab/Simulink software including the two controllers. The reference wheel angle was computed from the complete steering wheel model. To generate this reference, we have introduced dual torque gate signals. Fig. 12 shows some simulation results for the steering-by-wire system. One observes that the angle from the axle motor follows the reference with a smooth error. Further, the vehicle behaviour is coherent because after a torque gate on the wheel, the direction of the vehicle changes (down graph in Fig. 12). B. Validation In this phase of validation, the Steering ECU1 is replaced by a real target NEC V850(PHO3), connected to a real hand wheel designed for this application (Fig. 13). The hand wheel permits to simulate sensors/actuator errors and thus it is validated with all the functional and safety requirements of the steering system. The rack and the Wheel ECUs (Wheel ECU3 and Wheel ECU4) are replaced with Hardware In the Loop (HIL) test bench, including a model of a generic car, giving vehicle speed Vx and Vy, used for the computation of feedback torque function. To emulate the road wheels behaviour, dSPACE prototyping hardware is used. The models developed in the section 3 are implemented using Matlab/Simulink software and RTI toolbox. This last one ensures the interconnection between the electromechanical system and the embedded one. The setpoint steering angle is transmitted by the FlexRay network to the
ECU4 which includes the PID regulator for the wheel angle control. The output of the road wheel ECU4 is modulated as a PWM (Pulse Width Modulation) signal. The duty cycle of the signal is a function of the steering angle received on the FlexRay network. VI. C ONCLUSION This paper presents a framework for the design, test and validation of a steering-by-wire system. It has been identified that embedded software design and mechatronics frameworks deal with similar methodologies such as build and deploy components. AUTOSAR methodology seems to be more mature regarding scaling an application onto a multitude of ECUs and components configuration. However, both AUTOSAR and mechatronics methodologies assume that you start from a set of well defined components and interfaces but they are unable to define a framework for the definition of a component architecture based on a set of requirements: component granularity, coordination, etc. Our framework gives an integrated approach for the design and simulation of the steering system at both system level and behaviour level. The hardware and software architectures are first specified based on the functional and safety requirements of the system, which is expressed in a basic architecture. Then, they are implemented using simulation and real environment. In this work, we show how the mechatronics methodology has been integrated to the component-based AUTOSAR methodology using a modelbased component framework. R EFERENCES [1] J. Berwanger, C. Ebner, A. Schedl, R. Belschner, S. Fluhrer, P. Lohrmann, E. Fuchs, D. Millinger, M. Sprachmann, F. Bogenberger, G. Hay, A. Krger, M. Rausch, W. O. Budde, P. Fuhrmann, and R. Mores, “Flexray - the communication system for advanced automotive control systems.” [Online]. Available: http://dx.doi.org/10.4271/2001-01-0676 [2] P. Yih and J. C. Gerdes, “Steer-by-wire for vehicle state estimation and control,” in proceedings of the International Symposium on Advanced Vehicle Control (AVEC), HAN Universtity, Netherlands, 2004. [3] L. yan Y., Y. guang O., and F. L., “Research on control strategy and bench test of automobile steer-by-wire system,” in Vehicle Power and Propulsion Conference. IEEE, 2008. [4] J. R. Pimentel, “An architecture for a safety-critical steer-by-wire system,” Society of Automotive Engineers, 2004. [5] S.-L. F. Wilwert C., YeQiong Song and C. T., “Evaluating quality of service and behavioral reliability of steer-by-wire systems,” in proceedings of the IEEE conference on Emerging Technologies and Factory Automation (ETFA), vol. 1, Dearborn, Michigan, USA, september 2003, pp. 193 – 200. [6] H. Heinecke, K.-P. Schnelle, H. Fennel, J. Bortolazzi, L. Lundh, J. Leflour, J.-L. Mat, K. Nishikawa, and T. Scharnhorst, “Automotive open system architecture - an industry-wide initiative to manage the complexity of emerging automotive e/earchitectures,” in proceedings of Convergence 2004, Detroit, Michigan, October 2004. [7] K. Chaaban, P. Leserf, and S. Saudrais, “Steer-by-wire system development using autosar methodology,” in Proceedings of the 14th IEEE international conference on Emerging technologies & factory automation, ser. ETFA’09. Piscataway, NJ, USA: IEEE Press, 2009, pp. 1110–1117. [Online]. Available: http://portal.acm.org/citation.cfm? id=1740954.1741107
Fig. 13.
Validation platform
