Actually we do have a client requirement of designing a Hardware-in-the-loop simulator. the Client is a market giant in the mineral ore drilling industryand they want the “HWIL” simulator for their drill Rigs. They do have a Linux based DAS( drill Rig Automation System) with all the I/os controlled by the same. Our challenge is to develop a “HWIL” simulation application and hook it up with their DAS.

CAn any one help me in understanding the different s/w packages which can be used for the purpose, we are considering the Math works Simulink kind of softwares but have a very limited knowledge about the same. so can any one help us out in understanding like how to use different software packages available to serve the purpose.

To test and verify the design, we use a layered test strategy. At the lowest level, static analysis and simulaton are employed, to validate algorithms and local functional behavior. This is done by the developer, using a software simulator on pieces of the compiled code, to catch basic design flaws and complex detailed interrupt and low-level behavior.
After this level, the system is tested directly in hardware.

As you said, hardware-in-the-loop simulation and testing is a very ad-hoc and broad field.
We use several automated simulation engines, made in-house, to exercise and simulate complex scenarios on the fieldbus ports. These tests use PLCs programmed with command test sequences, with capability to perform random sequences and detect and capture unexpected responses. Usually these are performed on the complete system, sometimes with realtime capture of hardware signals using a Mixed Signal Oscilloscope with serial/parallel bus protocol decoding to detect problems under heavy processing loads.
All these tests need to be non-intrusive, so the simulation involves generating real-life conditions and having the real system perform under observable conditions. Using an MSO oscilloscope is invaluable to analyse and verify behavior in real-time.

Another approach we use is unit testing using subsystem isolation and wrappers at selected points of the interface. This unit testing allows a broader range of test vectors to be done in layers of the logic that are not accessible in normal operation, and can be done using HIL also. The test vectors can create impossible scenarios to exercise fault handling and meta stable conditions to explore logic vulnerabilities. The tools we use for that are also designed internally, using C++ in a Windows platform as the test vector driver/logger. Sometimes, the HIL setup is actually embedded in the instrument itself, and run as another task in the target processor. This approach allows deep access to function interfaces while a subsystem is running.

We do not use “traditional” HIL modelling, using MATLAB/SIMULINK, for example. The control models involved in our systems are either too simple to require this level of modelling, or complex enough to require real circuit evaluation, instead of an idealized model.

- Jonny

At MathWorks, we have customers using xPC Target to perform hardware-in-the-loop simulation and real-time rapid control prototyping on a wide variety of applications. Usage is very strong in Aerospace and Automotive areas, but we also see customers emerging in other application areas who are now conducting real-time testing, such as wind turbines, solar power inverters, medical devices, office equipment, and industrial robotics. All of these applications increasingly require embedded systems to control and monitor these systems. Using HIL Simulation is a great way to do a full range of testing in the lab, even conducting tests that would be at the edge of the operating envelope or difficult to do on actual hardware in the field.

- Brian

Marine Cybernetics is currently developing HiL systems for maritime Dynamic Positioning Systems, Power Management Systems, and for oilfield Drilling Packages.

John