Virtual Test Bed

    The VTB supports multi-lingual and interactive simulations as well as advanced visualization techniques. Multi-lingual capabilities of the VTB include interfaces with Matlab/Simulink, Labview, ACSL. These interfaces are highly beneficial in many aspects including development, implementation and rapid prototyping of various control algorithms at all levels from low level device controllers to high level system or decision-making controllers.

    Advanced 3-D visualization and animation capability is invaluable for quick and precise comprehension of the simulation data. The visualization objects are linked to the real time simulation processes. Two-way communication between the visualization and simulation yields highly interactive simulation. For example, power converter modules can be turned “on” or “off” from within the visualization environment during simulation run-time. This action changes the circuit topology during the simulator run-time, which results in interactive simulation that closely models the behavior of a realistic physical system.

    The most significant features of the Virtual Test Bed software include:
 

    A system is assembled by a drag and drop approach, selecting objects from the model library. Model objects are not limited to the electrical discipline, but can instead be defined in other disciplines such as mechanical, fluid, thermal and so forth. Interconnection ports can be of type “natural” or “signal”. The independent model format of the environment allows the model library to be upgraded independently from the other parts of the software. Furthermore, each object can use or define its own computational processes internally, reporting back to the structured environment only the minimal data necessary to solve for the behavior of the interconnected system.

    Models can have multiple “layers”, which may correspond to different views and/or to different mathematical representations. In the simplest implementation, the same object could be represented in different colors corresponding to a state or variable within the model. In more sophisticated implementations, the different layers can correspond to different levels of complexity in the model or to different forms of representation. Examples of the first case include representation of a power converter at three levels of detail such as 1) switching average model, 2) switching model with ideal switch, 3) switching model with non-ideal switch. Examples of the second case include showing power system entities in one-line representation or in 3-phase representation.

    The architecture of the VTB requires that models be provided as dynamically linked software objects. Exposed user parameters can be adjusted during simulation runtime, either through dialog boxes or via controls (such as sliders) in the graphical output environment. This allows efficient human interaction with the simulation, which leads to quick assimilation of parametric dependencies.

    The graphical output environment, VXE (Visualization eXtension Engine), allows the user to rapidly comprehend system performance. Visual outputs include data-driven animations of object motions, imposition of novel representations of abstract simulation data on top of solid objects, or just oscilloscope-like graphs. Bi-directional communication paths between the graphics environment and the simulation environment allow objects in the graphical environment to control parameters in the simulation environment, and vice-versa.

    Besides electric system objects, models within the VTB environment can represent any object where natural coupling laws apply. Generally lumped element models are used, but otherwise more complex models such as finite element models can be used. For example, the software is heavily used on projects that include fluid and thermal analyses such as fuel cell systems.

    When running under the Windows operating system, the software allows human interaction at arbitrary simulation speeds, either faster or slower than clock time depending on the capabilities of the processor, the complexity of the problem, and the nominal time step. For systems that are capable of running faster than real time, a soft real time option can be invoked that forces the simulation speed to correspond with clock time. This soft real time feature is useful to make the interaction and visualization appear realistic when a simulation is driving animations that require operator interaction.

    Hard real time operation with fast time resolution can be achieved by running the simulation under a Linux operating system with real time controls. Running under such a system is as easy as defining the system on a computer that runs the Windows operating system, then saving the system definition file (*.vts) to a mapped network drive on the Linux computer. Starting the simulation on the Linux computer (by reading the *.vts file) allows the simulation to interact with external hardware – either digital equipment (which we call “processor in the loop”, or analog equipment (which we call “power in the loop”. “Processor in the loop” is valuable for rapid prototyping of digital controls, while “power in the loop” is valuable for incremental virtual prototyping – incremental substitution of real hardware for components of the simulation model. This incremental substitution of real hardware allows one to test the overall system with the best possible representations of the immediately available system components – the components themselves!

    Interface objects allow the VTB solver to co-simulate with other executable objects, which can be stand-alone code or other user software. Two particularly valuable environments are the Matlab/Simulink environment and the Advanced Continuous Simulation Language environment. The Simulink interface is available in two forms – one which allows co-simulation with the Simulink engine and hence requires the simulationist to own a Matlab/Simulink license and another which allows co-simulation with a compiled form of the model, which does not require the simulationist to own a form of the model. The compiled form of the model is exported from Simulink using the toolset from the RealTime Workshop, and then automatically compiled into a VTB model by specifying an icon, etc.

<< Back <<