Using the right tools for the right job

How often has it happened to you that, just because you have a tool handy, you use it for a total different use (PowerPoint to edit images, anybody?). The same happens when you are talking about using tools to design and algorithm, to deploy it and to validate it.

It happens often that the design tools is "missused" to do other kind of work that was not design for. Notice that I use quotes since someone might say that the right tools is the one that gets the job done, independently of other tools out there that might be suitable.

When there is a small team, this issue might not be such. For example, below is an example of a student team that use the same platform for design (model plant and control algorithm), Prototype (using tether IO on a scale system) and Deploy (deploy the algorithm to a Real Time system).

http://multimechatronics.com/images/uploads/movies/NI%20RPI%20Transporter.wmv

This is an example on how using the same platform helps speeding up the left side of the V Diagram.

But there are instances where the team in charge of the plant modeling would like to use one tool. Let's say SimulationX. The team that design the control algorithm use another tool. Let's assume LabVIEW. The embedded team doesn't have any idea of either modeling or control design as they only care to deploy to and embedded target. And there is the validation team that is in charge to validate the embedded code that is more concern on how to build a test system capable of consistently and automatically test different test scenarios. How to bring everything together?

Here is where a platfrom that integrates different tools and can be used without programing skills is very useful.

The image above show a combination where we have a tool to automate the tests (TestStand) and another tool to run the dynamic simulation (VeriStand). This kind of approach allow users to use the tool more suitable to their needs (or the one they are more comfort with) while reusing and interacting with different parts of the organization. And all while saving money in the process!

 Here is a video that goes in detail explaining the architecture in detail.

http://zone.ni.com/wv/app/doc/p/id/wv-2618

Enjoy!

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!