Introduction of co-simulation in the design cycle of the real- control for electrical systems R.RUELLAND, J.C.HAPIOT, G.GATEAU Laboratoire d'electrotechnique et d'electronique Industrielle Unité Mixte de Recherche I.N.P.T.-E.N.S.E.E.I.H.T. / C.N.R.S. B.P. 7122-2, rue Camichel 31071 Toulouse Cedex 7 - FRANCE email: ruelland, hapiot, gateau}@leei.enseeiht.fr Tel. : 05-61-58-82-08, Fax. : 05-61-63-88-75 URL : http://www.leei.enseeiht.fr/ Abstract: The design of a real control device for electrical systems is a complex task because the constraints are various and include severe and precision requirements. The electrical systems heterogeneity, the technology available, and the structure of algorithms which are more and more complex have to be taken into account to respect these constraints. An example of co-simulation including a microprocessor simulator is presented for the design of a numeric speed control of a D.C. current machine. The co-simulation includes the simulation of the electro-mechanical system with the Saber simulator from Analogy, associated with a digital control unit with an instruction set simulator of the 68332 microcontroller from Motorola. This stage allows us to test differents software synthesis and to compare the co-simulation results with experimental results. Key-Words: Control system architecture, real control, electrical systems, co-simulation. 1 Introduction. The choice, the design and the experimental validation of the control architecture actually represent a large part in the development cycle of real control applications. These stages can have serious consequence on the control performances. Therefore, in order to respect the numerous constraints such as requirements, precision, development, cost,...the designer must take into account a lot of parameters. A part of these parameters are the structure of the algorithms, the technology available, the nature of the controlled system composed of a continuous part (an electrical machine associated to mechanics) and a discrete part (the static power converter),... According to this description, the designer of real control systems needs assistance, firstly for the architecture choice and also to estimate if all the constraints can be reached with the selected architecture before starting the hardware design. We have focussed our study on the integration of microprocessor simulators and co-simulation technique in the development cycle of the control of an electrical drive associated with a static power converter. The paper is organized as follow. In section 2, the co-simulation technique is introduced within the development cycle for control systems. The third section discusses about related work on the models of software processor. We present in the fourth section an example of co-simulation applied to the numeric speed control of an electrical machine. The next section is dedicated to the confrontation of simulation and experimental results. The last section conclude about the results and present our future objective. 2 The co-simulation in the design cycle The development cycle is composed by several significant stages [4] which can be illustrated by the figure 1. 1. The choice of an Architecture: This includes the choice of the microprocessor model, the hardware devices (FPGA, EPROM,... ), the communication interface... 2. Hardware and Software partitionning: Usually all the functionalities are divided into tasks. Each task must be assigned to a hardware or software part. There is a great interactivity with the previous stage.
expensive loop (in and cost) Functional specifications Hardware synthesis Hardware and Software partitioning System integration performance evaluation Hardware prototype Architecture choices Software synthesis Optimisation loop Co-simulation Fig. 1 : Using co-simulation in the development cycle 3. Hardware and Software synthesis: That consists to generating the custom Hardware code (FPGA, EPROM), to generating software, and to adapting the wordlength of communication interface between hardware and software but also with analog domain... 4. System Integration and Performance evaluation: During the integration stage, software/hardware interaction is evaluated in a real prototype or an emulator[8]. In that stage, the objective is to know if the timing requirements and functional specifications are respected. All the stages in this design cycle are naturally iterative. The last stage is certainly the most expensive. If the specifications are not reached, any stage can be redefined. That's why for the estimation performance of a control unit, we use the co-simulation technique. The co-simulation term is used in different contexts but usually concern the use of connected heterogeneous computation models [11][7]. Our purpose is to use the co-simulation in the last stages of the design, to jointly simulate the software, the hardware and the electromechanical parts. In the development cycle, we place the co-simulation step after the synthesis of the differents technologies (code generation, interfaces choices,... ) and we do not make the co-simulation of the hardware part because we focus our study on the software performance estimation. In the application dedicated to the control of electrical systems, the control system have hard constraints. Concerning the computation, the microprocessors are the most critical components. Therefore a bad accuracy in the estimation of software performance can have a serious consequence on the design choices. That's why in this first step we show the related approach to estimate and simulate software performances. 3 Models of software processors. Nowadays, processors simulation can be achieved by different ways [1]. The technical choice mainly depends on objectives we want to reach. An overview of methods currently used is given in this part: A Hardware detailed model: This approach consists in describing the internal hardware architecture as arithmetic and logic unit, memory management unit, etc... with a hardware description language like VHDL or Verilog. A very good accuracy can be obtained with this model. Despite the relative precision, the computation is very large (some thousand instructions per second). This accuracy seems to be useless compared to our objectives. A Bus functional model: This model does not execute any software. It simulates only the pin behaviour during a reading or writing operation of the processor. The bus transaction frequency can be represented by a stochastic model. This model is mainly used to help the hardware interface development. An Instruction Set Simulator (ISS): That type of simulator is often provided in the processor development toolkit. It allows designer to debug program because ISS is a software which can read microprocessor instruction and simulate its execution. They are built using the interpretive simulation technique. Consequently, they can provide information about resources like registers and memories. They can also provide timing information at cycle level. The performance estimation of a software, using an instruction set simulators, have a great interest even if they have a slow simulation speed (200 to 20k instructions/s) and if they are very difficult to extend.[3] A Compiled simulation: The basic idea is to translate the target binary
code in an "assembler level" C code, which can be executed on a standard workstation. During the transposition, some informations are added like informations for example. This type of simulators is faster than ISS simulators because steps like instruction decodage or instruction fetch have disappeared. Because processor resources are C variables, they can easily be visualized during the simulation using a standard debugger. This type of simulators seems to be more interesting than ISS but they are not very developed [10][5]. An estimation by annotation: Here, the objective is to estimate the execution s of the High Level Language used. This is done using a benchmark program. The benchmark is built with all the current elements used in the HLL. This program is then analyzed with profiler or assembly language tools. Once this step done, the principle is to use the data base created before, by annotating the tested program. The information annotation allow us to estimate the program execution. However, this method has a poor accuracy because this principle cannot include compiler optimization and because it cannot consider architectural features like pipeline for example.[9] According to our objectives and in view of the different models features, the instruction set simulation and the compiled simulation seems to be the more interesting techniques. 4 A co-simulation application. A co-simulation between SABER simulator from Analogy and a 68K simulator [2] is presented in this part. The 68K microcontroller is simulated using the instruction set simulator written in C language. The communication between the both simulators is achieved by using the MAST language of SABER. These capabilities of SABER simulator permit us to call 68K simulator during the simulation of the electrical system at each sampling period. 4.1 The electrical system and its control unit structure. A numeric speed control of a D.C. machine has been chosen to illustrate the co-simulation possibilities in the electrical systems domain. In the Saber simulator, the electrical system is modelled and includes an electrical D.C machine associated to mechanics, fed by a four quadrants chopper. The numeric speed control is based on a cascade control algorithm which includes a current loop (cf figure 2). C language + Ωref - Sim68k Ωm Speed Control Iref + - Ωm Fork Current SABER simulator +Machine Im Chopper Fig. 2 : Cascade regulation diagram. Load The control loop for the current is composed by an analog fork current control. The numeric speed control loop, computed by the 68K microcontroller simulator with a fixed point precision, is based on a Proportional Integral control algorithm. The 68K microcontroller works with a fixed sampling period and the reference current is updated only at the end of the control algorithm computation.(cf. figure 3). i/o transfert Te(k) Ωm(k) 68k computation Iref(k) Fig. 3 : The real- events. Te(k+1) Ωm In this first stage, the sensors are perfect and the interface between analog and digital domain is done by perfects "ADC" (analog to digital converter). 4.2 Synchronization between the two simulators. The SABER simulator allows us to do mixed-signal simulation (digital and analog). Moreover, the communication between the two simulators can be scheduled using the discretes events simulation technnique. By using the SABER simulator language (MAST), we have scheduled the tasks as described in figure 3. A
sim68k call is done at each sampling period computed by SABER. The argument sent to the sim68k function is the mechanical speed. Then the sim68k simulates the control program execution which correspond to the speed control algorithm. At this stage, the sim68k function send back to SABER the new reference current and the computation. The computation is used by SABER to schedule a new event, which corresponds with update the reference current only after the calculation (cf figure 4-b), what cannot be done during a simple functional simulation (cf figure 4-a). executing a MOVEL instruction at location aa INSTRUCTION: memory[ aa]= 0 0 1 0 0 0 1 1 memory[ ab]= 1 1 1 1 1 1 0 0 REGISTERS: <D0> = 00000000 <D4> = 00000000 <A0> = 00000000 <A4> = 00000000 <D1> = 00000000 <D5> = 00000000 <A1> = 00000000 <A5> = 00000000 <D2> = 00000000 <D6> = 00000000 <A2> = 00000000 <A6> = 00000000 <D3> = 00000000 <D7> = 00000000 <A3> = 00000000 <A7> = 00000000 trace: -1 sstep: -1 cycles: 32 <A7'>= 00000f00 <PC> = 000000b4=180 Control register: X=0 N=0 Z=0 V=0 C=0 STACK: mem[ f10]=0 0 0 0 mem[ f0c]=0 0 0 0 mem[ f08]=0 0 0 0 mem[ f04]=0 0 0 0 mem[ f00]=0 0 0 0 < mem[ efc]=0 0 0 0 mem[ ef8]=0 0 0 0 mem[ ef4]=0 0 0 0 mem[ ef0]=0 0 0 0 ---------------------------- Te(k) Te(k+1) Fig. 5 : ISS used as a assembler level debugger Iref(k) a) Events during a functional simulation (seconds) : t(s) cpt_ (float) Te(k) Te(k+1) Iref(k) 68k computation (seconds) 01 500u cpt_ (integer) b) Events during a co-simulation (rad/s) : t(s) speed (float) 10 Fig. 4 : The co-simulation and the timing information. 5 speed (integer) (rad/s) 5 Simulation and experimental results. 5.1 Simulation results. In a first the instruction set simulator can be used as a traditional debugger at assembler level, which permits to verify the use of the microprocessor resources (cf. figure 5). In a second, when the co-simulation structure fixed, we can use it to test different ways to code the algorithm. We chose to illustrate our co-simulation principle by the following simulation cycle: starting the electrical machine with a numeric speed reference equal to 80 and an inversion of the reference after 1.8 seconds. Figure 6 illustrates the simulation results with a float format coding. This format is really expensive in term of computation and is not very interesting in a accuracy objective. Moreover, when the reference current reached the saturation limit, the computation is 5 10 0.25 0.5 0.75 1.0 1.25 1.5 1.75 2.0 2.25 2.5 2.75 3.0 t(s) Fig. 6 : Simulation results: comparison between the float and the integer format coding influence. increased by 50 percent compared to a non-saturated reference. Figure 7 illustrates the simulation results when the coding format is 16 or 32 bits. We observed that the computation has not the same behaviour in the two cases, specially when the error between speed measured and the speed reference is negative. This simple example shows us the effects of the coding format used for the control algorithm and the response of the microcontroller. These informations may have a great importance for designer, and can for example guide the designer to make the
(seconds) (rad/s) 150u 100u 50u 10 5 5 10 0.25 0.5 0.75 1.0 1.25 1.5 1.75 2.0 2.25 2.5 2.75 3.0 t(s) (seconds) : t(s) cpt_ (short) cpt_ (integer) (rad/s) : t(s) speed (short) speed (integer) Fig. 7 : Simulation results: comparison between the integer and the short format coding influence. choice of a sampling period taking into account the constraints while having a poor latency. The choice of a lower sampling period may have effects on the response [6] and the perturbation rejection. Somes it can have a direct influence on the dimensioning of passive elements for the filter associated to the static converter, like inductances or capacitors. Using response of the microcontroller, we can highlight some behaviours which allow the designer to define the critical constraints with a good precision. 5.2 Experimental results. The use of sim68k simulator has been made because we work on a target based on 68332 CPU which has the same instruction set than the 68K microcontroller. sim68k can be therefore used for evaluating the computation and we just have to change the instructions execution and the computation of the execution to become compatible with the 68332 cycle definition. Currently, the behaviour is correct and the execution s between the simulation and the prototype are about the same (cf. table 1). The differences can be explained by the fact that the 68332 CPU has a micro-sequencer which can perform pipeline. coding format sim68k execution 68332 execution relative error Non-saturated current reference integer 43.5 μs 38 μs 14.4% short 26.2 μs 22.5 μs 16.4% float 620 μs 425 μs 45.9% Saturated current reference integer 86 μs 68.33 μs 25.9% short 59.6 μs 49 μs 21.6% float 1.1 ms 720 μs 52.7% Table 1 : Comparison of execution s between the sim68k and the 68332 CPU. 6 Conclusions and Future Work. We have proposed in this paper the use of cosimulation principle in the design cycle of a real control system dedicated to electrical systems. To illustrate our purpose, we have chosen to study the numeric speed control for a D.C. machine. This example shows the possibilities of the co-simulation between a microcontroller simulator (68K) and SABER simulator. By adding a co-simulation stage in the design cycle, designer can be able to test and validate the whole system but also to have new information about constraints applied to the real control system. It can be very useful to have all these informations before starting a new development. Doing iterations on the synthesis stage is also possible. This allow designer to see the effects on the control, helping on the evaluation about performance stage. The next step of our project is to include a VHDL simulator which permit to simulate hardware components and its interactions with the software and the electromechanical part. This next step of Cosimulation will allow us to test some differents partitionning cases. References [1] E. A. Lee A. Kalavade. A hardware/software codesign methodology for dsp applications. The IEEE Design and Test of Computers, September 1993. [2] Eos Unity Computing
. http://www.eos.ncsu.edu/eos/info/tkm_public /68k/dos/sim68k/. [3] A. Sangiovanni-Vincentelli J. Liu, M. Lajolo. Software timing analysis using hw/sw cosimulation and instruction set simulator. 6th International Workshop on Hardware/Software Codesign, March 1998. [4] Hoang Le-Huy. Microprocessors and digital ic's. Proceedings of the IEEE,Vol. 82, No. 8, page 1140, August 1994. [5] A. Sangiovanni-Vincetelli M. Lajolo, M. Lazarescu. A compiled-based software estimation scheme for harware/software co-simulation. Design Autmation Conference, March 1999. [6] E. Monmasson. Architecture of digital control devices Application to variable speed drives. electrical engineering, INPT-Enseeiht, 1993. [7] F. Hessel A.A. Jerraya P. Le Marrec, C.A. Valderrama. Hardware,software and mechanical cosimulation for automotive applications. IEEE international workshop on Rapid System prototyping, June 1998. [8] Slim Ben Saoud. Real emulator of Static converters / Electrical Machines/ Sensors sets. electrical engineering, INPT-Enseeiht, 1996. [9] K. Suzuki and A. Sangiovanni-Vincentelli. Efficient software performance estimation methods for hardware/software codesign. Design Automation Conference, June 1996. [10] Heinrich Meyr Vojin Zivojnovic. Compiled hw/sw co-simulation. Design Automation Conference, June 1996. [11] E.A. Lee W.-T. Chang, A. Kalavade. Effective heterogeneous design and co-simulation. The Nato Advanced Study Institute Workshop on Harware/Software Codesign, June 1995.