More on the V-Diagram: How to move models around

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.

Enjoy!

V (Or W or Y) Diagram. What’s yours?

I recently talked in a keynote about the V Diagram and how it helps design engineers have a methodology to design and test embedded software. There are many variations of the diagram (thus the W diagram and the Y diagram) but the most common reference I’ve seen by far is the one that uses V.

In a simplified view, the general idea behind the V diagram is to start in the top-left with the requirements development and design of the control strategy and move your way through prototyping, deployment to production hardware, and then on to various real-time testing tasks such as hardware in the loop testing, test cell validation, and so on until the entire system has been implemented and tested.


The goal is to enable system level testing at each phase of the process with a different mix of real and simulated systems. During the design stage everything is being simulated with models. And with each subsequent step in the process simulated models are being exchanged for real components as they become available.

Why would you care? Altough being created in the aerospace industry and heavily adopted in the automotive the benefits of the V diagram are being incorporated into other industries. Check for example this application where Whirpools uses the V Diagram to design and test new advanced 6th sense control algorithm in their high-end washing machines.

http://sine.ni.com/cs/app/doc/p/id/cs-14447

Enjoy!

Not everything is about design

Most of the posts of this blog (including the name) is about how to design an algorithm so that a particular action, typcially a control, can be perform. We have talked in the past about advanced control algorithms and, while control design is fun, we must also talk about how to test and validate those algorithms that we are designing.

While we work on our control problem we work with simulation tools, right? Nowadays simulation is cheap and fast. But one can't always work only with simulations on a computer and need to test embedded devices (where the algorithm is going to run) against something that behaves like the system is being control. Let's make an example. If someone is designing a control algorithm for a cruise control, you "might" want to test it first on a simulated car rather than on a real one, just in case the algorithm is not working as expected.

Here is where some of the "XiL" (Model in the Loop, Hardware in the Loop, Processor in the Loop, Software in the loop.....) come into place. The main idea is to run some or all of the compements of our embedded system in a simulated environment so that we can safely test it.

Here is a video from my colleage Chris Washington explaining more in detail what Hardware in the loop is



Have fun!

Probing your system

When I build a new VI program, I always put VIs and indicator to check the step response an bode plot of my models and, once check, I deleted them.

Thanks to Andy Chang, users can now leverage custom probes to check their models in LabVIEW without the need of extra code!



http://decibel.ni.com/content/docs/DOC-12804

Enjoy!

NIWeek is near!

Hello all

NIWeek is very near. I'm going to improve my "coverage" with news and updates relevant to the world of Algorithm design and Simulation. If you are coming, feel free to comment a post to meet!

I'll leave you with the vide0s from NIWeek last year



Enjoy!

Want to get an sbRIO? submit your Inverted Pendulum control code in LabVIEW

Ok, that might be a little bit long of a title, but will give you the idea. National Instruments and Ammons Engineering are sponsoring a code challenge. The goal is to design and implement a control algorithm for the... guess what... exactly: An inverted pendulum.

The best part (other than the fun of programing) is that we are giving way a NI Embedded Kit!!!

You can see all the details in the NI Community Forums

http://decibel.ni.com/content/message/16920#16920

Enjoy!

Another inverted pendulum.

By now you probably know I have something for inverted pendulums. I just found this project done in the University of Michigan as a Senior Design project. I like this particular project because:

- The inverted pendulum model was provided using Matlab, but it was implemented MathScript
- LabVIEW used for the control algorithm and cRIO for the embedded control platform
- I like the enclosure used to make it safe. This system is meant to be in a museum for children
- I also like the use of magnets to disturb the plant. Slick!

Here is a link to the youtube video



I know, I have to start posting about something different from inverted pendulum :D

Enjoy!