Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015 2008-01-0285
Accelerated and Integrated Real Time Testing Process Based on Two Universal Controllers on Rapid Controller Prototyping Zhenchun Xia and Feng Gao MB SIM Technology Co., Ltd
Kazuhide Togai Mitsubishi Motors Corporation
Hiroki Yamaura Mitsubishi Automotive Engineering Co., Ltd Copyright © 2008 SAE International Inc.
ABSTRACT Rapid Controller Prototyping (RCP) is an efficient method for design & development of ECU (Electronic Controller Unit) at early stage. Usually, RCP requires firstly performing Software-in-the-loop simulation and then connecting universal controller (e.g. MicroAutoBox) to real controlled system for testing of controller functionality. During this process, it is likely that some problems related to signal configuration and real time characteristics occur and consequently give rise to unexpected results, e.g., sensor signals or controlling signals produce large deviation and possibly damage components of real system under severe condition. On the other hand, it cannot make sure that the real time characteristics of designed controller are suitable just after applying Software-in-the-loop simulation. One problem often encountered is that the sampling time of controller is not suitable for real system very well, even though it has been tested by Software-in-the-loop testing in simulation environment. One approach of rapid controller prototyping based on two universal controllers is presented. It is performed after the Software-in-the-loop simulation and before real time testing of real system. It is able to check efficiently the real time characteristics of designed controller as well as configuration of I/O interface. Majority of problems or errors related to real time characteristics or interface configuration can be found quickly and corrected immediately. In this approach, the used two universal controllers have different roles: one is to perform the designed controller functionality and the other is to simulate the controlled system. All interface signals are configured and then the two universal controllers are connected by sensor signals line and CAN line according to the specifications of real system. Based on the approach, the real time closed loop testing can be conducted and real time characteristics of system can be checked and analyzed. This approach improves greatly
258
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
reliability of designed controller and reduces the duration of RCP. It facilitates the testing of designed controller on real system as well as decreases risk of damage on real system to the minim. It is also convenient to develop and test diagnosis functionality of controller. This approach is applied on the design & development of one new type of TCU (transmission controller unit) and proves high efficiency and capability for developing ECU.
INTRODUCTION In the last decades, the development of ECU (electronic controller unit) in automotive industry has experienced large changes, which results from requirements for higher efficiency of development, shorter time-to-market, more reliable quality and more accurate controlling functionality. However, in the early stage of ECU development, one traditional way in which ECU is designed developed and tested gives rise to more and more difficulties to shorten the time-to-market, meanwhile achieve high quality. This traditional way is based on C code programming development style and process. C code has been one popular and efficient tool in a variety of industrial fields in the last decades. Especially in embedded system fields, C code and its programming style is one efficient interface between hardware system and programmer. Unfortunately, with the development of complex system in automotive industry, the codes performing real time functionality is becoming more and more complicated and gives rise to tanglesome structure. This leads to terrible difficulty in terms of readability and maintenance. Especially when the controlling functionality needed to be updated, the modification and debug process can be one nightmare under such conditions.
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
In the late 1970s, CAD (Computer Aided Design) begins to develop into design field of industry. Diagram style design attracts more and more attention. New graphic design tool & platform emerges, e.g. Matlab, Simulink, etc. Matlab is the abbreviation of Matrix laboratory. As its name indicates, Initially Matlab is developed to deal with complicated matrix calculation. As well known, the matrix calculation using C coding is one large burden programmers have to bear. Matlab integrates the matrix calculation algorithm in terms of m. file and Simulink blocks. With more and more toolboxes used, Matlab/Simulink begins to develop powerful environment for graphic design. Real time Workshop is developed to perform automatic code generation. More tools are designed to perform the automatic transfer from graphic design to codes that can be run in real time on target hardware. Targetlink is one efficient tool that can basically produce production code. Based on the CAD and the development of modeling & automatic coding, from the early 1990s, the rapid controller prototyping begins to be applied from laboratory to practices in automotive industry. A lot of big automotive companies in the world gradually perceive the importance of RCP. One of important forces is the pressure coming from more and more complicated software structure and faster time-to-market with still high quality. In the past, one complete design of ECU needs at least dozens of months from the beginning of specification to production. Compared with this traditional development flow, RCP fully utilizes flexible and efficient development methods, which includes graphic specification, model establishment, automatic coding generation, fast and real time testing on real system, etc. However, in the 1990s, automatic coding generation did not develop into maturity stage; automatic generated codes just are used for testing and invalidation of controller algorithm. Its efficiency and precise can not reach production level. After the testing using RCP, software engineer still needs to manually program the code into ECU. Entering 21 Century, with the further maturity of modeling tools, RCP hardware platform and automatic coding technology, RCP gradually develops into its industrial practices stage. One interesting example is some big automotive companies even begin to perform such projects: transferring paramount C codes to Simulink model. One of its purposes is to perform bypass testing to add new functionality, and another one is to achieve high readability for update of functionality in future. As everyone can see, facing at least several thousands hundred lines of C code, only reading and maintaining them seems more and more difficult tasks and need large manpower and time.
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
MAIN SYSTEM FRAMEWORK RCP mainly includes the following important steps: functionality specification, modeling according to functionality specification, software-in-the-loop testing, C code automatic generation into target hardware, real time testing on real time system, correcting and updating functionality according to testing results, finally writing the functionality code into ECU. RCP schematic diagram is indicated in Fig. 1. Functionality specification
Modeling
Plant model
Controller model
SiLS
C code automatic generation
Real time testing on real system
ECU production
Fig. 1 RCP schematic diagram Functionality specification of ECU is important portion in the development flow. It will directly determine what type and what function should be realized. In traditional development, functionality specification of ECU has to finished based on different system levels; from high level of automotive company to sub-level of OEM, and deeply to different develop team. The phenomenon results from the fact that different system level has different platform and environment. They cannot be integrated into one complete development flow. This is changed completely by RCP. The automotive company (or OEM) can directly describe specification completely. The specification will not be separated into different system levels; instead it is directly realized by modeling. This can be viewed as one graphic specification. In early stage of RCP, some manpower and time are needed to establish model. However it is worthy doing so. These models will accelerate the development flow greatly; moreover, they can be re-used in other development projects.
259
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
The plant model and controller model are needed for Software-in-the-loop simulation. One example of SiLS results is indicated in Fig. 2. Ignition key position 6 4 2 0
0
5
10
15
20
25
30
35
40
45
50
Acceleration pedal position % 100
50
0
0
5
10
15
20
25
30
In the last ten years, RCP has been playing important role in ECU R & D field of automotive industry. RCP is utilized to develop a variety of ECUs for different component in vehicle, e.g. engine ECU, ESP ECU, transmission ECU, and roof ECU, etc. RCP greatly accelerates the procedure of ECU development and undoubtedly exposes the traditional C code programming of ECU development to large pressure.
35
40
45
50
35
40
45
50
35
40
45
50
35
40
45
50
Brake pedal position % 1
However, the progress of state-of-the-art is unlimited. When researchers and engineers have been dedicated themselves to developing different ECU to achieve faster time-to-market with high quality, they also find out that there are still big space to improve the RCP schematic diagram indicated in Fig. 1.
0.5 0 -0.5 -1
0
5
10
15
20
25
30
Time (s)
Engine speed [rpm] 6000 5000 4000 3000 2000 1000 0
0
5
10
15
20
25
30
Vehicle speed [km/h] 150
100
50
0
-50
0
5
10
15
20
25
30
Time (s)
Fig. 2 Software-in-the-loop Simulation The whole system, including plant model and controller model, needs to be modeled based on mechanical, electrical and controlling dynamics. Appropriate sampling time and calculation methods (e.g. Euler method) needs to be selected to actuate the model of system. The purpose of SiLS is to perform the initial testing of controller functionality. During SiLS, most malfunctions or errors can be detected by means of massive testing with different testing scenarios. SiLS proves the tremendous importance in the development of controller. SiLS can validate at least three aspects efficiently: controlling functionality, signal flow, sampling time scope. Controlling functionality can be directly tested through the interaction between plant model and controller model. Signal flow realized in the model of whole system will lead to clear understanding & tracking which is critical to master the behaviors of system. Sampling time scope is another crucial issue. Under large numbers of signals conditions, different characteristics of signals will give rise to large difficulty to analyze the proper sampling time. SiLS can easily solve this. Appropriate sampling time will actuate system normally; otherwise system will probably be activated abnormally, even put into chaos.
260
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
In Fig. 1, the “C code automatic generation” refers to that the controller model is automatically transferred into C code and downloaded into target hardware, e.g. AutoBox, MicroAutoBox and PC-compatible board, etc. Then the target hardware is connected to the real system for real time testing. Before this real time testing on real system, just the software-in-the-loop is performed. Possible problems often, even inevitably occur: the target hardware that acts as controller to actuate & control the real system possibly cannot meet the requirements of real time operation. Even under extreme condition, it cannot be completely avoided that the controlling signal will exceed normal scope, therefore possibly cause the damage of components in real system. For example, the PWM signal from the target hardware will possibly exceed its normal scope and lead to the abnormal action of motor. It is dangerous if action of motor cannot be controlled precisely. The root of such problem lies in the difference between software simulation and real time running: the software-inthe-loop simulation cannot completely simulate & indicate the interactions of system in real time environment. It is not difficult to find the reasons for such situation. Normally software-in-the-loop environment is based on non real time operation system, e.g. Windows operation system. In running circumstance of such system, the operation of CPU is split into pieces of time. The pieces of time are assigned to different working of software program. How fast and how long time one program runs and needs is determined by the number and duration of the pieces of time which are assigned to the program. For example, the running time of one model system in Matlab/Simulink environment doesn’t have direct relationship with real time. If the CPU frequency and internal memory is large enough, the model system may take only one tenth of time to finish running. On the other hand, if a model system is very complex and needs large memory, it will take far too longer simulation time than needed in real time environment. It is not to one’s surprising that one model in certain operation system can take several hours to finish one simulation which simulation time is set to just several minutes. Another important reason is related to the issues of interruption. In Matlab/Simulink, there is no interruption concept existing, neither hardware interruption nor
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
software interruption. All sub tasks are sequentially and logically conducted without any interruption from external environment.
Fig. 3 Interrupt occurrence during system running This obviously doesn’t comply with the real situation in the real world. Interruption is one crucial concept and influence for the controlling system in the real world. Some events or issues own high priority and need fast response by controller. Meanwhile, other sub tasks are not always important; some of them can be temporally suspended and re-run after short pauses. Speed signals are generated or given as certain values in SiLS environment, however those signals are commonly fed to ECU as pulse inputs in real application. Pulses are converted into speed values through interrupt in actual ECU. The illustration of interruption is indicated in Fig. 3.
Besides the running time and interruption, there is still one important issue which cannot be ignored when taking into account the difference between the simulation in Matlab/Simulink and real time running. That is the running power: memory volume and processor capability. In Matlab/Simulink, the memory volume and processor capability is so powerful that they can reach hundreds of million bytes and thousands of million Hz. But these cannot be true concerning the hardware & software conditions of real ECU. This situation likely gives rise to obstacles when trying to write generated C code to real ECU: overrun situation will occur and the C code volume exceed the capability of real ECU, either on the memory or on processor frequency, even both. All analysis above clearly indicates that software-in-theloop cannot deal with all problems before applying controlling algorithm on real system. More and more practices and project experiences explicitly indicate that more things need to be performed after software-in-theloop and before the real time testing on real system. This new-added part is indicated in Fig. 4. From Fig. 4, it can be seen clearly that not only the controller model is automatically downloaded into target hardware, but also the plant model is automatically download into target hardware. These target hardware should be different, which are connected by sensors lines and CAN lines. The two target hardware and link lines are built into one complete system which can perform comprehensive real time testing, analysis and evaluation. The plant model and controller model both can be real time run. The sensors lines and CAN lines are used to transfer different signals, from which characteristics of signals can be monitored. Interruption can be realized by utilizing the interruption port of the target hardware. Sometimes overrun situation probably occurs, and this provides warning that the volume of controlling algorithm exceeds the calculation capability of processor. It seems to one addition of cost in R & D procedure due to the introduction of the second target hardware. On the contrary, the addition of cost will prove overridden by the benefits coming from the results that majority of possible problems & errors can be detected and solved early before testing on real system, which leads to higher efficiency and faster time-to-market, consequently achieves high profit. In reality, the updated RCP schematic diagram has proven one efficient platform, which enables researchers or engineers to see results of real time running, monitor important signals, and detect some errors early.
SOFTWARE-IN-THE-LOOP SIMULATION Software-in-the-loop simulation has developed into the core and the base for model based development of ECU. It enables the visual ability during the procedure of ECU controlling algorithm. Fig. 4 Updated RCP schematic diagram SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
261
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
Based on more and more variety of blocks, Matlab/Simulink makes it possible to establish complicated model in short time. Complex controlling algorithm & idea can be realized quickly in terms of combination of different blocks with kinds of functionality. Different algorithm & ideas can be tested and selected in incredible short time compared with the traditional C coding of controlling functionality. Model simulation makes it un-necessary that one software engineer’s team is needed to transfer the controlling idea to coding for testing and evaluation.
The plant model is downloaded into AutoBox, and the controller model is downloaded into MicroAutoBox. RTI blocks and RTI CAN blocks are added separately on plant model and controller model. Through these RTI bocks and RTI CAN blocks, the two universal controllers are connected by CAN lines and sensor lines. Two laptops are used to monitor, modify and debug on-line the system and perform the real time testing as well as data log.
ControlDesk
ControlDesk
Signal monitoring
MicroAutoBox
RTI
CAN signal
RTI
Motor PWM
Sensor signal CAN signal Motor PWM CAN signal
Plant Model
CAN signal
Signal tuning
RTI
Sensor signal
RTI
Controller
In Matlab/Simulink, different sampling time can be set up for different requirements of different components of whole system. This will greatly reduce the calculation burden of ECU in real time running. Even Matlab/Simulink has developed one powerful ability that it can automatically deal with coordination of multi-sampling time blocks. What designer needs to do is just to concentrate on functionality development and sampling time to be optimum. Majority of low-level configuration and coordination can be finished by Matlab/Simulink itself automatically as shown in Fig. 5.
Matlab/Simulink, Stateflow, S-function, dSPACE ControlDesk, RTI Blocks, RTI CAN Blocks, CANoe, etc.
AutoBox
Fig. 6 Integrated RCP platform based on two universal controllers
HARDWARE INTERFACE DEFINITION
Fig. 5 Automatically handle data transfers between tasks The development and gradual maturity of technology of automatic C code generation largely expands the capability of Simulink model. Only one button operation is needed to transfer one complicated Simulink model to executed C code. All complex working, e.g. model analysis, signals analysis, complier execution, header and C file generation, etc can be done by Real Time Workshop of Matlab/Simulink. State flow block is utilized in Matlab/Simulink to realize multi state operation flow. This is especially useful when conduct simulation of transmission. State flow simply the realization of multi state operation flow greatly.
The hardware definition of RCP system includes two parts: the plant interface and controller interface. The plant interface defines the output ports, e.g. sensor signals, CAN bus signals and motor driver command signals; correspondingly, these signals are also defined on side of controller. When defining the hardware interface, the signal calibration should be paid more attention. Hardware interface definition includes physical signals definitions and CAN signal definitions as shown in Fig. 7. Environment
Controller
RCP SYSTEM STRUCTURE For quick development of new type of TCU meanwhile with high quality, one integrated & efficient RCP platform based on two universal controllers is developed as shown in Fig. 6. The hardware of this platform mainly includes AutoBox, MicroAutoBox, CAN lines and Sensor lines and laptop for monitoring, etc. Software of the platform mainly includes
262
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
Fig. 7 Hardware interface definition
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
Voltage range adaptation
4 10/9
ADC ADC_T YPE1_M1_CON2
>=
Gai n1
The signal lever_position is provided as one example to indicate how to conduct adaptation of signal between plant model and controller model concerning RTI blocks.
1 lever_position
0.9
3
>= 0.6
2
The lever_position includes 0, 1, 2, 3, 4 four numbers. In order to output these values, one DA conversion of RTI block is used as one output port of plant model as shown in Fig. 8.
>= 0.3
1
>= 0.1
0
>=
DAC
0 0
DAC_TYPE1_M1_C7
Fig. 8 RTI block for DA conversion
Fig. 11 Adaptation on side of controller model Signal value positive offset
I/O characteristics Table 1 shows the scaling between the input of the block and the analog output voltage: Table 1 DA conversion I/O characteristics Simulink Input
Output Voltage
Simulink Data Type
0 … +1
0 … + 4.5 V
Double
Another example of signal adaptation is related to motor current value adaptation. In the plant model, the motor current signal is about -19 A - +19 A. In order to transfer right value to controller model, signal value positive offset need to be performed as shown in Fig. 12.
1 1/40
Motor current 20
Gain4 offset
DAC DAC_T YPE1_M1_C6
Add2
Correspondingly, one AD conversion block is used as one input port of controller as shown in Fig. 9. 1 Motor current
10/9 Gain1
ADC
Table 2 AD conversion I/O characteristics Input Voltage
Simulink Output
Simulink Data Type
0 … +5 V
0…+1
Double
Fig. 12 Signal value positive offset After the connection of ABX and MABX, under some conditions, maybe MicroAutoBox updated its flash memory, but AutoBox doesn’t do so. This situation is shown in Fig. 13. Controller MABX
Consequently, voltage adaptation needs to be conducted according to real value range of lever_position and characteristics of A/D, D/A conversion blocks.
RAM
The adaptation on sides of plant model and controller are indicated in Fig. 10 and Fig. 11.
Flash memory
Code 1
0.25 Gain8
Add
offset
Fig. 9 RTI block for AD conversion Table 2 shows the scaling between the analog input voltage and the output of the block:
1 Out1
Gain 20
ADC_TYPE1_M1_CON2
lever_position
40
Power supply
Plant ABX
RAM
CAN Cable
Sensor Cable
Flash memory
Empty
DAC DAC_T YPE1_M1_C7
Fig. 10 Adaptation on side of plant model
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
Fig. 13 Refresh of universal controllers
263
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
Normally, it can transmit the correct value, but if the Plant ABX doesn’t run the plant model code or the signal cable is disconnection. The Controller MABX could detect a value from the pin, which is 0, then the controller model subtracts 20, and the final result is -20A. Obviously, it’s wrong. Before accepting the transmitted data from Plant MABX, one judgment must be done whether the plant model is running or the connection is right firstly or not.
1/0.0005
Pulse width #1
1 Pulse width of motor PWM
Pulse width percent 1/0.0005
Pulse width #2
Pulse width percent1 DIO_TYPE1_FPW2D_CTM_M1_BL1
2 motor PWM
BIT_IN DIO_TYPE1_BIT_IN_M1_G2_C5
motor PWM combination
BIT_IN DIO_TYPE1_BIT_IN_M1_G2_C6
Because the current range is -19 - +19, when the Controller model accept a value -19 Constant4 when the input value is < the constant, the output equal to the input. otherwise the output value is setted to zero
Block Function
Simulink Output
Simulink Data Type
Pulse width
>= 0 [s]
Double
Fig. 14 Judgment of transit situation
RCP PROCESS BASED ON TWO UNIVERSAL CONTROLLERS
Actuator command signal Actuator controlling signal is very important in hardware interface definition. For example, PWM will determine the motion speed and direction of motor rotation. On side of controller model, motor PWM signal is divided into CMD, Enable and Direction as shown in Fig. 15. 0.0005 Period
2k Hz CMD
Duty Cy cle
DIO_TYPE1_PWM_VP_M1_C3 1
In1
Enable
BIT_OUT
motor pwm DIO_TYPE1_BIT_OUT_M1_G1_C5 Direction
BIT_OUT DIO_TYPE1_BIT_OUT_M1_G1_C6
pwm division
Step1 Controller and Plant model establishment Controller model and plant model are established in Simulink environment. Controlling strategy is designed & developed in Controller model. Under some conditions, core/key parts of controlling strategy may be masked into S-function. There are two types of wrapping controlling strategy into S-function. One is to directly wrap existing C code of controlling strategy into S-function. This is one powerful tool to utilize existing large volume of C codes. The other is to wrap sub-blocks of controlling strategy into S-function as shown in Fig. 17. This method is one effective tool to protect intelligent property rights. Original Originalmodel modeland andfolder folder
Fig. 15 Division of PWM
Generate GenerateS-function S-function
CMD is transited by DIO_TYPE1_PWM_VP_M1_C3.
RTI
block
Created Createdfile file
Table 3 I/O characteristics of RTI block for CMD Simulink Input
Duty Cycle
0…1
0 … 100%
Created intermediate files
On side of plant model, CMD, Enable and Direction are combined into PWM signal as shown in Fig. 16. Fig. 17 Wrap of sub-block into S-function
264
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
Step 2 Software-in-the-Loop simulation Controller model and plant model are connected by defined signals, e.g. sensor signals, CAN signals, actuator command signals, etc. Then Software-in-the-Loop simulation is conducted. Depending on the analysis of simulation results, controlling strategy could be improved and most of errors/faults could be found and eliminated, e.g. errors related to signals definition, interface configuration, etc.
Data log Signal monitoring
Acce pedal
Brake pedal Lever position
Ignition key postion Vehicle speed
Engine speed
Fig. 19 Monitoring of Driver Command signals
Fig. 18 Download flow of model Step 3 Models download into universal controllers After Software-in-the-Loop simulation, the complete model is split into two parts again: controller model and plant model, which are downloaded separately into two universal controllers, e.g. MicroAutoBox and AutoBox. Before downloading, RTI blocks and RTI CAN blocks need to be added into input/output side of controller model and output/input side of plant model. Controller model and plant model are automatically converted to code, which is called automatic code generation. In the last decade, automatic code generation has gradually developed into one efficient and reliable tool. The download flow of model is indicated in Fig. 18.
One of most important benefits of real time closed loop testing is to detect possible errors which can not be detected during the software-in-the-loop simulation. For example, as shown in Fig. 20, the simulated results of vehicle speed and engine rotation rate are respectively 230 km/h and 7500 rpm, however, the real time testing results of vehicle speed and engine rotation rate are 70 km/h and 10500 rpm. Obviously, there are huge difference between simulated results and real time testing results. Further and detailed analysis indicates that the lack of filter and robustness of system leads the instability of controlling strategy. After modifying the filer parameters and improving the robustness of system, controlling strategy can work normally in real time environment. Real time testing results
Maxi Value=70km/h
Maxi Value=10500rpm
Maxi Value=230km/h
Maxi Value=7500rpm
E ng ine S pe ed , 1 35 Input S pe ed and 24 6 R Input S pe ed [rp m]
V ehic le S p ee d [km /h]
8000
250
7000 200
6000 150
5000
4000
100
3000 50
2000
Simulated results
0
-5 0
0
10
20
30
40
50
60
Simulated results
1000
0
70
0
10
20
30
Step 4 Real time closed-loop testing based on two universal controllers The two universal controllers are connected by sensor signals and CAN lines. Real-time closed-loop testing can be performed based on the complete system.
40
50
60
70
Time (s)
Tim e (s )
Real time testing results Maxi Value=230km/h
Maxi Value=7500rpm
Maxi Value=230km/h
Maxi Value=7500rpm
V e hic le S pe e d [km /h]
E ng ine S p e e d , 1 3 5 I np ut S p ee d and 2 4 6R I np ut S p e ed [rp m ]
250
8000
7000 200
Great benefits can be achieved by real time closed-loop testing, mainly including: signal monitoring, analysis of real time characteristics of system dynamics, testing of sampling time, evaluation of robustness and stability of whole system, validate of hardware interface definition, etc. For example, the monitoring of Driver Command is indicated in Fig. 19.
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
6000 150 5000
100
4000
3000 50 2000 0 1000
-5 0
0
10
20
30
40
50
Tim e (s )
Simulated results
60
70
0
0
10
20
30
40
50
60
70
T im e (s )
Simulated results
Fig. 20 Comparison of simulated results and real time testing results
265
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
On-line modifying parameters, real time monitoring of system response and on-line data logging are other important functionalities of real time testing, which are show in Fig. 21.
Fig. 21 Debug interface of real time testing Step 5 Controller works on real system After the real time closed loop testing of the controller, majority of errors of controlling strategy can be found and eliminated. As the last step of RCP, the controller is applied on real system. For example, the MicroAutoBox is applied to control the actuators. In order to catch quick pulse signals of actuator sensor, hardware interruption blocks are used as shown in Fig. 22. DS1401BASE Interrupt DS1401BASE_HWINT
f unction() angle
DS1401BASE Interrupt DS1401BASE_HWINT1
DS1401BASE_HWINT2
In1Out1
Task Transition (no buffer)
In1Out1
H1 f unction() angle
DS1401BASE Interrupt
Task Transition (no buffer)
Function-Call Subsystem1
H2
1
Angle1
Out1
Function-Call Subsystem2
H3
Angle calculation f unction() angle
Task Transition (no buffer)
In1Out1
Function-Call Subsystem3
Fig. 22 Hardware interruption for pulse signal
CONCLUSION A new structure of RCP is presented. It tests the real time characteristics of controller based on two universal controllers that represent a target plant and an ECU. The proposed method requires minimum set of hardware for real time functionality evaluation. And a system to be applied for the method is compact as shown. The method was applied on controller functionality development successfully. The application indicates effectiveness of such new RCP method. The proposed method accelerates the development of ECU, and reduces the time-to-market efficiently.
266
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
REFERENCES [1] Arno Ebner, “Real-time Platform for Rapid Prototyping and On-line Simulation of Digital Controllers for Electrical Drives”, SAE 2006-01-0306 [2] Jooyoung Ma, Jeamyoung Youn, Minsuk Shin, and Myoungho Sunwoo, “A Design Approach Using Seamless Development Environments, SILS/RCP, for Real-time Control Systems”, SAE 2006-01-0310 [3] Axel Schlosser, Bert Kinoo, Wolfgang Salber, Sascha Werner, and Norbert Ademes, “Accelerated Powertrain Development Through Model-Based Calibration”, SAE 2006-01-0858 [4] J. Gertler, M. Costin, Xiaowen Fang, Z. Kowalczuk, M. Kunwer, and R. Monajemy, “Model Based Diagnosis for Automotive Engines – Algorithm Development and Testing on a Production Vehicle”, IEEE Transaction on Control System Technology, Vol. 3, No. 1, March, 1995 [5] Amit S. Deshpande, Anant Wanpal, M. Ganesh Babu, Nilesh Kankariya, Keshav Mundhra, and S.A. Sundaresan, “ECU Testing and Verification Using Hardware-in-the-Loop”, SAE 2006-01-1444 [6] Jeamyoung Youn, Jooyoung Ma, Wootaik Lee, and Myoungho Sunwoo, “Software-in-the-Loop Simulation Environment Realization Using Matlab/Simulink”, SAE 200601-1470 [7] Everet Ray Lumpkin and Michael Gabrick, “Hardware/Software Design and Development Process”, SAE 2006-01-0170 [8] Yasser Yacoub and Alain M R Chevalier, “Rapid Prototyping With the Controller Area Network (Can)”, SAE 2001-01-1224 [9] Shigeaki Kakizaki, Martin Eckmann, Dirk Berneck, and Frank Schuette,., “Advances in Rapid Control Prototyping – Results of a Pilot Project for Engine Control”, SAE 2005-011350 [10] Klaus Lamberg, Rainer Otterbach, Mario Eschmann, Mirko Conrad, Ines Fey, and Michael Beine, “Model-Based Testing of Embedded Automotive Software Using Mtest”, SAE 200401-1593 [11] Michael H. Smith, Satoshi Furukawa, Shugang Jiang, and Dharshan Medonza, “Design and Implementation of an Integrated Development Environment Consisting of Engine Rapid Control Prototyping and Real Time Vehicle Simulation”, SAE 2007-01-0515 [12] Luca Solieri and Enrico Corti, “Rapid Control Prototyping System for Combustion Control”, SAE 2005-01-3754 [13] William Luitje, “Seeing Beyond C”, SAE 2006-01-1610 [14] dSPACE, “Real-Time Interface Implementation Guide”, Release 4.2 – March 2005 [15]Kazuhide Togai, Kazuo Kido, Hiroki Yamaura, Zhenchun Xia, and Guozhong Wang, “Model Based Diagnosis: Failure Detection and Isolation by State Comparison with Model Behaviors”, SAE 2007-01-2077 [16] M. Guler, S. Clements, N. Kejriwal, L. Wills, B. Heck, and G. Vachtsevanos, “Rapid Prototyping of Transition Management Code for Reconfigurable Control Systems”, in Proc. of the 13th IEEE International Workshop on Rapid System Prototyping, Darmstadt, Germany, 1-3 July, 2002
Downloaded from SAE International by Zhenchun Xia, Tuesday, April 07, 2015
[17] Jonas Fredriksson and Bo Egardt, “Nonlinear Control Applied to Gearshifting in Automated Manual Transmissions”, in Proc. of the 39th IEEE Conference on Decision and Control, Sydney, Australia, December, 2000 [18] L. Glielmo, L. Lannelli, V. Vacca, and F. Vasca, “Speed Control for Automated Manual Transmission with Dry Clutch”, in Proc. of 43rd IEEE Conference on Decision and Control, Atlantis, Paradise Island, Bahamas, 14-17 December, 2004 [19] R. C. Baraszu and S. R. Cikanek, “Torque Fill-In for an Automated Shift Manual Transmission in a Parallel Hybrid Electric Vehicle”, in Proc. of the American Control Conference, Anchorage, AK, 8-10 May, 2002 [20] Herbert Schuette and Markus Ploeger, “Hardware-in-theLoop Testing of Engine Control Units – A Technical Survey”, SAE 2007-01-0500
CONTACT Zhenchun Xia, MB SIM Technology Co., Ltd, China,
[email protected] Feng Gao, MB SIM Technology Co., Ltd, China,
[email protected] Kahuhide Togai, Mitsubishi Motors Corporation, Japan,
[email protected] Hiroki Yamaura, Mitsubishi Automotive Engineering Co., Ltd, Japan,
[email protected]
SAE Int. J. Passeng. Cars - Mech. Syst. | Volume 1 | Issue 1
267
