Formation of a Software Rapid Prototyping Platform

'3rd International Heinz Nixdorf Symbosium on Mechatronics and Advanced Motion Control',
27. - 28. May, 1999, Paderborn, Germany

Dipl.-Ing. Holger Hennen, Dipl.-Ing. Alfred Pruckner
Institut für Kraftfahrwesen Aachen
RWTH Aachen

---

Abstract
Conventional Development Course for Vehicle Electronics
Developments of a Software Rapid Prototyping Platform
Hardware in the Loop (HIL)
Software Rapid Prototyping
Summary
References

---

Abstract

Modern vehicle development is increasingly transferred from drawing board and test track to the virtual software environment. Constructions are prepared by Computer Aided Design (CAD) and stability of components is directly investigated by means of the Finite Element Method (FEM). Kinematic properties can already be determined with the computer in advance; multibody simulation (MBS) programs enable the registration and evaluation of critical, dynamic vehicle reactions. The basic development of a great variety of control algorithms for the improvement of these dynamic vehicle properties is also done with the computer by means of control engineering simulation tools (CST). However, the testing and further development of these algorithms is still very hardware-orientated, being on the one hand time-consuming and therefore expensive, and on the other hand limiting the possibilities for the control optimization.

Some simulation programs offer therefore the possibility of a mutual data transfer during a dynamic simulation calculation, in order to test the influence of the control algorithm on the vehicle in advance. Different control strategies can be compared and the effects of various system break downs can be analyzed. In order to avoid faulty developments, the development work of these controlling structures should not only be done on the computer, but instead be accompanied by observations on prototype vehicles.

In order to keep these observations as flexible as the development, software rapid prototyping platforms are developed. An algorithm developed by a control engineering program is immediately implemented into the hardware controller of a vehicle; complicated intermediate steps such as the conversion of the algorithm in C-code as well as the implementation of this C-code into the micro controller is very swiftly and fully automatically being done.

In this report the combination of MBS and CST programs in virtual prototyping and the conversion of the controller development in a hardware platform is presented. A complex ADAMS full vehicle model replaces the real vehicle on the test track and a dynamic driving control system (DDC) developed in MATRIXx and delivered by AutoCode generation is directly linked to this model. Operation mode and several theoretic approaches can thereby be very comfortably analyzed and compared. The same algorithm is implemented into a controller platform developed at the Institut für Kraftfahrwesen Aachen (ika). Driving tests demonstrate the quality or the effects of the controller in real environment. By means of this rapid prototyping structure a very flexible and reasonable development basis is provided that can be used for all possible controller developments in automotive engineering.

Conventional Development Course for Vehicle Electronics

The principal course of vehicle control is done by scanning certain measuring data by sensors, converting this information in a control computer into positioning quantities and transferring these quantities to different actuators. In case of an Antilock Brake System (ABS) for example, all four wheel speeds are measured and thereby a reference velocity determined as well as the actual slip values and wheel decelerations calculated. Then, the ABS algorithm decides, whether the braking pressure has to be increased, to be kept or to be reduced. This is being achieved by opening and closing of the single in- or out valves. The schematic course of this control process, in general being run through by a control frequency of 100 Hz, can be seen in the following Fig. 1.



Fig. 1: Controlling Process of a Vehicle Control

The data exchange between the single electronic components is mostly done by means of a so-called CAN-Bus system. The "Controller Area Network" (CAN) as developed by Bosch has established itself as the industry standard bus system for mobile applications. Components for CAN-based systems are available in large quantities at very reasonable prices due to their wide spread use in the automobile branch. The following Fig. 2 shows the combination of the single components [STW99]. Therein ESX/EST displays the controller.



Fig. 2: CAN-Bus Module [STW99]

The programming of the control computer is mainly done in the high command language C. The development of a control algorithm does, however, run through several processes, which are the algorithm development, the conversion into a C-code, the implementation into a electronic box, the connection to the vehicle sensors and actuators as well as the testing on a test track [PRU98]. The test results are then again passed on to the developing engineers, whereby the development chain is closed.

The development process in this chain is significantly slowed down by different "technical" languages of the single staff members and by often different computer programmes. Dependence relationships and the one-directional information flow in long development chains as well as not exactly define interfaces lead to an increase in the development time. This cycle is been run through not only in case of the algorithm development, but also in case of vehicle behaviour improvement.

In accordance to always shorter generation times for vehicle development the above described process must be interrupted. It must be possible for the developing engineer to test different basic variants of control strategies and their influence on the vehicle, without being dependent on the co-operation of others. This has to be realised in a very early stage of the vehicle development, in which no prototype is yet available. The generation of the programming code should furthermore be automated, in order to exclude individual mistakes in advance. Moreover, alterations during the code optimisation should not always require a programming specialist. Improved Algorithm Development
All this can be achieved by the support of latest computer software, which transfer the development process into a virtual environment.

The reproduction of the vehicle is thereby done by so-called multi-body dynamic simulation programmes. The controller development is taking place in special control technique software tools. The co-operation of these two programme packages in the virtual PC-environ*ment is referred to as virtual software prototyping, whereas the co-operation of virtual prototyping, electronic hardware and vehicle prototype is called software rapid prototyping. Virtual Software Prototyping
Virtual prototyping means the reproduction of the real vehicle structure and their environment in the virtual software environment. The mechanical structure is thereby reproduced by so-called multi-body dynamic simulation programs; the control algorithms are developed by means of special control technique programs.



Fig. 3: Multi Body Simulation Program ADAMS

Fig. 3 shows the reproduction possibilities of the multi-body dynamic simulation program ADAMS [ADA98]. The single vehicle components are implemented through their mass, moments of inertia and centre of gravity in their respective position. The mutual relation of the parts are defined by kinematic context or their mutual force connection. These force connections can be presented non-linearily, in order to model, for example, rubber elements in the chassis or driving and steering operations in different driving manouvre simulations as accurate as possible. Usual vehicle models achieve thus 100 degrees of freedom and more, which would hardly be possible by manually determined mathematical models.

The forces between tire and road surface are depicted by non-linear contexts between the tires longitudinal slip ratio, side slip angle and camber angle. Different road surface conditions such as friction values and profiles can be reproduced by road surface models. The drive or brake forces are defined by different complex models, which influence the wheel speed by a drive or brake torque and thus induce forces in the simulation model through the occurring slip. Steering movements at the steering wheel are transferred to the wheels by steering geometry, generating lateral forces and thereby lateral movements of the model by the occurring side slip and camber angles.



Fig. 4: Control Design Program MATRIXx

Complex control algorithm can be depicted by the special control technique software program MATRIXx [MAT99]. Typically, different input quantities are processed in mathematical blocks, whereby different levels can be defined for a better overview. Fig. 4 shows the MATRIXx working sheet. The different substructures are combined in so-called super blocks, where every superblock can consist of single sub blocks.

The combination of both programs can be designed in different ways. Concerning the development of a Software Rapid Prototyping Platform, the possibility of connecting one by MATRIXx automatically generated C-Code was chosen [PRU97]. The integration during a simulation is thereby taken over by the program ADAMS, which passes the quantities, also measurable in the real vehicle, on to the C-code algorithm (f.e. wheel speed) to exactly defined times. The code determines the necessary information (f.i. valve position of the ABS-hydraulic) for the vehicle by this data. This process is discretely run through with the given scanning frequency (~100 Hz). In this process the simulation with ADAMS is not done in real-time.



Fig. 5: Interface ADAMS - MATRIXx

Fig. 5 illustrates again the co-operation between the two simulation programs, whereby MATRIXx is only used for the code generation, but not for the following simulation. So-called tamplates, hand-written translators in an own computer language, thereby enable to adjust the automatically generated C-code to the necessary interface, so that the processes code generation, compilation to ADAMS and simulation start only takes a few seconds.

The deviation via these automatic code generation as well as the use of a complex multi-body dynamic program seems to be too complicated in case of simple control algorithms. Commercialised ABS algorithms could up to now be developed and tested in real time at simple models. However, the complexity of future control requirements also demand respective simulation models. The following example illustrates the complexity of a non-linear side slip angle observation. Example Side Slip Angle Observation
The angle between vehicle lateral and vehicle longitudinal speed is called side slip angle. Big side slip angles cause an uncomfortable driving feeling and are hard to manage by untrained drivers. New dynamic controllers use the vehicle's side slip angle apart from the yaw angle speed, in order to avoid a sliding of the vehicle in dangerous situations [ZAN96]. The measuring of the side slip angle is very cost intensive at the moment, so that the observation of this quantity is being done from other measuring quantities. In the following the process of this observation is described.

Fig. 6 shows the real vehicle and it's mathematical approximation. The input quantity u (steering angle) causes changes in the state quantities x (side slip angle) and in the measuring quantities y (yaw velocity, lateral acceleration). The mathematical model calculates aprroximinations of the state and measuring quantities by the input quantity [HEN98].



Fig. 6: Vehicle and Mathematical Model

The state equation f (x,u) contains a non-linear two-lane model with integrated HSRI tire model [KOR94]. This tire model determines the actual tire forces from wheel load, slip and camber on dry road surface. This in it's turn enables, together with the knowledge of the actual drive- or brake torque (from engine data and braking pressure) the estimation of the really acting tire forces and thereby an estimation of the actual road friction values [HEN99].

The structure of a non-linear driving state observers is depicted in Fig. 7. The non-linear twolane model extended by a correction matrix L is parrellely wired to the real vehicle, in order to thus obtain the estimation value of the non-measurable state quantity (side slip angle). The structure of this observer is similar to the linear Luenberg observer [FOE93]. The Jacobi Matrix of the state and measuring equation has to be established for every calculation step and thereby a dynamic matrix equation with chosen eigen values has to be solved.



Fig. 7: Non-linear Driving State Observation

The development of this observer ran from a simple, linear one-lane model via the non-linear two-lane model, integrated HSRI tire model, friction value recognition, linear Luenberg observer and finally to the non-linear observer. Every one of these steps brought an additional estimation improvement, whereby the algorithm programming would have to be began every time anew. The automatically generated algorithm contains about 3000 programming lines; this in itself, of course, not representing any optimisation. Every code created by programming specialists would be clearly smaller in the programming size, however, the size plays a minor role in the development.

The lastly used controller vehicle model is already so complex that no difference between the simulation model and controller model would have been recognisable without the help of dynamic simulation programs.

Developments of a Software Rapid Prototyping Platform

Naturally the controller algorithm, determined by virtual prototyping, doesn't represent an optimum. Different influencing factors such as temperature, wear and others is only badly and not sensible been understood by multi-body dynamic simulation programs. In order to transfer the advantages of the virtual prototyping also to the test track, the development of a Software Rapid Prototyping Platform is worked on at the Institut für Kraftfahrwesen.

Thereby, the algorithm calculation should be moved from the PC to the electronic hardware in a first step. Then the sensors and actuator should be implemented into the control cycle and finally the simulation model be completely exchanged by the real vehicle. Electronic Hardware in the Loop
The following Fig. 8 shows the first step from the pure virtual prototyping up to the Software Rapid Prototyping. The sensor information from the simulation program ADAMS is passed on to the electronic hardware on the basis of a Siemens C167 microprocessor [STW99] at a PC-CAN interface. The automatically generated C-code generates from this the positioning quantities for the actuators depicted in ADAMS.



Fig. 8: Electronic Hardware in the Loop

For the C-code implemented in the microprocessor a newly designed template must be use, which exactly controls the interface for the CAN data information. The implementation and generation of the C-code as well as the simulation start can again be done within seconds.

The use of dynamic simulation programs in this case has the advantage to analyse effects of the algorithm on the driving behaviour in a closed control cycle. However, real time simulations are not possible in this constellation. In order to test the speed of the electronic hardware, it can be either relied on simple, real-time capable programs or models, or the by ADAMS determined sensor data is directly given to the algorithm in an open control cycle and the results are then compared to those of the virtual prototyping (no real time).

Hardware in the Loop (HIL)

A next step is represented by the Hardware in the loop test. Thereby, only the sensor data of the real driving operation is being replaced by the simulation program, the control outputs can be directly brought to the actuators implemented in the vehicle on specially test benches (Fig. 9).

Depending on the test bench configuration, the reaction of the actuator intervention into the vehicle (f.i. braking torque) can be taken off and in their turn be inserted into the simulation program. However, in order to depict the in this state interesting electronic and actuator dynamic, a real-time capable vehicle model should be used in any case. The multi-body dynamic simulation program SIMPACK [SIM98] offers, for example, the possibility to deliver the vehicle model as linearised C-code model.



Fig. 9: Hardware in the Loop

HIL allows, for instance, the testing of all kinds of possible state variants and also system failures at the real vehicle, without provoking very dangerous driving situations on test tracks. Also the necessary actuator speed under test bench conditions can be more understandably tested.

Software Rapid Prototyping

The last step in the algorithm's development chain is represented by the transition to Software Rapid Prototyping. Thereby, the vehicle model in the computer is replaced by the real prototype (Fig. 10).



Fig. 10: Software Rapid Prototyping

In the ideal case, the algorithm developer is sitting in the vehicle and implements the controller in the vehicle, developed in the environment of the control technique software program, by simply pushing a button. Real driving tests directly allow conclusions about the occurring effects. Changes of single algorithm structures can be very efficiently and plastically done, the parallel operation of the virtual prototyping finally allows the illustration of different interventions concerning their potential danger in advance.

Summary

Virtual prototyping is the depiction of a real vehicle structure and it's environment in the virtual computer world. The vehicle structure has to be thereby reproduced as exact as possible. Electronic control concepts can be connected to these driving dynamic simulations by means of an automatically generated C-code.

In order to test this automatically generated C-code also outside of the computer environment on the electronic platform used in the vehicle, a so-called Electronic in the loop procedure was developed. Thereby, the C-code is loaded into an electronic box, based on a C167 micro-controller, whereas the vehicle model is still be simulated in a PC. The data exchange between PC and electronic hardware bases on a so-called CAN-bus interface.

In a further step the process can be extended to a so-called Hardware in the loop test. Thereby, the vehicle with integrated electronic is placed on a test bench; the sensor input data in the electronic is given by the simulation. The test bench measures the generated reactions at the vehicle and enters them anew in the simulation program. In order to control the dynamics of the control environment, a real-time capable simulation model should be used.

In case of Software Rapid Prototyping the simulation model is finally completely being replaced by the real prototype vehicle. The control software is by push button automatically being generated, compiled, transferred into the vehicle electronics and instantly tested. Changes of the controller code don't have to be newly programmed, the development course can thereby be extremely accelerated. By the combination of dynamic simulation, controller software development tools, C167 electronics and vehicle prototypes newest controlling variants can be very fast and efficiently be developed and tested.

References

ADAMS 9.2.
Operating Manuel to the Software Program, Mechanical Dynamics Inc

FÖLLINGER, O..
Nichtlineare Regelung II
R. Oldenburgverlag, München, Wien, 7. Auflage 1993

HENNEN H.
Entwicklung eines Fahrzustandsbeobachters auf Basis eines nichtlinearen Zweispurmodells
Studienarbeit am Institut für Kraftfahrwesen Aachen, 1998

HENNEN H.
Entwicklung eines integrierten Fahrzustandsreglers auf Basis eines nichtlinearen Zweispurmodells
Diplomarbeit am Institut für Kraftfahrwesen Aachen, 1999

KORTÜM, W.;LUGNER, P.
Systemdynamik und Regelung von Fahrzeugen
Springerverlag, Berlin-Heidelberg 1994

MATRIXx 60.6
Operating Manuel to the Software Program, Integrated Systems Inc.

PRUCKNER, A.
Analysis of Dynamic Driving Control (DDC) Systems on a Full Vehicle Model in ADAMS
ADAMS User Conference, Marburg 1997

PRUCKNER, A.
Virtuelles Prototyping zur Entwicklung von Fahrwerkregelungssystemen mit ADAMS und MATRIXx
7. Aachener Kolloquium, Aachen 1998

SIMPACK 7.1
Operating Manuel to the Software Program, INTEC GmbH

SENSOR TECHNIK WIEDEMANN GmbH
Referenzmanuel for the Control Electronic System ESX, Kaufbeuren 1999

WALLENTOWITZ H.
Vertikal-/Querdynamik von Kraftfahrzeugen, Umdruck zur Vorlesung KFZ II
Forschungsgeselschaft Kraftfahrwesen Aachen mbH

van ZANTEN, A.
Control Aspects of the Bosch-VDC
AVEC Symposium, Aachen 1996