Embedded-control system designers feel more pressure than ever to provide better performance and more features, all while meeting tight deadlines and keeping costs down. As these demands intensify, traditional design and verification methodologies tend to fall short.
In traditional design flows, designers can’t determine if their controller works until late in the effort, when hardware is available. This was often sufficient for systems developed in years past. System behavior was predictable, and the simple control scheme minimized opportunities for error. Problems could be solved by tuning the controller during verification.
With today’s multidomain systems, however, this process is no longer sufficient. As system complexity grows, the potential for errors and suboptimal designs increases. When design problems show up in the verification stage, they require difficult, costly changes— changes that often include time-consuming hardware fixes.
The growing complexity of control systems makes it difficult to test all the corner cases in a design. For many systems, it’s impractical or even dangerous to test the full operating envelope on production hardware. For these systems, traditional verification methods simply don’t work. Leading system designers recognized these challenges and are adopting early verification with Model-Based Design.
With this approach, engineers can simulate the physical plant alongside the control algorithms and logic. Early verification allows designers to quickly evaluate a variety of control strategies and optimize system behavior; catch errors early, before hardware is available; use simulation to test the full operating envelope; and reuse models for real-time testing.
In the traditional workflow, requirements are provided via paper specifications (Fig. 1). Each subsystem—including mechanical, electronics, controls, and software—is designed in separate design tools directly from the specifications, with very little coordination between the subsystem designs. This process calls for verification late in the design cycle, once the system is integrated. Only at this point can designers fully observe the interaction between the system’s physical systems, control algorithms, and logic.
This may be acceptable for lowperformance systems, where the interaction between domains is simple and easy to characterize. Yet the interaction between subsystems becomes more complex as designers add features and push for optimal performance. This makes it harder to design the controller, and it increases the likelihood of design errors.
The risk of errors is compounded because each part of the design— mechanical, hydraulic, controls, and software—involves different ways to describe requirements, implement solutions, and test designs. These differences make it easy to introduce conflicting requirements, misinterpret requirements during design, and perform incomplete or extraneous testing.
If an error isn’t discovered early in the design process, the complex interaction between subsystems can make it difficult to trace the problem back to its root cause— and fixing this problem can be just as tricky. Errors related to incomplete, incorrect, or conflicting requirements may even necessitate a fundamental redesign.
Model-Based Design addresses these challenges by enabling early verification. Verification is no longer treated as a final step. Rather, it becomes a continuous process that begins in the design phase and carries through realtime testing (Fig. 2).
Also, designers can build a mathematical model of the control software as well as the physical plant, including mechanical, electrical, hydraulic, and other physical domains. By linking the model to the system requirements, the model becomes an executable specification that can be used for each subsystem and the system as a whole. It drives an unambiguous understanding of the requirements, reducing the risk of design errors.
Model-Based Design also creates a common design and verification platform. Engineers have an intuitive, graphical view, creating a common environment for designers from different disciplines. Model- Based Design tools also facilitate the reuse of existing designs and engineering data by providing hooks into CAE tools, like CAD, FEA, and circuit emulation tools (including Spice).
The availability of an executable specification helps designers of control algorithms better understand the system, which leads to better control design. Instead of designing against an inherently vague paper specification, designers can experiment with the model to fully understand the system’s behavior. They also can quickly try out different control strategies, allowing them to identify the strategy that optimizes performance while meeting other design constraints.
Control designers using a traditional workflow can’t verify their designs until hardware is available, which is usually late in the design process. In contrast, with Model-Based Design, designers can start testing against a model. This early verification capability saves time and reduces costs, while simultaneously improving design quality and performance.
The key benefit of early verification, of course, is that designers can catch errors in the first stages of the development process, where they’re easier and cheaper to fix. Simulation helps designers spot problems that would require hardware changes—a particularly valuable capability because hardware changes are much more expensive than software fixes.
Continue to page 2
Also, troubleshooting errors is much easier in simulation than in the field. In simulation, the designer can inspect the state and history of each component and drop a scope at any point, run the simulation repeatedly under identical operating conditions to replicate the problem, and ensure it was addressed. In the field, the designer has much less data.
Testing against a model also enables more thorough verification. Complex systems often have large operating envelopes with numerous operating modes, multiple failure modes, and so on. Testing the full operating envelope on hardware can be impractical or even dangerous. It’s easier to achieve full test coverage with a simulation, and there are no concerns about equipment damage or other hazards.
REAL-TI ME TESTING
The same models used in early verification via desktop simulations can take verification a step further with real-time testing. Using Model-Based Design, engineers can generate embedded code directly from the model to enable rapid prototyping and hardware- in-the-loop testing.
In rapid prototyping, the control algorithms are tested in real time with the physical plant hardware. By reusing the control models to generate the prototype code and running it on a generic test system, engineers can often complete real-time verification before deciding on the final controller platform. And because a direct connection exists between the design and implementation, it’s easy to fix errors identified during testing.
With rapid prototyping, an engineer can run through the same tests that were used in desktop simulations directly on the plant hardware. These tests will highlight any approximations or simplifications made when modeling the plant that could significantly impact system performance. After working bugs out in the lab on prototype hardware, engineers can implement the design on production hardware with more confidence.
In hardware-in-the-loop testing, the production controller hardware is tested against a real-time simulation of the physical plant. This is useful when access to the physical system is limited or unavailable. It’s also invaluable for projects that may be dangerous when testing the full operational envelope. Hardwarein- the-loop tests can fully exercise system diagnostics as well, which might be difficult or impossible to test on the plant itself.
Early verification with Model-Based Design results in shorter, less expensive design cycles. It also helps designers create more robust, better performing control systems. As control systems become ever more complex, verifying designs before committing to hardware not only will be a best practice, it also will be imperative.