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!

How low can you go? PID Performance?

I can't wait for Toy Story 3 to come out in cinemas. I still remember when I skip a couple of classes in university to see Toy Story with a couple of good friends and how long we stayed afterwards discussing the merits of the 3D generated characters.

One of my favorites sequences in Toy Story 2 is when in Al's Toy Barn they are looking for Buzz and drive along the isle where the Barbies are playing and one of the games go "how far can you go, how far can you go".

I guess that applies today to computing plaftorm used for control. There is a wide variety, from multicore CPUs machines to 8 bit processors and the control engineer has to find the balance between performance and cost (among other things). I wanted to test the performance on three embedded computing platforms that I have on my desk. A PXI, my Laptop, a CompactRIO and and embedded ARM board.

I've successfully run Simulation Loops (the backbone of simulations in LabVIEW) in all of those platforms. More soon!