- Email: [email protected]
Framework for Fast Real-Time Applications in Automatic Control Education
Copyright © IFAC Advances in Control Education, Istanbul, Turkey, 1997
FRAMEWORK FOR FAST REAL-TIME APPLICATIONS IN AUTOMATIC CONTROL EDUCATION Christophe Salzmann, Denis Gillet, Roland Longchamp, and Dominique Bonvin
lnstitut d 'Automatique (lA), Ecole Poly technique Federale de Lausanne (EPFL) CH - 1015 Lausanne, Switzerland, email: [email protected], WWW' http://iawww.epji.ch/
Abstract: This paper presents an integrated solution to develop fast real-time applications in an academic environment. The solution is based on a framework which guides the user through all the necessary steps: from the selection of a control solution to its real-time implementation and validation. With the proposed framework, students can concentrate on the control concepts. The difficult implementation aspects, such as the real-time programming and the hardware interfacing, are completely managed by the framework and transparent for the user. The framework user interface is well adapted to meet didactic requirements, and its ease of use leads to a reduced learning period. Copyright © 1998 !FAC Keywords: Education, Automatic Control, PD Controller, Real-Time Applications.
The RTFw described in this paper enables users to develop an application to drive a real process through an universal acquisition board. These components (realtime software, computer, acquisition board) compose the integrated workbench (Gillet, et aI. , 1995) used by the students to perform virtual and real experimentation (simulation and implementation).
I . INTRODUCTION Students in automatic control need to put the theory they learn during lectures into practice (Gillet, et aI., 1994), which includes experimentation on real processes and implementation of complete control solutions. This implementation can be difficult to present in lectures without reducing the time dedicated to the presentation of fundamental topics. As a matter of fact, implementing control solutions from scratch requires knowledge not only in automatic control but also in sensors technology and in computer engineering, such as hardware interfacing and real-time programming. These skills might not be previously mastered by students who take automatic control courses, since they usually have various engineering backgrounds. An integrated framework is provided to the students in order to combine theory study and implementation practice. This framework reduces the additional knowledge required to proceed with the implementation and helps students focus on essential concepts. This Real-Time Framework (RTFw) integrates the different steps, such as simulation and testing on the real process, necessary for developing control solutions. To be attractive to the students, the RTFw needs to be highly interactive and offer a well-designed graphical user interface. These conditions and price considerations make professional real-time development tools, such as dSPACE and the Real-Time Workshop (The MathWorks), inappropriate for educational purposes.
This paper is organized as follows : Section 2 gives an overview of the existing solutions to develop real-time applications. Section 3 describes the real-time kernel upon which the real-time framework relies. Section 4 shows the use of the real-time kernel within LabVIEW. Section 5 presents the real-time framework characteristics. Finally, an application example is given in Section 6, where the PD control and the real-time simulation of an electrical drive are implemented using the RTFw. 2. CURRENT SOLUTIONS Current solutions for real-time control applications can be divided into five categories: The first solution is the implementation of an analog controller. This means that only analog circuits are used to carry out the control job. The advantage of this solution lies in the fact that it can be used for fast processes whereas its lack of flexibility is the main disadvantage. The controller type is predefined and the user can only change parameters in a limited range.
299
With the second solution, parts of the analog circuits are replaced by a microprocessor. This type of controller is called a pseudo-analog controller. It possesses the same drawbacks as the first approach, except that the controller code can be changed by swapping the microprocessor ROM.
nel has been developed at the Institut d'automatique and integrated into the real-time framework . It is driven by interrupts generated either by the real-time clock (RTC) found on the motherboard (internal interrupt) or by a timer found on the acquisition board (external interrupt).
The third solution is based on Programmable Logic Controllers (PLC). This type of controller facilitates the implementation of more advanced solutions with a greater flexibility. It can also be supervised by another computer. The PLCs are widely spread in industry and can work in a stand-alone mode.
3. REAL-TIME KERNEL The real-time kernel (RTK) should be seen as a standalone background application which communicates through shared memory with the foreground application holding the user interface. The RTK has two main functions: the first is the communication with the real process via acquisition devices like AD & DA boards. The second is the management of the user's defined real-time tasks (RTT), which can be any type of timed operation such as real-time control, real-time simulation or on-line identification.
The fourth solution is to equip a personal computer with a dedicated board holding a specific processor such as a Digital Signal Processor (DSP). Compared to the previous approaches, this dedicated processor accepts more sophisticated controllers and advanced analysis algorithms. The dedicated board also hosts the I/O circuitry such as AD & DA converters. This expensive solution gives the user the opportunity to supervise the different development stages during controller design.
The RTK must be able to execute tasks repetitively at a fast and accurate timing. To achieve these performances, the RTK relies on interrupts 0 (see Fig.l). An interrupt is a unique or repetitive signal, generated by a device such as a timer. This signal tells the processor to stop the execution of the current process @, to save the current processor state, and to switch to a predefined routine called Interrupt Service Routine @) (ISR). When the ISR is completed, the processor restores the saved state and resumes the interrupted process O. The time between the interrupt occurrence and the start of the ISR is called latency 0. This time varies depending on the OS and the processor's current state.
With the fifth solution, the computer processor alone is used to run the controller algorithm. Today's computer processors are in some cases faster than specialized processors. The I/O operations are handled by an extra brainless acquisition board. This solution is wellsuited for education purposes because of its low cost and the possibility to reuse standard acquisition boards available in many laboratories. This paper presents the implementation of the fifth solution because of its advantage in an academic environment. This solution evolves around a personal computer used for performing other tasks, for example word processing. For such a versatile use, real-time Operating Systems (OS) cannot be considered. However, current personal OS like MacOS or Windows provide basic mechanisms to handle fast real-time operations. To expand those capabilities, a real-time ker-
Many of today's universal acquisition boards have the required timers and circuits to generate interrupts. The advantage of using external interrupts is that such signals can also trigger the acquisition of the data
'#;&' External interrupt @
i
I ,
I I
tI Interrupt 0
0
~~S]gJ35~\ S
E;:Sl
Current process @,O
RT Task #18, called every int.
EIll!3
RT Task #28
called every
2 int
c.. RT Task #38. issues the AD conversion and waits for the data 10 be available. TIle lighl gray pan represents time spenl for !he AD conversion.
Internal interrupt
~
lSSSJ
~
I"""'J
JE~0 )~ n J[3 ~~
~~ :#: :#:
Fig. I. Interrupt operations.
300
fl
trr.
~
, ~
output(s) writing (ASAP) CD input(s) reading
I§] TIme Stamp 0
-=-- AD Conversion
available. This delay, which may vary significantly, is added to the latency.
when a RTf parameter must be returned to the user. There is one aBuf for each KIT. User
When an interrupt or the RTK triggers an acquisition, the measured signals are read through the input ports such as AD converters. The duration of this operation depends on the converter's resolution. If there are more than one input signal, they have to be acquired simultaneously or nearly simultaneously. If there is no external interrupt, a time stamp 0 needs to be associated with each sample. This infonnation is retrieved from the RTC or from a dedicated timer. When using external interrupts, the time stamp is the interrupt ID number (position) multiplied by the sampling period. The time stamp is needed in case of a numerical differentiation occurring in the control algorithm, an operation for which time interval accuracy is critical. If the sampling period is much longer than the ISR duration (and the latency duration), the output signal(s) can be written as soon as possible (ASAP) 0 to the output port(s) such as a DA converter. If the ISR duration is close to the sampling period, the update of the output(s) should occur just before the next input reading (k+ 1) 4l!> by using the same interrupt.
/
I L . . . - _...... ___
" aBufPID
......
RT Kernel
---
Samples
---~ce~t1
Fig. 2. Data exchange mechanism. The user-defined real-time tasks are called by the RTK at each sampling period or at a multiple of the sampling period (subsampling). If there is more than one RTf defined for the same board, the RTK calls them in a pseudo-parallel fashion (Auslander, 1991). This simplifies the implementation of parallel or complex operations. In the example of single RTf performing a cascade control with two PIDs, the RTf can be split into two single PID controllers. In the same manner, subsampling allows two different tasks such as filtering and control to be called at different times. Instead of having the controller called at a faster than needed sampling rate in order to filter the input signal(s), these two operations are implemented in separate routines: the filtering operation which is perfonned at each sampling period, and the control operation which is called, for example, every twenty interrupts. The filtered signal is shared between the filter and the controller using the sBuf. This method lowers the processor's load and makes the RTf easier to write.
In contrast to data acquisition, control operations require output values to be computed and written to output ports at every sampling period. This removes the possibility of perfonning batch processing based on the data stored in the acquisition board buffer (if there is any). The RTK handles all 110 operations according to the user's preferences. The input and output data are stored in an internal buffer. This buffer (sBuf) is updated synchronously with each interrupt. When called by an interrupt, the RTK puts the new acquired values into the sBuf and then retrieves the value for the next outputs from the same sBuf. The sBuf can be partly or completely retrieved in order to be, for example, asynchronously displayed to the user. This data exchange mechanism is presented in Fig. 2.
The RTK is a low-level "application" requiring no user interface. In order to visualize the different data and manage the RTK, an application with a Graphical User Interface (GUI) is needed. In order to reduce the effort necessary to build a GUI, the commercial package LabVIEW (National Instruments) was chosen and used as described in Section 4.
Beside input and output data, other infonnation such as time stamps, execution errors, and virtual channels holding internal states of a controller are stored in the sBuf. There is one sBuf for each acquisition board; it is shared with all real-time tasks (RTf) running on the specified board.
4. INTEGRATION TO LABVIEW LabVIEW is a complete graphical environment designed to build Virtual Instruments (VIs) such as oscilloscopes, signal generators, etc. LabVIEW is designed for data acquisition and signal processing, but it has many multi-purpose libraries (files management, advanced mathematical functions, networking, etc.) covering most of today's users' needs. Hardware is very well integrated into Lab VIEW, and all the ne<::essary VIs to handle data acquisition are provided. This, along with an advanced graphical user interface, makes it very easy to use. Students can use it after an
When the user wants to modify a RTf parameter, the RTK must reflect this modification in real-time (interactivity). The user's parameters are transmitted asynchronously by the RTK to the RTf through a buffer. This asynchronous buffer (aBuf) is not updated at each interrupt, but only when a parameter is modified or
301
introduction of only 4 hours. LabVIEW is multiplatform and well spread in universities and industries.
The first step is the configuration of the RTFw environment. This is done in the "Environment Config." panel where the user defines the different default paths and selects the compiler used by the RTFw to compile the real-time tasks.
The Real-Time Kernel is managed through VIs that call a Lab VIEW external C code (Code Interface Node). The functionalities of the Real-time VIs (RT VIs) displayed in Fig. 3 are very similar to the Data Acquisition VIs (DAQ VIs) supplied with LabVIEW. There is one VI for each basic real-time operation.
In order to define the connections with the real process, the user has to configure the hardware via the "Hardware Config." panel (Fig. 5). The information required for each input or output channel is: the board slot, the channel position and name, the type of signal (analog, digital, ...), the 110 gain, the initial values for the inputs and the final values for the outputs. Virtual channels, which are similar to the input and output channels, need to be named and initialized. The interrupt-related parameters must then be defined. These parameters are the sampling period, the type of interrupt (internal, external), the type of output writing (ASAP, k+l). Finally, the synchronous buffer size must be defined.
.·. ..·.·.'•.
l~rtGll~II~ Hwd~ 5~~ ~ > ~' 1 !~~~II~ = li ·.. T. · .:. •~II.~ /·~.JDlb l Fig. 3. VIs to manage the RTK. The first operation is the hardware configuration. In the VI "RT Config Hwd", the user specifies the input and output channels, the sampling period, the type of interrupt and the size of the sBuf. The second operation, the software configuration, installs the user's real-time tasks on the specified board using the "RT Config Soft" VI. For each RTT, the size of the aBuf needs to be defined. Once the configuration is completed, the user can activate the RTK with the "RT Start" VI. While the RTK is running, the data (RTT parameters or acquired data) can be exchanged interactively between LabVIEW and the RTK. Different VIs built using the "RT Read Base" VI are available for the data exchange operations. When the real-time operations are completed, or when an execution error occurs, the RTK can be stopped via the "RT Stop" VI. Finally, the memory used by the different buffers is released via the "RT Clear" VI.
The next step is the writing of the real-time tasks. These tasks can be any real-time operations: control, on-line identification, filtering or real-time simulation. The real-time simulation is a specific task since it is important to validate a new control algorithm before testing it on the real process. Usually, the simulation is performed with specialized tools like Simulink (The MathWorks), where representations and operations differ from those found in implementation tools like Lab VIEW. In order to be able to focus on a single software package, the RTFw provides capabilities for both implementation and custom made simulation, thereby covering the important experimental steps in an integrated manner. The user can conduct both real and virtual experimentations concurrently, which can be useful to compare on-line real and simulated dynamical behaviors. As a consequence, the computational time required to integrate the mathematical model over a certain time horizon must be shorter than this horizon.
The RTK VIs allow the user to install one or more Real-Time Tasks. These tasks are Dynamic Linked Libraries (DLLs) written in C and built using a standard C compiler. To avoid having to worry about complex compiler environment issues, the compiler is controlled directly by the Real-Time Framework. 5. REAL-TIME FRAMEWORK The Real-Time Framework (RTFw) is a group of tools meant to cover the different development stages of a real-time task, typically the design and the implementation of a controller. From the real-time simulation of the system to the test on the real process, the user will only see the LabVIEW front-end of the RTFw. The other necessary applications, such as the compiler, are interfaced to LabVIEW by using an inter-application messaging protocol like AppleEvent on Mac or Dynamic Data Exchange (DDE) on PC.
In the RTFw, the user can define the model to be simulated in a general state space representation (set of nonlinear differential and algebraic equations). The number of inputs and outputs is taken from the number of input and output channels set for the acquisition in the "Hardware Config." panel. Numerical integration is performed using the traditional fixed-step fourth order Runge-Kutta algorithm. At run time, the user can choose between real-time simulation and real-time measurement, or select both.
The RTFw appears to the user in the form of a toolbar in which there is one button for each development stage (Fig. 4).
The writing of real-time tasks is entirely done within LabVIEW by using the "Software Config." panel (Fig. 6). The creation of a new RTT automatically creates the needed files and sets up the compiler preferences. If the user selects a real-time simulation, the RungeKutta integration library is added to the compiler project.
Fig. 4. Front-end of the real-time framework.
302
While writing the control algorithm, the user needs access to the current or previous data stored in both the aBuf and the sBuf. This is made possible by using functions provided in a library (Dahl, 1991). Trus library is defined for C, but could easily be defined for any other language supporting the Dynamic Link Library (DLL) mechanism. There are about fifteen functions to be called from the real-time task. Since mistakes made at an interrupt level are likely to result in a crash, preventive error checking is performed within the RTT routines, each of them returning an error code.
6. APPLICATION EXAMPLE This example shows the different relevant steps necessary to develop a PD controller to drive either the real process or the real-time simulation of an electrical drive controlled in position (i.e., a second-order system with an integrator). It is necessary to first define the hardware configuration. In this example, the MI016XL multipurpose board from National Instruments is used. The board generates interrupts wruch allow the controller to run with an accurate sampling period in the order of 1 ms. This performance can be acrueved thanks to the board pseudo-parallel scan mode, where inputs are acquired successively without delay. Tills board is available for both Mac and PC platforms.
When the edition of the RTT is completed, the compilation is performed in background. Tills process creates a DLL ready to be called by the RTK. The communication between Lab VIEW and the compiler is performed using predefined scripts. In case of compilation errors, they are returned to LabVIEW and graphically displayed in the "Software Config." panel.
A sampling period of 1 ms is selected. It is specified to output the control signal just before the next acquisition (at time k+l ). The 110 buffer (aBuf) is set to hold one second of data which correspond to 1000 samples per channel. The controller has two input channels, one for the reference value (channel 1) and one for the controlled value (channel 0). The control signal is written to the output channel O. For the real-time simulation, two virtual channels are used, one for the angular position and one for the angular velocity of the simulated electrical drive.
For each board, one or more RTT(s) can be selected in the "Software Config." panel. The subsampling and the size of the asynchronous Buffer (parameters buffer) need to be defined for each RTT. The last step before testing a newly created Real-Time Task(s) is the selection or the creation of the controller and its graphical user interface. This controller is written using Lab VIEW: it will call the different RTK VIs in order to set up, launch and stop the controller. More than one controller using the same DLL, but with a different GUI, can be developed. During the test phase, the GUI is dynamically launched from the RTFw. When the DLL and its GUI are completed, the RTFw is no longer needed. The real-time application can be saved in a stand-alone form and can work on its own. There are no royalties to be paid for stand-alone LabVIEW applications used in an academic environment.
_ _ ~
The next step is the creation of the two real-time tasks that are displayed and controlled within the "Software Config." panel (Fig 6). The first task, wruch will be called at each sampling period, is the real-time simulation of the electrical drive. The second task is the PD control. In order to include the Runge-Kutta integration library to the code, the Real-Time Simulation box in panel @ must be checked in the "Software Config." panel. To illustrate subsampling, the real-time simulation rou-
,.in
/ 1 9ft thrt control... from tht GUI pow.n;os ao /I idtfn dIIoriv.tion t"'"" , ~t pas . , / 1 r"'Nd tht ~tHt contron.d nlut fOfoftlS YI tht s8uf 11 r ....s tht \It Kt vab fN"d in ttw s:8uf 1/ computt. h «Tor b-.. on thrt> 1It.st ~ f~ in tN s8uf 11 proport;onol ..... 0( tho .......1 ~1 _ _......
... ...cO,&Kp); ......cl ,&Td) ; " Goto.(O);
"""''''...-.ct
V" ·Gtt~l) ;
Err-"'-\lr ; Up"I
I h;
SoUlut(o ,Up • Ud) ; prmrr " Err ;
rf'V"nno£l"T ;
Fig. 5. Hardware Config. Panel.
Fig. 6. Software Config. Panel.
303
11 ,.,t thrt ,...xt output .t petS -0 /1 M't -. thr 9lotMl .........lH for ttw MXt /1 no lfTor chrtdcin9
~n
tine is shown to run at twice the speed of the controller routine, allowing thereby the computation of intermediate simulation values.
7. CONCLUSIONS The Real-Time Framework proposed in this paper facilitates the writing (handling, implementation) of real-time applications. This framework, based on LabVIEW, allows the user to write the real-time algorithms in C. The high-level functions available to the user are similar to textbook pseudo-codes. Control algorithms as well as real-time simulations can be directly developed and tested from the framework, or run as stand-alone applications.
The management (add, remove, new) of real-time task(s) and the selection of the current RTf is defined in the upper left area
This framework has been successfully used by instructors to develop real-time virtual instruments for both students' laboratory works and more advanced research solutions (Gillet, et al., 1993), (Altpeter, et aI, 1995). The same framework has also been used by students to build their own real-time applications in semester and diploma projects.
Ill.
The model of the simulated system called by the Runge-Kutta real-time integration reads: l ong Moael(dx[] ,y [] ,x[],u[], kh ) (
REFERENCES
float A, T; GetParam(O , &A); II Get the static gain A GetParam(l , &T) ; II Get the t ime const . T dx [O ] = x[l ] ; dx [ l ] = - x [ l] I T + A * ufO] I T; y [O] = x [ O]; return NoError;
Altpeter F., C. Salzmann, D. Gillet, and R. Longchamp, (1995). "A General Instrument for Real-Time Control and Data Acquisition", The 3rd IFACIIFIP Workshop on Algorithms and Architectures for Real-Time Control, Ostend, Belgium.
When the DLLs for both the simulation and the control have been completed, the user builds the real-time application GUI with the large set of graphical objects provided by LabVIEW (Fig.7) The RTK VIs are used for writing the real-time application Diagram.
Auslander D. M. (1991). Control Implementation: Real Time Multi-taskinglMultiprocessing, IFAC, Advances in Control Education, Boston, USA. Dahl O. (1991). "An Interactive Environment for RealTime Implementation of Control Systems", IFAC Symposium on Computer Aided Design in Control Systems, Swansea, UK.
user interface update loop
Gillet D., R. Longchamp, and D. Bonvin, (1991). "Integrated Workbench for Laboratory Projects in Automatic Control", Int. Conf. on Computer Aided Learning and Instruction in Science and Engineering, Lausanne, Switzerland. Gillet D., C. Salzmann, R. Longchamp, and D. Bonvin, (1993). "A Methodology for Laboratory Development of Scientific Teachware with Application to Adaptive Control", American Control Conference, San Francisco, USA. Gillet D., G. F. Franklin, R. Longchamp, and D. Bonvin, (1994). "Introduction to Automatic Control via an Integrated Instruction Approach", The 3rd IFAC Symposium on Advances in Control Education, Tokyo, Japan.
Detail of the subsampling (2 x) effect
Fig. 7. Real-time application user interface and diagram. The user can execute its real-time application from within the RTFw. If there is more than one real-time application, the user has to select the desired GUI which is then dynamically launched from the RTFw.
dSPACE, 25505 W. Twelve Mile Road, Suite 2800, Southfield, MI 48034, USA, Fax: (810) 358-9692. National Instruments, http://www.natinst.com.
When the development step is completed, the realtime application can be saved in a stand alone form which can be freely distributed to the students.
The MathWorks Inc., http://www.mathworks.com.
304
FRAMEWORK FOR FAST REAL-TIME APPLICATIONS IN AUTOMATIC CONTROL EDUCATION Christophe Salzmann, Denis Gillet, Roland Longchamp, and Dominique Bonvin
lnstitut d 'Automatique (lA), Ecole Poly technique Federale de Lausanne (EPFL) CH - 1015 Lausanne, Switzerland, email: [email protected], WWW' http://iawww.epji.ch/
Abstract: This paper presents an integrated solution to develop fast real-time applications in an academic environment. The solution is based on a framework which guides the user through all the necessary steps: from the selection of a control solution to its real-time implementation and validation. With the proposed framework, students can concentrate on the control concepts. The difficult implementation aspects, such as the real-time programming and the hardware interfacing, are completely managed by the framework and transparent for the user. The framework user interface is well adapted to meet didactic requirements, and its ease of use leads to a reduced learning period. Copyright © 1998 !FAC Keywords: Education, Automatic Control, PD Controller, Real-Time Applications.
The RTFw described in this paper enables users to develop an application to drive a real process through an universal acquisition board. These components (realtime software, computer, acquisition board) compose the integrated workbench (Gillet, et aI. , 1995) used by the students to perform virtual and real experimentation (simulation and implementation).
I . INTRODUCTION Students in automatic control need to put the theory they learn during lectures into practice (Gillet, et aI., 1994), which includes experimentation on real processes and implementation of complete control solutions. This implementation can be difficult to present in lectures without reducing the time dedicated to the presentation of fundamental topics. As a matter of fact, implementing control solutions from scratch requires knowledge not only in automatic control but also in sensors technology and in computer engineering, such as hardware interfacing and real-time programming. These skills might not be previously mastered by students who take automatic control courses, since they usually have various engineering backgrounds. An integrated framework is provided to the students in order to combine theory study and implementation practice. This framework reduces the additional knowledge required to proceed with the implementation and helps students focus on essential concepts. This Real-Time Framework (RTFw) integrates the different steps, such as simulation and testing on the real process, necessary for developing control solutions. To be attractive to the students, the RTFw needs to be highly interactive and offer a well-designed graphical user interface. These conditions and price considerations make professional real-time development tools, such as dSPACE and the Real-Time Workshop (The MathWorks), inappropriate for educational purposes.
This paper is organized as follows : Section 2 gives an overview of the existing solutions to develop real-time applications. Section 3 describes the real-time kernel upon which the real-time framework relies. Section 4 shows the use of the real-time kernel within LabVIEW. Section 5 presents the real-time framework characteristics. Finally, an application example is given in Section 6, where the PD control and the real-time simulation of an electrical drive are implemented using the RTFw. 2. CURRENT SOLUTIONS Current solutions for real-time control applications can be divided into five categories: The first solution is the implementation of an analog controller. This means that only analog circuits are used to carry out the control job. The advantage of this solution lies in the fact that it can be used for fast processes whereas its lack of flexibility is the main disadvantage. The controller type is predefined and the user can only change parameters in a limited range.
299
With the second solution, parts of the analog circuits are replaced by a microprocessor. This type of controller is called a pseudo-analog controller. It possesses the same drawbacks as the first approach, except that the controller code can be changed by swapping the microprocessor ROM.
nel has been developed at the Institut d'automatique and integrated into the real-time framework . It is driven by interrupts generated either by the real-time clock (RTC) found on the motherboard (internal interrupt) or by a timer found on the acquisition board (external interrupt).
The third solution is based on Programmable Logic Controllers (PLC). This type of controller facilitates the implementation of more advanced solutions with a greater flexibility. It can also be supervised by another computer. The PLCs are widely spread in industry and can work in a stand-alone mode.
3. REAL-TIME KERNEL The real-time kernel (RTK) should be seen as a standalone background application which communicates through shared memory with the foreground application holding the user interface. The RTK has two main functions: the first is the communication with the real process via acquisition devices like AD & DA boards. The second is the management of the user's defined real-time tasks (RTT), which can be any type of timed operation such as real-time control, real-time simulation or on-line identification.
The fourth solution is to equip a personal computer with a dedicated board holding a specific processor such as a Digital Signal Processor (DSP). Compared to the previous approaches, this dedicated processor accepts more sophisticated controllers and advanced analysis algorithms. The dedicated board also hosts the I/O circuitry such as AD & DA converters. This expensive solution gives the user the opportunity to supervise the different development stages during controller design.
The RTK must be able to execute tasks repetitively at a fast and accurate timing. To achieve these performances, the RTK relies on interrupts 0 (see Fig.l). An interrupt is a unique or repetitive signal, generated by a device such as a timer. This signal tells the processor to stop the execution of the current process @, to save the current processor state, and to switch to a predefined routine called Interrupt Service Routine @) (ISR). When the ISR is completed, the processor restores the saved state and resumes the interrupted process O. The time between the interrupt occurrence and the start of the ISR is called latency 0. This time varies depending on the OS and the processor's current state.
With the fifth solution, the computer processor alone is used to run the controller algorithm. Today's computer processors are in some cases faster than specialized processors. The I/O operations are handled by an extra brainless acquisition board. This solution is wellsuited for education purposes because of its low cost and the possibility to reuse standard acquisition boards available in many laboratories. This paper presents the implementation of the fifth solution because of its advantage in an academic environment. This solution evolves around a personal computer used for performing other tasks, for example word processing. For such a versatile use, real-time Operating Systems (OS) cannot be considered. However, current personal OS like MacOS or Windows provide basic mechanisms to handle fast real-time operations. To expand those capabilities, a real-time ker-
Many of today's universal acquisition boards have the required timers and circuits to generate interrupts. The advantage of using external interrupts is that such signals can also trigger the acquisition of the data
'#;&' External interrupt @
i
I ,
I I
tI Interrupt 0
0
~~S]gJ35~\ S
E;:Sl
Current process @,O
RT Task #18, called every int.
EIll!3
RT Task #28
called every
2 int
c.. RT Task #38. issues the AD conversion and waits for the data 10 be available. TIle lighl gray pan represents time spenl for !he AD conversion.
Internal interrupt
~
lSSSJ
~
I"""'J
JE~0 )~ n J[3 ~~
~~ :#: :#:
Fig. I. Interrupt operations.
300
fl
trr.
~
, ~
output(s) writing (ASAP) CD input(s) reading
I§] TIme Stamp 0
-=-- AD Conversion
available. This delay, which may vary significantly, is added to the latency.
when a RTf parameter must be returned to the user. There is one aBuf for each KIT. User
When an interrupt or the RTK triggers an acquisition, the measured signals are read through the input ports such as AD converters. The duration of this operation depends on the converter's resolution. If there are more than one input signal, they have to be acquired simultaneously or nearly simultaneously. If there is no external interrupt, a time stamp 0 needs to be associated with each sample. This infonnation is retrieved from the RTC or from a dedicated timer. When using external interrupts, the time stamp is the interrupt ID number (position) multiplied by the sampling period. The time stamp is needed in case of a numerical differentiation occurring in the control algorithm, an operation for which time interval accuracy is critical. If the sampling period is much longer than the ISR duration (and the latency duration), the output signal(s) can be written as soon as possible (ASAP) 0 to the output port(s) such as a DA converter. If the ISR duration is close to the sampling period, the update of the output(s) should occur just before the next input reading (k+ 1) 4l!> by using the same interrupt.
/
I L . . . - _...... ___
" aBufPID
......
RT Kernel
---
Samples
---~ce~t1
Fig. 2. Data exchange mechanism. The user-defined real-time tasks are called by the RTK at each sampling period or at a multiple of the sampling period (subsampling). If there is more than one RTf defined for the same board, the RTK calls them in a pseudo-parallel fashion (Auslander, 1991). This simplifies the implementation of parallel or complex operations. In the example of single RTf performing a cascade control with two PIDs, the RTf can be split into two single PID controllers. In the same manner, subsampling allows two different tasks such as filtering and control to be called at different times. Instead of having the controller called at a faster than needed sampling rate in order to filter the input signal(s), these two operations are implemented in separate routines: the filtering operation which is perfonned at each sampling period, and the control operation which is called, for example, every twenty interrupts. The filtered signal is shared between the filter and the controller using the sBuf. This method lowers the processor's load and makes the RTf easier to write.
In contrast to data acquisition, control operations require output values to be computed and written to output ports at every sampling period. This removes the possibility of perfonning batch processing based on the data stored in the acquisition board buffer (if there is any). The RTK handles all 110 operations according to the user's preferences. The input and output data are stored in an internal buffer. This buffer (sBuf) is updated synchronously with each interrupt. When called by an interrupt, the RTK puts the new acquired values into the sBuf and then retrieves the value for the next outputs from the same sBuf. The sBuf can be partly or completely retrieved in order to be, for example, asynchronously displayed to the user. This data exchange mechanism is presented in Fig. 2.
The RTK is a low-level "application" requiring no user interface. In order to visualize the different data and manage the RTK, an application with a Graphical User Interface (GUI) is needed. In order to reduce the effort necessary to build a GUI, the commercial package LabVIEW (National Instruments) was chosen and used as described in Section 4.
Beside input and output data, other infonnation such as time stamps, execution errors, and virtual channels holding internal states of a controller are stored in the sBuf. There is one sBuf for each acquisition board; it is shared with all real-time tasks (RTf) running on the specified board.
4. INTEGRATION TO LABVIEW LabVIEW is a complete graphical environment designed to build Virtual Instruments (VIs) such as oscilloscopes, signal generators, etc. LabVIEW is designed for data acquisition and signal processing, but it has many multi-purpose libraries (files management, advanced mathematical functions, networking, etc.) covering most of today's users' needs. Hardware is very well integrated into Lab VIEW, and all the ne<::essary VIs to handle data acquisition are provided. This, along with an advanced graphical user interface, makes it very easy to use. Students can use it after an
When the user wants to modify a RTf parameter, the RTK must reflect this modification in real-time (interactivity). The user's parameters are transmitted asynchronously by the RTK to the RTf through a buffer. This asynchronous buffer (aBuf) is not updated at each interrupt, but only when a parameter is modified or
301
introduction of only 4 hours. LabVIEW is multiplatform and well spread in universities and industries.
The first step is the configuration of the RTFw environment. This is done in the "Environment Config." panel where the user defines the different default paths and selects the compiler used by the RTFw to compile the real-time tasks.
The Real-Time Kernel is managed through VIs that call a Lab VIEW external C code (Code Interface Node). The functionalities of the Real-time VIs (RT VIs) displayed in Fig. 3 are very similar to the Data Acquisition VIs (DAQ VIs) supplied with LabVIEW. There is one VI for each basic real-time operation.
In order to define the connections with the real process, the user has to configure the hardware via the "Hardware Config." panel (Fig. 5). The information required for each input or output channel is: the board slot, the channel position and name, the type of signal (analog, digital, ...), the 110 gain, the initial values for the inputs and the final values for the outputs. Virtual channels, which are similar to the input and output channels, need to be named and initialized. The interrupt-related parameters must then be defined. These parameters are the sampling period, the type of interrupt (internal, external), the type of output writing (ASAP, k+l). Finally, the synchronous buffer size must be defined.
.·. ..·.·.'•.
l~rtGll~II~ Hwd~ 5~~ ~ > ~' 1 !~~~II~ = li ·.. T. · .:. •~II.~ /·~.JDlb l Fig. 3. VIs to manage the RTK. The first operation is the hardware configuration. In the VI "RT Config Hwd", the user specifies the input and output channels, the sampling period, the type of interrupt and the size of the sBuf. The second operation, the software configuration, installs the user's real-time tasks on the specified board using the "RT Config Soft" VI. For each RTT, the size of the aBuf needs to be defined. Once the configuration is completed, the user can activate the RTK with the "RT Start" VI. While the RTK is running, the data (RTT parameters or acquired data) can be exchanged interactively between LabVIEW and the RTK. Different VIs built using the "RT Read Base" VI are available for the data exchange operations. When the real-time operations are completed, or when an execution error occurs, the RTK can be stopped via the "RT Stop" VI. Finally, the memory used by the different buffers is released via the "RT Clear" VI.
The next step is the writing of the real-time tasks. These tasks can be any real-time operations: control, on-line identification, filtering or real-time simulation. The real-time simulation is a specific task since it is important to validate a new control algorithm before testing it on the real process. Usually, the simulation is performed with specialized tools like Simulink (The MathWorks), where representations and operations differ from those found in implementation tools like Lab VIEW. In order to be able to focus on a single software package, the RTFw provides capabilities for both implementation and custom made simulation, thereby covering the important experimental steps in an integrated manner. The user can conduct both real and virtual experimentations concurrently, which can be useful to compare on-line real and simulated dynamical behaviors. As a consequence, the computational time required to integrate the mathematical model over a certain time horizon must be shorter than this horizon.
The RTK VIs allow the user to install one or more Real-Time Tasks. These tasks are Dynamic Linked Libraries (DLLs) written in C and built using a standard C compiler. To avoid having to worry about complex compiler environment issues, the compiler is controlled directly by the Real-Time Framework. 5. REAL-TIME FRAMEWORK The Real-Time Framework (RTFw) is a group of tools meant to cover the different development stages of a real-time task, typically the design and the implementation of a controller. From the real-time simulation of the system to the test on the real process, the user will only see the LabVIEW front-end of the RTFw. The other necessary applications, such as the compiler, are interfaced to LabVIEW by using an inter-application messaging protocol like AppleEvent on Mac or Dynamic Data Exchange (DDE) on PC.
In the RTFw, the user can define the model to be simulated in a general state space representation (set of nonlinear differential and algebraic equations). The number of inputs and outputs is taken from the number of input and output channels set for the acquisition in the "Hardware Config." panel. Numerical integration is performed using the traditional fixed-step fourth order Runge-Kutta algorithm. At run time, the user can choose between real-time simulation and real-time measurement, or select both.
The RTFw appears to the user in the form of a toolbar in which there is one button for each development stage (Fig. 4).
The writing of real-time tasks is entirely done within LabVIEW by using the "Software Config." panel (Fig. 6). The creation of a new RTT automatically creates the needed files and sets up the compiler preferences. If the user selects a real-time simulation, the RungeKutta integration library is added to the compiler project.
Fig. 4. Front-end of the real-time framework.
302
While writing the control algorithm, the user needs access to the current or previous data stored in both the aBuf and the sBuf. This is made possible by using functions provided in a library (Dahl, 1991). Trus library is defined for C, but could easily be defined for any other language supporting the Dynamic Link Library (DLL) mechanism. There are about fifteen functions to be called from the real-time task. Since mistakes made at an interrupt level are likely to result in a crash, preventive error checking is performed within the RTT routines, each of them returning an error code.
6. APPLICATION EXAMPLE This example shows the different relevant steps necessary to develop a PD controller to drive either the real process or the real-time simulation of an electrical drive controlled in position (i.e., a second-order system with an integrator). It is necessary to first define the hardware configuration. In this example, the MI016XL multipurpose board from National Instruments is used. The board generates interrupts wruch allow the controller to run with an accurate sampling period in the order of 1 ms. This performance can be acrueved thanks to the board pseudo-parallel scan mode, where inputs are acquired successively without delay. Tills board is available for both Mac and PC platforms.
When the edition of the RTT is completed, the compilation is performed in background. Tills process creates a DLL ready to be called by the RTK. The communication between Lab VIEW and the compiler is performed using predefined scripts. In case of compilation errors, they are returned to LabVIEW and graphically displayed in the "Software Config." panel.
A sampling period of 1 ms is selected. It is specified to output the control signal just before the next acquisition (at time k+l ). The 110 buffer (aBuf) is set to hold one second of data which correspond to 1000 samples per channel. The controller has two input channels, one for the reference value (channel 1) and one for the controlled value (channel 0). The control signal is written to the output channel O. For the real-time simulation, two virtual channels are used, one for the angular position and one for the angular velocity of the simulated electrical drive.
For each board, one or more RTT(s) can be selected in the "Software Config." panel. The subsampling and the size of the asynchronous Buffer (parameters buffer) need to be defined for each RTT. The last step before testing a newly created Real-Time Task(s) is the selection or the creation of the controller and its graphical user interface. This controller is written using Lab VIEW: it will call the different RTK VIs in order to set up, launch and stop the controller. More than one controller using the same DLL, but with a different GUI, can be developed. During the test phase, the GUI is dynamically launched from the RTFw. When the DLL and its GUI are completed, the RTFw is no longer needed. The real-time application can be saved in a stand-alone form and can work on its own. There are no royalties to be paid for stand-alone LabVIEW applications used in an academic environment.
_ _ ~
The next step is the creation of the two real-time tasks that are displayed and controlled within the "Software Config." panel (Fig 6). The first task, wruch will be called at each sampling period, is the real-time simulation of the electrical drive. The second task is the PD control. In order to include the Runge-Kutta integration library to the code, the Real-Time Simulation box in panel @ must be checked in the "Software Config." panel. To illustrate subsampling, the real-time simulation rou-
,.in
/ 1 9ft thrt control... from tht GUI pow.n;os ao /I idtfn dIIoriv.tion t"'"" , ~t pas . , / 1 r"'Nd tht ~tHt contron.d nlut fOfoftlS YI tht s8uf 11 r ....s tht \It Kt vab fN"d in ttw s:8uf 1/ computt. h «Tor b-.. on thrt> 1It.st ~ f~ in tN s8uf 11 proport;onol ..... 0( tho .......1 ~1 _ _......
... ...cO,&Kp); ......cl ,&Td) ; " Goto.(O);
"""''''...-.ct
V" ·Gtt~l) ;
Err-"'-\lr ; Up"I
I h;
SoUlut(o ,Up • Ud) ; prmrr " Err ;
rf'V"nno£l"T ;
Fig. 5. Hardware Config. Panel.
Fig. 6. Software Config. Panel.
303
11 ,.,t thrt ,...xt output .t petS -0 /1 M't -. thr 9lotMl .........lH for ttw MXt /1 no lfTor chrtdcin9
~n
tine is shown to run at twice the speed of the controller routine, allowing thereby the computation of intermediate simulation values.
7. CONCLUSIONS The Real-Time Framework proposed in this paper facilitates the writing (handling, implementation) of real-time applications. This framework, based on LabVIEW, allows the user to write the real-time algorithms in C. The high-level functions available to the user are similar to textbook pseudo-codes. Control algorithms as well as real-time simulations can be directly developed and tested from the framework, or run as stand-alone applications.
The management (add, remove, new) of real-time task(s) and the selection of the current RTf is defined in the upper left area
This framework has been successfully used by instructors to develop real-time virtual instruments for both students' laboratory works and more advanced research solutions (Gillet, et al., 1993), (Altpeter, et aI, 1995). The same framework has also been used by students to build their own real-time applications in semester and diploma projects.
Ill.
The model of the simulated system called by the Runge-Kutta real-time integration reads: l ong Moael(dx[] ,y [] ,x[],u[], kh ) (
REFERENCES
float A, T; GetParam(O , &A); II Get the static gain A GetParam(l , &T) ; II Get the t ime const . T dx [O ] = x[l ] ; dx [ l ] = - x [ l] I T + A * ufO] I T; y [O] = x [ O]; return NoError;
Altpeter F., C. Salzmann, D. Gillet, and R. Longchamp, (1995). "A General Instrument for Real-Time Control and Data Acquisition", The 3rd IFACIIFIP Workshop on Algorithms and Architectures for Real-Time Control, Ostend, Belgium.
When the DLLs for both the simulation and the control have been completed, the user builds the real-time application GUI with the large set of graphical objects provided by LabVIEW (Fig.7) The RTK VIs are used for writing the real-time application Diagram.
Auslander D. M. (1991). Control Implementation: Real Time Multi-taskinglMultiprocessing, IFAC, Advances in Control Education, Boston, USA. Dahl O. (1991). "An Interactive Environment for RealTime Implementation of Control Systems", IFAC Symposium on Computer Aided Design in Control Systems, Swansea, UK.
user interface update loop
Gillet D., R. Longchamp, and D. Bonvin, (1991). "Integrated Workbench for Laboratory Projects in Automatic Control", Int. Conf. on Computer Aided Learning and Instruction in Science and Engineering, Lausanne, Switzerland. Gillet D., C. Salzmann, R. Longchamp, and D. Bonvin, (1993). "A Methodology for Laboratory Development of Scientific Teachware with Application to Adaptive Control", American Control Conference, San Francisco, USA. Gillet D., G. F. Franklin, R. Longchamp, and D. Bonvin, (1994). "Introduction to Automatic Control via an Integrated Instruction Approach", The 3rd IFAC Symposium on Advances in Control Education, Tokyo, Japan.
Detail of the subsampling (2 x) effect
Fig. 7. Real-time application user interface and diagram. The user can execute its real-time application from within the RTFw. If there is more than one real-time application, the user has to select the desired GUI which is then dynamically launched from the RTFw.
dSPACE, 25505 W. Twelve Mile Road, Suite 2800, Southfield, MI 48034, USA, Fax: (810) 358-9692. National Instruments, http://www.natinst.com.
When the development step is completed, the realtime application can be saved in a stand alone form which can be freely distributed to the students.
The MathWorks Inc., http://www.mathworks.com.
304