High Level Virtual Prototyping with Hardware in the Loop

International Workshop on Virtual and Intelligent Measurement Systems29-30 April 2000, Annapolis, MD, USAHigh Level Virtual Prototyping with Hardware in the LoopA. Monti ( + ), R. Dougal ( ++ ), B. Pettus ( ++ ), E. Santi ( ++ )( + ) Dip. di Elettrotecnica, Politecnico di Milano, Milano, Italy( ++ ) Dep. of Electrical Engineering, University of South Carolina, Columbia (SC), USAAbstractVirtual prototyping of complex systems presents interestingchallenges, especially with regard to systems in whichsome components are represented by software models andothers are present as real hardware. We describe here oneapproach to solving such a problem. In this instance, twomotors were controlled by a dSpace general-purposecontroller board that was coupled to the Virtual Test Bedsoftware environment for system simulation.I. IntroductionSimulation of complex systems where manycomponents interact presents peculiar challenges. Considerthat a particular system might be analyzed differently bydifferent users, each one of them focusing on a differentaspect of the system performance and each one having adifferent metric for what is important. Consider that thecomplexity of the system may bridge several areas oftechnical expertise, and that users in each of thosetechnical areas traditionally work with their own set ofdesign and simulation tools. Consider also that some partsof the system may be already available while other partsare still being designed. To the extent possible, one maywish to substitute real components for their models everytime that a new component becomes available. Such anapproach keeps the design/simulation "alive", promotesiteration, allows an opportunity to validate models, andintroduces at the earliest possible time potentiallycomplicating nuances that were not originally accountedfor in the component models. The cost of this approach isthat it requires a sophisticated capability for working withHardware In the Loop (HIL) [1-2]. All of theseconsiderations suggest the desirability of a new high-levelinterface that allows many types of users to be comfortablewith the virtual prototyping tool. An attempt to developsuch a tool has been underway at the University of SouthCarolina for several years now under the program nameVirtual Test Bed. We have just recently begun the processof incorporating hardware in the loop.II.The VTB ProjectThe Virtual Test Bed (VTB) is software for virtualprototyping of multi-technical dynamic systems. Withinthe context of "virtual prototyping" we include not onlysimulation of system dynamics, but also solid modeling ofthe system, and visualization of the system dynamics. Oneof the project goals is to extend the context of virtualprototyping to include operation of hybrid systems --where some of the parts exist as real hardware and otherparts exist as simulation models. The work reported in thispaper focuses on our approach to achieving that goal. Tobetter understand the context of our work, we present firstan overview of the Virtual Test Bed projectThe Virtual Test Bed project is dedicated to developing anew environment for simulation and virtual prototyping ofpower electronic systems [3-4]. One of its challenges is tofully accommodate the breadth of disciplines that powerelectronics encompasses, including analog electronics,digital electronics, power systems, controls, electromechanics,and mechanical systems. We have addressedthese challenges by choosing to support:Multiformalism: Different languages can be use to buildmodels of the different components that make up a system.This allows an individual to build models using thelanguage preferred within his or her discipline. Inparticular the system now integrates dynamic modelsdefined by such widely used tools such asMatlab/Simulink, SPICE, and ACSL [5-7-8].Highly interactive environment: Users can change thesystem topology or parameters while a simulationexecutes. This allows the user to rapidly investigateinteractions between components or to explore theinfluence of design parameters on system performance.High-level visualization: Visualization models of thesystem can be easily created and linked to live simulation

data. Visualization aids the user to rapidly comprehend thesystem performance. Visual outputs include data-drivenanimation of the motion of solid objects, imposition on topof the solid objects of novel representations of abstractsimulation data, or simply oscilloscope-like graphs.Distributed computation: Large or complicated systemsrequire that computational load be distributed across anetwork in order to achieve speeds suitable for interactiveexplorations. This naturally supports hardware-in-the-loopoperations.The structure here introduced is well summarized in Figure1. Let us now go into details about the component structureto better appreciate the system design.PC1VTBSocketPC2DOSMatlab EngineThe VTB has other significant strengths, includingautomatic enforcement of physical constraints (such asensuring that the sum of currents at a node is zero).MatlabPC busDspaceBoardIII.Demonstration SystemOur HIL capability was developed with reference to aspecific laboratory setup so as to focus our effort and toallow immediate testing of the system. The hardwaresystem amounted to a two-axis DC motor drive. Ourinterest was in designing the higher-level logic to controlthe motors in coordination with software models of othercomponents of the system. Working in this way, we wereable to directly verify the consequences of the commandsignals sent to the drive and to use a real oscilloscope toobserve the system operation. At the same time, theadvanced visualization capabilities of the Virtual Test Bedshowed on a PC screen the operation of the entire system.The motor control system was based on a dSpace board[9], which could be easily programmed usingMatlab/Simulink. The authors added a custom interface toMatlab to exchange data with the control board working inreal time. The system is based on the Matlab Engine [6]interface and allows one to send data to and receive datafrom the Matlab workspace. A set of custom Matlabcommands (developed by the authors) allowscommunication with the real time dSpace board. The dataexchange with VTB was implemented via a socketcommunication channel. This arrangement allows havingVTB and the dSpace board running on differentcomputers, if so desired. This feature adds flexibility to thevirtual simulation environment.From the VTB point of view, the external system is adevice that receives virtual data from the simulationenvironment and that sends back real data from thehardware environment. This is reasonably transparent tothe user, who has only to define the parameters for thesocket communication (the name of the PC having theDSP board) and the number of the input/output channel. Inthe demonstration case two data are sent from thesimulation environment to the hardware (the two axisposition references) and two are sent back from thehardware to the simulation environment (the real positionof the two motors).Digital and Analog I/OControlledFigure 1: Diagram of the HIL system, includingtwo motor drives, the interfaces, the PC and theDSPACE boardIV.The Matlab-dSPACE InterfaceThe heart of the communication protocol with thedSPACE board is the Matlab engine. The Matlab engineallows data exchange between Matlab and C customsoftware.The main program is a DOS application running on thePC connected to the dSPACE system. The structure of theapplication is well summarized in the following:• wait for VTB startup• start Matlab Engine• set up the communication with Matlab defining the setof shared data• select the dSpace board to be used in the experiment• wait for VTB dataAt every cycle the following set of operations isperformed:• send the data from VTB to dSpace system using theMatlab engine• acquire from dSPACE the feedback data• send the feedback data through the socketcommunication channel to VTBThis set of data exchange is guaranteed thanks to a set ofuser defined new Matlab commands that run through theMatlab engine:HW

• [xf, yf] = placexy(x,y): it sends the new reference xand y to the motor controllers and receives back thereal xf and yf position• enable_motor(num): it enables the position and speedcontrol of the motor num• disable_motor(num):it disables the position and speedcontrol of the motor numThe gun visualization is shown in Figure 2. The gunangular position and pitch are given by the actual angularposition of the two motors. VTB receives the actual motorposition from the dSpace board and animates the gun. Thegun itself is placed aboard the ship shown in Figure 3. Thereference angle for the two motors could come from theposition of an “enemy” airplane, which could also be partof the VTB visualization.V. The VTB Interface and VisualizationCapabilityVTB allows advanced data visualization. The purpose is tohelp the user understand the simulation results and to putthem in a visual form that may be more familiar andmeaningful to the user. In particular VTB allows datadrivenanimations. In the case of the two-axis motorcontrol presented here, an animation has been implementedshowing a possible application of the two-axis motorcontroller. The application is the two-axis position controlof a gun in a ship.Figure 2: VTB visualization of a gun whoseposition is controlled by the two-axis motorsystem. The gun is aboard a ship.åFigure 3: VTB visualization of the ship carryingthe gun. The arrow shows the position of the gun.VI. The Distributed Environment andNetwork SupportCommunication at the computer-to-computer level (PC1 toPC2 in figure 1) is handled by use of Windows/NTsockets. This is a generic technique and functionalequivalents exist for other environments. The connectionto the individual PC’s is a 10 Mbit Ethernet, creating apotential bottleneck although the highest communicationbandwidth achieved in our system is currently only onethird of the available network bandwidth (in the best caseof unidirectional communication from VTB to the dSpaceboard). However, the variable latency times are potentiallymore troublesome than the bandwidth. A next -generationversion of the system will have a dedicated connection,resulting in predictable performance.It is possible to compensate for some of the effects of(variable) delays in the network. For instance, there are anumber of distributed clock algorithms that can keep localclocks synchronized in the presence of significant networkdelays. Reference [10] has a good discussion of thesealgorithms. Current network response times are sufficientfor distributed large subsystems having slow responsetimes but improvements may be needed for device-levelconnections having faster response times.VII.ResultsThe data protocol has been implemented and tested.Figure 4 shows an interesting result. The position of onemotor is fed to the horizontal input of the oscilloscope,while the position of the other motor is fed to the verticalinput. A VTB model running on another computergenerates the reference signals for these movements.Figure 5 shows the commanded position and actualposition of one motor. The delay is two VTB time steps.This can be seen from the figure: the commanded positionat time step #171 has a numerical value of 106.393 and theactual position reaches a value close to it (106.535) at timestep #173.The delay is mostly due to network delay. This can beseen from Figure 6, which shows the actual motor positionand the commanded motor position measured at the DSPboard. This allows looking at the motor controller response

time separately from the network delay: the dSpace boardreceives the new commanded position and the controlleradjusts the actual motor position to follow it. The twowaveforms are substantially in phase, which indicates thatthe delay measured by VTB (Figure 5) is due to thenetwork connection. The response time to a step referencechange of the dSpace position controller is approximately120ms.The communication bandwidth is approximately threedata points per second in the case of bi-directionalcommunication between VTB and the dSpace board. In thecase of unidirectional communication (no real position sentback to VTB) the speed was approximately twenty timeshigher. At this point the reason for this deterioration ofcommunication speed in the case of bi-directionalcommunication is not clear.Figure 6: Oscilloscope measurement showingactual motor position in the upper trace andcommanded position in the lower trace (timescale 2s/div).Attempts to speed up communication are under way. Apromising approach is opening a direct communicationchannel between VTB and the dSpace board bypassingMatlab (see Figure 1).Figure 4: The real position of the motor as shownin x-y mode in the scope (the position referencecame from the VTB model)Figure 5: Commanded position and actualposition of one of the motors as visualized byVTB. The actual position is delayed with respectto the commanded position by two time steps.VIII. ApplicationsThe HIL experience here described is a starting pointfor a wider experience in VTB project. New features willbe added to automate the interface between any plant partand the simulator.The principle of the VTB design approach, withreference to HIL, could be summarized as follows:• at the beginning of the project nothing is availableso that a complete virtual model is compulsory• during the project, as soon as a part is available,define the interface, and substitute the virtualmodel with the real plantThis should guarantee that any subsystem of a complexpart is developed with an appropriate interface with therest of the system.Furthermore, the realized system is also extremelyinteresting from the didactic point of view. In effect, itallows a group of students to share among themselves asingle remote real platform. Students can design anddevelop a system using only virtual prototypes, then, whenthe simulation is completely working, they can substitutethe virtual prototypes with real hardware accessed througha network connection.An interesting example has been already developedwith reference to the current application.

As discussed above, the system implemented includestwo DC motors with position control. The complete systemhas been modeled with Simulink before theimplementation. Only the speed and position control hasbeen at the end downloaded on the dSPACE board.This procedure suggests a set of exercises for studentthat will be applied in the Electrical Drive course atPolitecnico di Milano:• development of a suitable model starting from plantspecification• tuning of the speed control• design of the position control using pole placementapproach• design of coordinated trajectories on a two axis controlLet us focus, e.g., on the third example that has beenalready defined in details.Starting from the project specification a detailed modelof the control can be defined in terms of transfer function.Applying the control theory the controller transfer functioncan be calculated.The theory can then experimentally verified:• program VTB to define a reference trajectory• download the new control using the obtained transferfunction• start VTB and dSPACE system analyzing the positionevolution both graphically and visuallyThis could be considered a first test: then the studentcould check the control parameter sensitivity synthesizingdifferent controllers starting form wrong plant parameterspecification. The procedure is really simple andcompletely automated and allows the student to set-up asequence of experiments in a very short time.Thanks to the network distributed characteristics of theapplication, in a short time the experiment will be includedin a Virtual Laboratory structure so that students wouldaccess the laboratory at any time from the universitynetwork for the practical tests.IX.Further DevelopmentsTwo further developments are under consideration atthe moment:• the DSPACE board can be used not only as aninterface to control systems but also as a generalpurpose data acquisition board. For this reason theauthors are working to define advanced Matlabcommands to make communication easier and moreflexible• at the moment Matlab acts as a bottleneck on thecommunication protocol. The authors are working onthe possibility to directly communicate with thedSPACE board at low level. This should improve thetotal throughput and the simulation performance.X. ACKNOWLEDGMENTThis work was supported in part by the Office of NavalResearch under Grant N00014-96-1-0926. The activity ofthe first author has been partially supported by C.N.R. (theItalian Council for Research) inside the initiative ShortTerm Mobility for Researchers. The help of Teems Lovettand Bill Mckay from the University of South Carolina inthe implementation of the network communicationsoftware is gratefully acknowledged. The help ofFerdinanda Ponci in the hardware realization is alsogratefully acknowledged.REFERENCE[1] Carmeli, S., Castelli Dezza, F., Monti, A., “A new platformfor real time testing of electrical drive digital control”, IEEECOMPEL 98, 19-22 July 1998, Como (Italy)[2] De Paola, E., Marina, G., Monti, A., Tramalloni, L., "Afrequency analysis method for real-time simulation", EPE99,Lausanne (CH), September 1999[3] Beker, B.; Hudgins, J.L.; Coronati, J.; Gillett, B.; Shekhawat,S., Extraction of parasitic circuit elements in a PEBB forapplication in the virtual test bed, Industry ApplicationsConference, 1997. Thirty-Second IAS Annual Meeting, IAS'97., Conference Record of the 1997 IEEE Volume: 2 ,Page(s): 1217 -1221 vol.2[4] Gokdere, L.U.; Brice, C.W.; Dougal, R.A., Graphical andvisual simulation of electric drive systems , Electric Machinesand Drives, 1999. International Conference IEMD '99,Page(s): 685 -687[5] MGA Software, "ACSL Model, ACSL reference manual",1995 (for more details see http://www.acslsim.com/)[6] The Mathworks, "Matlab: Application Program InterfaceGuide", 1996 (for more details seehttp://www.mathworks.com/)[7] The Mathworks, "Simulink: User Guide", 1998[8] Microsim, "PSPICE A/D Simulator User Guide", 1997 (formore details see http://pcb.cadence.com/)[9] dSpace, "Matlab Interface and Trace Library", 1999 (for moredetails see http://www.dspaceinc.com/)[10] Shem-Tov Agrawala, Ashok K., Levi “Real-Time SystemDesign”, McGraw-Hill, 1990.