What Control Systems Engineers Do | Control Systems in Practice, Part 1

being a control systems engineer is more than just designing a controller and tuning it over the course of a project actually designing a controller might be a relatively small part of your day-to-day job now depending on the size and phase of the project your responsibilities and which group you work with will probably vary greatly this series is going to cover some of the practical aspects of being a control systems engineer and 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're trying to figure out the need the need might come from an external customer who's asking you to create something for them or it may come internally from your business development team who's claiming there's a market for a particular service or product for example there might be a service that takes high resolution aerial imagery of mountainsides 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 gimballed camera system that can bolt onto the bottom of 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 whole bunch of things like how quickly does an image need to be available how large is the area that you need to image and where is it and 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 be balanced against other metrics like cost size weight and power and the 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 you need the company to make them now in order to and or questions like these you 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 for 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's 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 were narrowing down to an acceptable answer by crossing off all of 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 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 and the systems engineering team is typically responsible for creating and managing these documents however if systems engineering is solely responsible for defining the system then there's a good chance that they're going to request something that is under defined not feasible or wildly impractical as a control engineer and the one ultimately implementing the control system you're going to be helping the systems engineering team to create and validate the requirement that pertain to your system now 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 high or too low your 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 is also 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 its defined and see the resulting discrepancy right away in some cases the model itself becomes the requirement where you define what the system needs to do in model form this can be 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 just handing them a set of drawings with the definition of the system complete or complete enough then development can start this is the design implementation and evaluation portion of the project and it's the phase that I think most people think of when they imagine what an engineer does they design stuff build stuff and test stuff these three activities aren't done just once but occur over and over again throughout the 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 the simulation and then update the model and your designed over time and this is the part of the job where you get to determine the controller structure and use the control theory knowledge that 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 that you want to implement but generally it's pretty quick most of your time will probably be spent updating your model to make it more realistic and then verifying that it is accurate as the project spirals in on specific implementations in addition to the model of your system you're gonna also be building a model of the environment that your system will operate in for example if you're implementing the spacecraft option you might have to model the orbital dynamics and disturbances from the earth and the Sun in order to have the necessary fidelity in your model now anytime you update your model either the system itself or the environmental simulation you have to rerun a set of regression tests to check to see if your controller 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 and 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 its 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 its noise and since 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 changed 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 now 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 creating and describing the algorithms and logic for the control laws in a way that a software engineer can understand and then 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's gaining more popularity every year is the ability for the control engineer to Auto code 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're on a team that follows a software centric development methodology like agile which is becoming a lot more popular alright let's talk a bit about test and verification because I don't think I can overestimate how much time you will be or at least should be spending verifying that your design is correct there are several different fundamental verification methods inspection analysis demonstration and test and as a control engineer you may use each of these methods to verify your design especially analysis which is basically what you're doing when you verify a requirement via simulation this also includes formal analysis like checking 4/0 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 of them 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 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 disassembling the system and then rebuilding it and after it comes back together you'd run the exact same test as before to verify that it was rebuilt the same way another reason is to just 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's 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 a customer I bring this up because running a physical test isn't as straightforward as running a simulation once you get Hardware involved things become a lot more complicated and a lot of your time will be spent defining what the test is and defending why you have to run it on hard ware in the first place this involves writing a test plan which describes what you're gonna get from the test what you're going to do with the hardware and how you're gonna keep it safe and you also may be required to write a test procedure documenting the step by step actions you're gonna take during the test also you'll need to create any unique hardware software and other apparatus --is that are needed to execute the test and even if you're not the one building this special test equipment you will at the very least be defining what you need for the test group to create 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 maybe a recall if the system doesn't perform the way it was expected to you can also be involved in training lis users how to operate the system or you may be working on the next variant of the design and therefore 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 specialized 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 possibly 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 to 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 and I'll see you next time

Channel: MATLAB

Views: 106,330

Rating: 4.9817166 out of 5

Keywords: MATLAB, Simulink, MathWorks, control theory, control systems, mathworks matlab

Id: ApMz1-MK9IQ

Length: 14min 20sec (860 seconds)

Published: Tue Aug 21 2018