Tony Lennon
The MathWorks Inc.
Natick, Mass.

In today’s world it is rare to find electromechanical devices without some kind of embedded computer system. In fact, the intelligence provided by an embedded system is often the key that differentiates a piece of equipment from its competitors.

But the benefits of an embedded system come at a price. As mechatronic systems take advantage of more powerful microprocessors, the interaction between hardware and software becomes more complex. Managing this complexity can prove challenging to hardware and software engineering teams, who state requirements, describe problems, and test and implement their ideas in different ways. Adding to the complexity is that most of these systems involve closed-loop control strategies that compensate for electromechanical interactions and external disturbances. With these challenges comes the need to run open-loop supervisory control for such operational requirements as startup and shutdown, personnel and equipment safety, and fault detection and remediation.

Mechatronic-design methods today emphasize mechanical modeling before any hardware gets built. However, we often do not see this same approach when developing embedded systems. In most traditional cases, engineers address software validation very late in the development process, only testing their software on hardware prototypes. Errors found in hardware or software at this stage create costly delays. It can be time consuming to trace problems back to their root cause. Errors related to incomplete, incorrect, or conflicting requirements may even necessitate a fundamental redesign.

Model-Based Design addresses such difficulties. It simplifies the development of mechatronic systems by providing a common environment for design and communication across different engineering disciplines. The roots of Model-Based Design began in the early 1990s with the aerospace and automotive industries, which were continuously building more microprocessors into their products. Aerospace and automotive engineers recognized the advantages of simulating multidomain systems for the purposes of developing embedded controls.

In the mid-1990s, simulation of control algorithms led to automatic generation of code from the math model. The successful use of Model-Based Design by these industries proved that simulation and automatic code generation for embedded systems are economical and time-efficient approaches for developing mechatronic systems.

During the last five years, other industries involved in mechatronic development have discovered Model-Based Design. The combined effects of more powerful software and dropping costper- MIP of desktop computers has let Model-Based Design spread in much the same way as CAD/FEA software.

Just as CAD provides a geometric way of describing equipment, Model-Based Design incorporates the dynamics and performance requirements to properly describe the overall system. Because this approach is software driven, engineers can fluidly investigate competing designs and explore new concepts without the overhead of extensive hardware investment.

Engineers can continuously test the design as it evolves, checking it against requirements and finding mistakes earlier in development when they are easier and less costly to correct. In addition, Model-Based Design automates code generation for the embedded system by eliminating the need to hand code the open and closedloop control algorithms.

Model-Based Design uses a system-level model. This model defines an executable specification by describing the natural and controlled behavior of the equipment in a mathematical form. Engineers can execute the model by simulating the actual dynamics and performance of the system. The model specifies an unambiguous mathematical definition of the expected performance of the mechatronic system.

Contrast this mathematical system model with the usual way of defining how the system will operate: written descriptions. As an executable specification, the system-level model provides a clear advantage over written documents. Documents, because they are subject to interpretation, can lead to requirements that are missing, redundant, or in conflict with other requirements.

DEVELOPING THE SYSTEM-LEVEL MODEL
Written requirements will always exist, but engineers can link their electronic formats to the system- level model and help establish compliance to standards such as ISO 9001 or IEC 61508. Tracing requirements from the written specifications to the system-level model clarifies how the engineer interpreted the requirement. Electronic links between requirements and the model let engineers connect test criteria to test cases used throughout the development process.

A block diagram is a natural approach for expressing a systemlevel model. The model has inputs — signals provided by external agencies; and outputs — measures of what the system is actually doing. The inputs and outputs represent real values, such as voltage, temperature, and pH. Blocks in the diagram represent mathematical operations between the input and output signals of the model. Some blocks, called the plant or process, represent the natural behavior of the mechatronic system. For example, the model may contain a block representing a motor. The mathematical model of the motor may be fairly simple, simply taking a voltage input and converting it to an output torque.

The motor model may become more complex by adding inputs to the model, such as noise in the voltage, or by adding parameters, such as temperature and magnetic saturation effects. A single block or a group of blocks, filtering and processing signals based on output errors or events in the model, can represent the compensation or control in the system.

The basis of a systemlevel model is a lumpedparameter mathematical model that describes the physics of the system. Ordinary differential equations (ODEs) and differential algebraic equations (DAEs) express the input-to-output relationship of the mechatronic systems. In the motor example, an ODE describes the relationship of the voltage input to the shaft output torque. Differential equations are a computationally efficient way to describe lumped dynamics, as opposed to using a tool such as FEA that is based on partial differential equations. FEA software is a more likely candidate for detail work such as solving for the torque-induced stress distribution at a key slot in the motor shaft.

IMPROVING THE SYSTEM-LEVEL MODEL
Of course, there are challenges in using ODEs to describe the system- level behavior of a mechatronic system that incorporates multiple engineering disciplines. Expressing system behavior mathematically requires a knowledge of the physics underlying the system. The reality of mechatronics is that all systems are nonlinear and you must account for hysteresis, friction, and thermal effects exhibited by the physical equipment.

When the mathematics of the system becomes too difficult or time consuming to develop, there are other ways of systemlevel modeling engineers can turn to. A common method is data-driven empirical modeling, such as system identification or neural networks. These black-box approaches use measured inputoutput data to construct linear or nonlinear ODE forms of the system behavior. These behavior models then get incorporated into the system-level model.

These approaches do not give a complete insight into the physics of the system, but can yield accurate descriptions of the system dynamics within the region of the test data. Measured data can also improve the accuracy of a firstprinciples math model by using parameter estimation techniques. This gray-box modeling involves special ways of optimizing model parameters, such as a friction coefficient, to match the model output with the test data.

Model-Based Design lets engineers start with a less detailed system-level model and incrementally increase its fidelity as development progresses. A proof-ofconcept model represented as a lower-order ODE may be all that’s needed initially to help engineers quickly eliminate concepts with little promise.

For stronger ideas, they can add fidelity by incorporating subcomponents provided by suppliers to more quickly evaluate the best combinations of components. Models evolve into a combination of multiple domains, providing only the needed detail to ensure performance under the operational conditions expressed in the requirements documents.

CAD meets Model-Based Design as engineers add mass and inertia properties of a mechanical system translated from a 3D CAD assembly file. Engineers can replace approximate mathematical representations with blocks that represent the mechanical bodies and linkages translated automatically from the CAD file. In addition to speeding the development of complex mechanical system-level models, this approach ensures system designers and the mechanical engineers use an agreed-upon common model behavior that will represent the actual mechatronic system that’s built.

After describing the system’s natural behavior, the next step is to develop and evaluate a control strategy. This strategy can incorporate many levels of open and closed-loop control. The openloop control, which includes all interface, mode, logic, and supervisory control, is how engineers implement features related to safe operation, fault detection, and recovery. The closed-loop control can range in sophistication from algorithms for a basic proportional-integral-derivative (PID) compensator to an implementation of a multivariable linear- quadratic-Gaussian (LQG) controller.

The open-loop control performs supervisory and mode control within the equipment and handles interactions with the operator. Availability of more powerful microprocessors lets developers create increasingly sophisticated selfdiagnostics, fault-detection, and safety-shutdown systems. Model- Based Design helps engineers develop and test the increasingly complex open-loop control systems needed for such functions against the system-level model. Simulation lets testing begin early in the design process to improve equipment ergonomics and find any scenarios that may lead to damage or unsafe conditions. A mechatronic system can employ several closed-loop control systems operating over a range of conditions. Use of a system-level model helps in designing and tuning the controllers in loops that exhibit coupled behavior.

It is difficult and time consuming to tune controllers in hardware. The result is often a detuning of the system below expected performance to prevent instability. A system-level model lets engineers analyze the interaction of the control loops, develop decoupling strategies, and tune compensator gains with a variety of approaches that rely on direct and optimization techniques.

At this stage, the system-level model exposes dynamic instabilities that are physically or economically infeasible to eliminate by using closed-loop compensation methods. The model makes it easy to identify and adjust physical parameters, such as mass, length, and capacitance, that cause instability. As a result, problems can be found during the less expensive software-simulation stage, rather than during testing of physical prototypes.

Model-Based Design helps engineers perform cost trade-off studies within the control system. The system-level model is an analysis tool for deciding whether a lessexpensive sensor with greater tolerance gives the desired levels of accuracy and performance. In this way, engineers can evaluate practically any component used in mechatronic systems for cost versus impact on system performance.

CONTINUOUS TESTING
Model-Based Design involves continuous testing and verification throughout the development process. Developers generally define standard tests as they design the control system. Using standard tests or a test harness ensures engineers always evaluate the evolving system-level model in a consistent manner and with the same set of measures. It’s often possible to use electronic links to connect requirement documents with test criteria such as pass/fail and tolerance bands. Continuous testing with a standard test harness immediately exposes the impact of any design change on system outputs and helps quickly trace the change to the cause.

In addition, engineers can use the test harness to determine whether they have full-model coverage, a measure of how completely the test harness exercises all of the equipment’s operational scenarios. The point of verifying how well the standard tests exercise the model is to give some assurance that the tests are comprehensive and correct before testing begins on the physical prototype. Thus Model-Based Design helps engineers create tests useful during all stages of the development process and into production testing.

Once the control design strategy has been developed and tested in simulation, engineers further elaborate the model for deployment. Deployment refers to converting the control algorithms into C code, hardware description language (HDL), or an IEC 61131-3 language such as structured text (ST), that can execute on a real-time system. This process involves converting the control algorithms from a continuous (analog) to a discrete (digital), and often a fixed-point, format. During testing, engineers test the digital form of the control algorithms against the continuous form of the plant to assess how the digital conversion affects system performance.

System designers also model the input/output (I/O) device drivers and any a/d and d/a converters to ensure there will be no corruption or aliasing of signals in the real hardware. Mechatronic systems often use a combination of different processors that operate at different speeds and sampling rates. The system-level model lets engineers simulate and test various combinations to assess various options, such as using a field-programmable gate array (FPGA) instead of a digitalsignal processor (DSP), or fixedpoint calculations instead of floating- point calculations.

Next comes a test of the system- level model on a real-time system. In this stage, engineers automatically convert the systemlevel model into C code, HDL, or PLC code. Engineers may generate code for the control algorithms, the plant model, or both, depending on how they choose to test the system. The emphasis is on the word “automatic.” In Model-Based Design, there’s no need for system engineers to be code-writing experts. This prevents the introduction of errors and saves time.

The process of automatic code generation is analogous to generating a toolpath for machining a part from a 3D CAD file. If an error is found in the part after machining, the engineer checks and modifies the CAD file and regenerates the code for the toolpath. In Model-Based Design, engineers change the code via the systemlevel model, a natural environment for trouble shooting the system. They then update and test the model and regenerate the code.

Real-time testing involves two kinds of testing: rapid prototyping (RP) and hardware-in-the-loop (HIL). Here, engineers can collect data in real time and modify parameters in the code as the test runs.

During rapid prototyping, the real-time system connects to real hardware. Because the control system in the model contains all of the needed I/O in most cases, the system-level model automatically creates the code for these features, eliminating the need for engineers to hand code them.

HIL testing deploys the plant model of the equipment to a realtime system. In this situation, engineers deploy the control algorithms to a real-time test system or to the intended target processor. The control algorithms also connect to the plant model, which runs in real time. Alternatively, it is possible to run HIL testing with the simulated plant model running on a desktop computer.

Model-Based Design lets engineers use the system-level model to deploy the control algorithms in C code, HDL, or PLC code, targeting the production processor or other real-time system. The codegeneration process optimizes the production code for a specific processor. It differs from the code used in real-time testing, however. Production code generation strips out all parameters needed during testing and optimizes the code for a minimum footprint to reduce memory overhead and maximize computational speed.

Engineers have control over the code-generation process to include data objects, user-defined storage classes, types, and aliases. In addition, it’s possible to customize the code format to conform automatically to a company’s software style guide. This helps make the optimization complete and simplifies the life of software engineers responsible for integrating the code into a larger code set.

All in all, Model-Based Design is CAE for system-level design of mechatronic systems. It lets engineers inexpensively design and test multiple approaches without a costly commitment to prototype hardware early in the development process. It also yields a collaborative design environment through use of a common executable specification that connects to requirement documents. This lets the multiple engineering disciplines involved communicate in a common language. Perhaps most significantly, it reduces development costs by finding and correcting errors during an early simulation stage.