As we covered last month, embedded motion control is operation-specific code targeted to microprocessors, FPGAs, and PLCs. As hardware becomes increasingly powerful, these controls do the same. Embedded I/O, structure, and algorithms are fixed, so there is little interaction between the code and user — but users of Siemens, Rockwell, and other common products, for example, are quite used to this.
Redefining rapid prototyping
One new credo is that physical prototypes should not be used to reveal flaws; they should used to validate that a design is fully debugged and well tailored to the application.
Simulation software has evolved to let designers generate code for rapid prototyping. This is not prototyping in the sense of CAD modeling, but is the making of rapid changes to control code by altering a simulation model and automatically generating control code that can be loaded onto a controller prototype. For example, generated C code can be deployed onto a real-time test system — a microprocessor running an RTOS with I/Os connected to a hardware prototype of the actual machine.
This approach is common in the automotive industry, where concept-car pretesting is protocol. If control-code changes are required, they are made to the algorithms in the simulation model, code is regenerated, and testing of the system begins again.
Taking it further is hardware-in-the-loop (HiL), real-time simulation of machines that are expensive to build, such as wind turbines, packaging machines, or industrial cranes. This allows control-engineering teams to begin testing without a physical prototype, as they can generate code from desktop models.
During testing, the controller “thinks” that it is communicating with an actual machine. So, once controller code proves sound, it can be deployed to the controller in the final product. In this way, control engineers are ahead of the game. Anytime new features or components are added to the production design, simulation models can be reused with the new augmentations for rapid prototyping and HiL. This allows the developers to verify the integrity of the new control software under multiple operating scenarios.
Embedding proven firmware
How good is this production-ready code? Often, software engineers would be hard pressed to tell the difference between human-authored code and that output by simulation.
When prototyping code is converted into real-deal control code for the final controller, it is processed for efficiency. Extra code used in prototyping is automatically removed. Output can be customized to satisfy variable-declaration conventions, templates, and company-specific guidelines.
The code can also be targeted to any device, sometimes with special optimizations for Texas Instruments, Analog Devices, and other microprocessors. HDL (used with FPGAs) and structured text for PLCs are other possibilities. So during development of the simulation model, the control engineer does not necessarily need to know what kind of embedded target will be used for a design until quite late in the game.
Alternatively, having code that can be fed to a variety of controllers means that end users can choose which they want. This is also useful for designs where low-volume, first-generation products that use a more costly controller may go into larger production and use a less costly controller at some point.
Error proofing
Safety standards, such as IEC 61508, are requiring improved verification of embedded systems. Simulation modeling software can help ensure conformity here, checking the model for constructs that would lead to generated code that could cause a system failure. One basic example: A safety system should never include a go-to function, as a missing element could cause that line of code to freeze the whole system. Simulation software can check for such problems, as well as runtime errors.
Simulink Control Design runs on Windows, Solaris, Linux, and Macintosh platforms. For more information, visit www.mathworks.com/products/simcontrol.
Some simulation software lets designers use block diagrams to do system-level modeling. Complex physical systems (mechanical, hydraulic, and so on) are replicated within this software along with mathematical functions, stored references, and the increasingly helpful ability to import engineering data from other CAE tools. Final models are sophisticated, so the closed-loop controls generated are realistic and stable. To illustrate: Say that we have a moving machine in which one sensor fails. Should it keep moving? If it's an industrial robot, perhaps it should shut down so that it doesn't harm anything or anyone. In this case, the software reveals effects of continued motion and lets the designer develop open and closed-loop control algorithms to safely stop the robot.
Visually straightforward, MathWorks Simulink Control Design 3.0 automates proportional-integral-derivative (PID) controller tuning. Engineers without expert control-theory knowledge can use blocks to quickly create controllers, select structure, include logic, convert from the continuous to the discrete-time domain, and prepare a controller for a processor using fixed-point arithmetic. Automatic gain calculations are based on target phase margins and system bandwidth, and Real-Time Workshop Embedded Coder automatically generates code for implementation on target microcontrollers.