As I mentioned in the previous post, we have different phases in our (simplified ) development process. Each one of the different phases have their own test where we simulate components and replace them as the physical systems be one available.
When we talk about "model in the loop" all do the components are simulated. If we use a simple process description where we have a control system that acts on a system, both are simulated. Once the control system is validated and embedded code is created, we could replace that control algorithm and add all necessary extra code, like safety and diagnostics) and test it against the plant model, always simulated.
|Model in the Loop (MIL)|
Once we have an algorighm that works, we might want to deploy it to a phisical system to test it out. In this stage of the development we are more concerned to have a system that allow us to debug failures related to phisical implemenation than an cost-optimized solution. We have a Rapid Control Prototyping application
|Rapid Control Prototyping|
Once we have a (more or less) final embedded solution, we might want to test it against a "simulator" that behaves like the system the embedded controller is meant to act on, without the risk of breaking anything (remember, we are still developing and thus prone to failures). This test is called hardware in the loop (HIL)
|Hardware in the Loop (HIL)|
Hardware in the loop has been around in one fashion or another for many years (I recently read that it started in the 50's) as it has many benefits that I will address in a different post.
Along this concept of moving from simulated models to simulated there other testing option. One that I like the most is "human in the loop" that my friends from Tecnalia. In this case, an embedded controller under test inputs don't come from a test profile a it is common, but rather from a simulation environment that allow the test engineers for more realistic scenarios. Check the email below to see how the move from simulated system to final, hardware based solution.