What Control Systems Engineers Do | Control Systems in Practice

Being a control systems engineer is more than just designing a controller and tuning it. Over the course of a project, actually designing the controller might be a relatively small part of your day-to-day job.  Depending on the size and phase of the project, your responsibilities and which groups you work with will probably vary greatly. This series is going to cover some of the practical aspects of being a control systems engineer.  In this video in particular, I want to provide a picture of the types of things you may be exposed to and which groups you might interface with while working in this field - at least from my experience. I’m Brian, and welcome to a MATLAB Tech Talk.

Let’s start at the beginning of the project, before you even have an idea of what you want to build.  The concept formulation phase is where you are trying to figure out the need.  The need might come from an external customer who is asking you to create something for them, or it may come internally from your business development team who is claiming there is a market for a particular service or product.  For example, the need might be a service that takes high-resolution aerial imagery of mountain sides to track erosion and predict mudslides.

The business team knows they can sell images like this, but they don’t know the best way to create them. Is it best to design a fleet of imaging drones, a gimbaled camera system that can bolt onto an airplane, or a satellite that takes pictures from orbit? This is where the engineering team helps out, to work through the technical difficulties of each concept. Now, the actual decision takes into account a bunch of things like how quickly does an image need to be available? How large is the area and where is it? How often does the area need to be revisited?  And so on.

But as a control systems engineer, your part in the decision making process is to explore all of these concepts from a controls perspective and provide information that will help narrow down the selection. It’s easy to see how performance is something that you would care a lot about but this needs to balanced against other metrics like cost, size, weight and power, and availability of the components. For example, how well does each system need to point the camera to get the image and what sensors and actuators are required for that performance?  Can you purchase those components or will your company need to make them? 

In order to answer questions like these, you typically don’t need a fully fleshed out design. Instead you create models of the proposed systems, making as many assumptions and simplifications as possible, and then simulate the various configurations and their performances. You don’t know very much about the details of the system at this point so you’re not getting exact answers. After all, every other function is at the same stage so, for example, it’s impossible to know the exact mechanical configuration, or compute capability, or operating environment. Rather, you’re trying to generate broad answers to estimate the feasibility and level of effort of the project. And, importantly, understand how uncertain you are with those answers.  That way you are confident that when you get into detailed design your system is something that you can actually build and even with the uncertainty, it is something that will meet the requirements.

This phase can be a very dissatisfying process because of how nebulous and confusing it is. There isn’t a path to the perfect answer.  Instead, you’re narrowing down to an acceptable answer by crossing off the things that don’t work or aren’t as good as other options. There are a lot of wrong answers and therefore a lot of work that you do to find those wrong answers that is just thrown away in the end and that can be hard to accept.   However, to me, this is a really exciting part of control engineering because at the beginning of a project you have a lot of influence on the system you’re ultimately going to build. And this gives you a chance to explore and learn about many different things that you might not get exposed to on an established program.

Once there is a general idea of what needs to be created, there comes the process of describing the system in a way that communicates to every team what they own and what they specifically need to accomplish. This is often done in the form of requirements, system constraints, technical budgets, and interface documents.  The systems engineering team is typically responsible for creating and managing these documents. 

However, if systems engineering is solely responsible for defining the system, there is a good chance they will request something that is under-defined, not feasible or wildly impractical.  As a control engineer, and the one ultimately implementing the control system, you will be helping the systems engineering team to create and validate the requirements that pertain to your system.  Maybe you’ll have a rock star systems engineering team that can do everything themselves, but typically having the engineering team participate in the definition of the system produces better results. At the very least, the engineering team will know why certain requirements were levied on them and will have already thought about the alternative design approaches. For example, a systems engineer might not understand the need for a gain or phase margin, or might set the requirement too low or too high.  You’re job at this stage of the project is to help define the system and catch errors early so that there are fewer discrepancies in the detailed engineering later on.

This, again, is a job that models can help with. You can catch those errors, or contradicting requirements with a model because you can simulate the system as it’s defined and see the resulting discrepancy right away. In some cases, the model itself becomes the requirements, where you define what the system needs to do in model form.  This can a more efficient way of describing your system.  As an example, imagine trying to explain to a contractor using only words what you want your house to look like and which features it should have rather than handing them a set of drawings.

With the definition of the system complete (or complete enough), development can start.  This is the design, implementation, and evaluation portion of the project. This is the phase of the project that I think most people think of when they imagine what an engineer does - design stuff, build stuff, and test stuff.  These three activities aren’t done just once, but occur over and over again throughout this phase as the entire project evolves and solidifies into the final product. You’re constantly tweaking your design, implementing the changes, and testing the result.

In some industries, you may use Model-Based Design and that requires models that accurately represent the real system.  You may start the process by designing a control system using your simplified model, test the design with a simulation, and then update the model and your design over time.  This is the part of your job where you get to determine the controller structure and use the control theory knowledge you’ve gained.  If you have a simple model, and the requirements are achievable, then getting an initial controller design probably won’t take very long. Maybe a few days if it’s particularly challenging or if you have to learn about the controller you want to implement. But generally it’s pretty fast.

Most of your time will probably be spent updating your model to make it more realistic and verifying that it is accurate as the project spirals in on specific implementations.   In addition to the model of your system, you also will be building a model of the environment that your system will operate in. For example, if you are implementing the spacecraft, you might have to model the orbital dynamics and the disturbances from the Earth and Sun in order to have the necessary fidelity in your model.

Now, any time you update your model (either the system itself or the environmental sim), you rerun a set of regression tests to check to see if your control design still meets the requirements with the more accurate model. If it doesn’t, then you cycle back around and tweak the gains of the controller or change the controller structure entirely.

Increasing the fidelity of the model isn’t the only thing that drives changes to your control design. Actual changes to the system, whether they're inside or outside of your control, also require that you revisit your design. And since it’s impossible to perfectly describe a system in the formulation phase, there are always changes over the course of the project.

Especially for control engineers, any change to the system, even ones that seem small, might affect your design and require you to cycle through these steps again. As an example, the mechanical team might change the material of the main structure to reduce mass. In this case, the reduction of the moment of inertia might change the stability margins since it’s a rotating system that points the camera. Or perhaps the thermal properties of the material changed so that the sensor that’s attached to it runs hotter or colder than expected changing its sensitivity or increasing noise. 

Because change is inevitable, you might find that a lot of your time in this phase is spent working with the other engineering groups to update models, rerun simulations, and convince yourself that your design still meets the requirements and can be implemented safely. If a design change drastically impacts your control system, you might be responsible for proposing other solutions that are less intrusive, or at the very least, describing the impact to the control system to project management in terms that matter to them; cost, schedule, and risk.

A quick note about what you might be expected to do when implementing a control law in software. In some companies, the control engineer is just responsible for describing the algorithms and logic for the control laws in a way that a software engineer can understand and code for production.  In other companies, the control engineer themselves is also a software engineer and expected to be able to write their own production code.  Finally, something that is gaining more popularity each year is the ability for the control engineer to autocode production software directly from their algorithms.  This allows the engineer to specialize in understanding control theory and modeling and still be able to generate their own code without deep software expertise or relying on another team. This ability to use Model-Based Design to build software products means that there is a lot more flexibility in the design, implementation, and test cycle. You may find even as a controls engineer that you are on a team that follows software-centric development methodology like Agile, which is becoming a lot more popular.

Let’s talk a bit about test and verification because I don’t think I can overestimate how much time you will be (or should be) spending verifying that your design is correct.  There are several different fundamental verification methods: Inspection, analysis, demonstration, and test.  As a control engineer, you may use each of these methods to verify your design (especially analysis which is what you’re doing when you verify a requirement via simulation). This also includes formal analysis like checking for divide by zero, memory leaks, dead code, or data overflows, and models can also be used to verify this as well since modeling software like MATLAB and Simulink have these analysis tools built into them.

But the method I want to go into more detail on is test.  Testing with physical hardware can be a large portion of your job, especially near the end of the engineering phase.

Let me explain why.  There are several reasons why you may need to set up a hardware test and verifying that the system meets a requirement is just one.  You may also need to run a test to get information from the system.  For example, you may need to develop or correlate your model to the real hardware.  Another reason to test is to get baseline data that you will compare to in the future.  For example, you might collect some data before dissembling the system and rebuilding it.  After it comes back together you’d run the same test as before to verify that it was rebuilt the same way. Another reason is just to do science.  You might have a hypothesis of how the system will behave, and you want to run a test to see if the hypothesis is true.  This is especially the case if there is an anomaly in the design and you’re trying to find the root cause.  Finally, you may run a test to train people on the hardware or to demonstrate capability to the customer. 

I bring this up, because running a physical test isn’t as straight forward as running a simulation.  Once you get hardware involved, things become a lot more complicated. A lot of your time will be spent defining what the test is and defending why you have to run it on the hardware. This involves writing a test plan describing what you’ll get from the test, what you’re going to do with the hardware, and how it will be safe.  You may be required to write a test procedure documenting the step by step actions you’re going to take during the test. Also, you’ll need to create any unique hardware, software and other apparatuses that are needed to execute the test.   Even if you’re not the one building this special test equipment, you will at the very least be defining what you need to the test group that will create them.

By the end of the engineering phase, you’ll have a system design that meets the project requirements and that is ready for delivery to the customer or to go into operation.  However, your job as a control engineer doesn’t stop once the system is in use.  You may be asked to be part of an anomaly investigation or recall if the system doesn’t perform the way it was expected to.  You can be involved in training the users with how to operate the system, or you may also be working on the next variant of the design and therefore are interacting with the users to get information regarding what changes are desired. 

The point here is that as a control engineer, you have a lot of different responsibilities.  You may be part of a very large project and be asked to do a very specialize portion of something I mentioned in this video. Or if you end up on a smaller project your role may expand to all of them and more. That’s what I think is so much fun about control systems, you have the opportunity to be involved with all phases of the project and you get to interact with a number of different engineering and business management teams if you want.

In the rest of this series, I’ll cover some of the practical problems you might encounter as a control engineer that are different than the typical controller design and tuning problems.  So if you don’t want to miss these future tech talk videos, don’t forget to subscribe to this channel. Also, if you want to check out my channel, control system lectures, I cover more control theory topics there as well. Thanks for watching, I’ll see you next time.