PID on a diet? How to tune your PID

There are two facts about PID that truly amazed me. The first one is the amount of people that use it and the second one is how many rules and utilities are out there to tune them.

In my mind, implemeting a PID is a little bit like going on a diet. Everyone wants to loose weight (or improve performance) and there are lots of different diets (tools, rules of thumb, programs) but there is no "magic diet" that miraculously lets you loose weight without some effort.

I don't have a solution for it; if anyone does feel free to add it in the comments!. What I do have is an Adaptive PID Example. It is not perfect, by any means, but shows the interesting concept of using online system identification to identify the plant and change the PID gains based on it.

My colleague Brian McCleery wrote a whitepaper about it and Dr. Jeannie Falcon demonstrated it

Enjoy!

The importance of being in Sync - Centralized vs Distributed

As if often happens, this post comes from a discussion I had with a customer.

One common trend that I see with test systems, is the need for them to be distributed. Having a distributed system has several benefits

- You can get your instrumentation closer to the signals, thus reducing noise. I had a customer that had to read lots of signals from sensors all around a facility and having very long cables didn't work very well with small signals, particulary when the cables had to run paralell for a long trek

- Since there will be some sort of data bus, less cabling is needed. In the case above, some of our systems act as concentrators, drastically reducing the needed lengh of cable

- You can have your instrumentation with the unit under test while having the control of your instrumentation on a safe location.

I think a graph will help explain it

So why don't we have more of this distributed architectures? Well, as you might guess from the post title, we might want to have the data that is collected synchronize. But what does it mean to be "synchronized", it basically means that signals use clocks that are correlated. The tighter the synchronization the closer the clocks need to be in synch.

Is this always neccesary? As usual, it depends on the application and the signals being developed. If you are building a control system based on temperature readings on different parts of the building (to activate the boiler, for example) signals do not need to be closely synchronized, as it is typically a slow control systems and temperature doesn't change rapidly.

On the oposite side of the spectrum, you might be building a iron-bird. In this case you need the information to share a timebase, among other things.

How is this accomplish? You'll have to read my next blog post :D

You want to see a system tightly sincronized? Behold the "Gears of Death" Demo!

Have fun!

MIL, SIL, PIL, HIL..... How is the "in the loop" term used.

Hello all!

It's been a while. I read a while ago that one shouldn't apologise for not writing and just keep writting as if nothing happen, so I'll take that advice.

Often in my customer interactions I hear and use the term "HIL". As you might know, HIL stands for "Hardware In the Loop" and is a testing methodology to verify and/or validate and embedded system design. I heard it was developed around 30 years ago by the automotive industry (feel free to correct me!) and had evolved much since. You can learn more from the wikipedia entry.

Interesting enough, there are a number of different "In the Loop" variations, depending on methodology used, equipment and even culture inside a company. By no means the terms I will refer below are anything like industry standards, but that's the way I have them in my head and make quite sense.

To simplify the explanation, let's assume we are developing an embedded control algorithm that will act over a physical system. The plant execution is needed to provide the information needed to close the control loop on the embedded device.  For example, let's assume the control system for an automatic transmission.

MIL ("Model in the Loop"):  In this instance, both the control algorithm and the plant model (transmission and car) are implemented as simulation models. Here is one example that ships with LabVIEW

SIL ("Software in the Loop"): Here we have created the optimized code for the embedded target but still run it against the plant model on a computer environment.

PIL ("Processor in the Loop"): The embedded code is running on an embedded target. The plant model. Here is great video below about simulation, control theory and a PIL system

HIL(or HWIL "Hardware in the Loop"): Embedded target is finished (or nearly so) and plant model is executed on an external device.

Test Cells: This is an extension of the methodology where both the embedded system and the plant are physically present and external elements are simulated. In the case of our automatic transmission, both transmission and TCU (Transmission ECU) exist and the engine input torque and road/car  load are simulated by electrical motors. Here is an example for a transmission from a customer.

There are many more terms I've heard like "Person in the Loop", "Sensor in the Loop", etc, but thought it would be good just somewhere to start on.

At the end of they day, when I have to explain my kids what I do, I tell them I help people build "simulators"

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!