Model-Based Design for Mechatronics

Challenges of Developing Mechatronic Systems

Most engineers are surprised to learn that the term mechatronics is nearly 40 years old. It was first used in1969 by Tetsuro Mori, an engineer at the Yaskawa Company, to describe a system composed of mechanical and electrical elements that is controlled by an embedded system (Figure 1). In today's world it is rare to find electromechanical devices without some kind of embedded system. The intelligence from an embedded system delivers enhanced performance, reduced energy consumption, better reliability, and safer operation, which are key differentiators and value drivers for a piece of equipment.

The benefits of an embedded system come at a price. As mechatronic systems take advantage of more powerful microprocessors, which provide the intelligence for embedded systems, 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 solutions in different ways. In addition, engineers must design closed-loop control strategies to compensate for electromechanical interactions and external disturbances, as well as incorporate open-loop supervisory control for operational requirements, such as start-up and shutdown, personnel and equipment safety, and fault detection and remediation.

In most traditional design approaches, engineers test software on hardware prototypes, addressing software validation very late in the development process. Errors found in hardware or software at this stage create costly delays and may be time consuming to trace back to their root cause. Errors related to incomplete, incorrect, or conflicting requirements may even necessitate a fundamental redesign.

Improved Development Using Model-Based Design

Model-Based Design simplifies the development of mechatronic systems by providing a common environment for design and communication across different engineering disciplines. Model-Based Design extends the computer-aided engineering (CAE) world with an additional perspective on system-level design. Just as computer-aided design (CAD) provides a geometric or static description of equipment, Model-Based Design incorporates the dynamics and performance requirements needed to properly describe the 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 the development process 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 closed-loop control algorithms.

Model-Based Design uses a system-level model that defines an executable specification by uniquely 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. As an executable specification, the system-level model provides a clear advantage over written documents, which, because they are subject to interpretation, can lead to requirements that are missing, redundant, or in conflict with other requirements.

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.

Developing the System-Level Model

A block diagram is a natural approach for expressing a system-level 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.

Inside the model, the blocks 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 complexity can increase by adding more inputs to the model, such as noise in the voltage, or by adding more parameters, such as temperature and magnetic saturation affects. A single block or a group of blocks, filtering and processing signals based on output errors or events occurring in the model, can represent the compensation or control in the system.

The basis of a system-level model is a lumped parameter 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 partial differential equation-based modeling tool, such as finite element analysis (FEA). FEA software could be used to solve for the torque-induced stress distribution at a key slot in the motor shaft.

Using ODEs to describe the system-level behavior of a mechatronic system involving multiple engineering disciplines does not come without challenges. Expressing system behavior mathematically requires that you have 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 real mechatronic equipment.

Improving the System-Level Model

When the mathematics of the system becomes too difficult or time consuming to develop, engineers can turn to other ways of system-level modeling. A common method to supplement a first-principles approach is data-driven empirical modeling, such as system identification or neural networks. These black-box approaches use measured input-output data to construct linear or nonlinear ODE forms of the system behavior for incorporation 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 first principles mathematical model by using parameter estimation techniques. This gray-box modeling involves optimization techniques to adjust 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-of-concept model represented as a lower-order ODE may be all that is required 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 increase model fidelity by using mass and inertia properties of a mechanical system translated from a three-dimensional 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 that the system designers and the mechanical engineers use an agreed-upon common model behavior upon that will represent the actual mechatronic system when built.

Developing the Control Strategy

After describing the system's natural behavior, the next step is to develop and evaluate a control strategy, which can incorporate many levels of open- and closed-loop control within the mechatronic system. The open-loop control, which includes all interface, mode, logic, and supervisory control, is how engineers implement the safe operation, fault detection, and recovery features. 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 control and mode control within the equipment and addresses the interaction of the operator with equipment. Equipment designers using more powerful microprocessors can develop complex user interfaces that provide greater control over the operation of the equipment. As a result, developers can create increasingly sophisticated self-diagnostics, fault-detection, and safety-shutdown systems within the equipment. Model-Based Design helps engineers develop and test the increasingly complex open-loop control system against the system-level model. Simulation lets testing begin early in the design process to improve the ergonomics of the equipment and find any scenarios that may cause equipment damage or create unsafe conditions.

A mechatronic system can employ a number of closed-loop control systems operating over a range of conditions. Using a system-level model helps in designing and tuning the controllers in control loops that exhibit coupled behavior. Tuning the controllers in hardware is difficult and time consuming, and often results in detuning 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-based 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 less expensive sensor with greater tolerance provide the desired levels of accuracy and performance. Engineers can evaluate practically any component used in mechatronic systems for cost versus impact of the system performance.

Continuous Testing and System Verification

Continuous testing and verification throughout the development process involves defining and using standard tests in conjunction with the control system design process. Using standard tests or a test harness ensures that engineers test the evolving system-level model in a consistent manner and with the same set of measures. Test criteria such as pass/fail and tolerance bands are associated with a test through electronic links to requirement documents. 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 operational scenarios of the equipment. Verifying that the standard tests will completely exercise the system for all operating conditions during the modeling phase assures developers that the tests are complete and correct before testing begins on the physical prototype. ModelBased Design helps engineers create complete tests that they can use during all stages of the development process and into production testing.

System-Level Model Elaboration for Deployment

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), for executing on a real-time system. This process involves converting the control algorithms from a continuous (analog) to a discrete (digital), often fixed-point, format. During the continuous testing, engineers test the digital form of the control algorithms against the continuous form of the plant to ascertain whether the digital conversion adversely affects the desired performance to the system.

Model elaboration lets engineers examine other aspects of converting to digital signals. System designers model the input/output (I/O) device drivers and any A/D and D/A converters to ensure that no corruption or aliasing of signals will occur in the actual implementation of the system. 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 cost and implementation options, such as using a field-programmable gate array (FPGA) instead of a digital signal processor (DSP), or fixed-point calculations instead of floating-point calculations.

Testing Mechatronic Systems Using a Real-Time System

Testing the system-level model on a real-time system is the next step in Model-Based Design. In this stage, engineers automatically convert the system-level 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. In Model-Based Design, automatically converting the system-level model to code eliminates the need for system engineers to be code-writing experts, prevents the introduction of errors, and saves time.

The process of automatic code generation is analogous to generating a tool path for machining a part from a three-dimensional 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 tool path. In Model-Based Design, engineers change the code via the system-level model, a natural environment for trouble shooting the system. They update and test the model and regenerate the code.

Using dedicated real-time test systems, real-time testing involves two kinds of testing: rapid prototyping (RP) and hardware-in-the-loop (HIL). During this testing, engineers can collect data in real time and modify parameters in the code as the test runs. Table 1 shows some of the options for real-time testing and illustrates the testing flexibility that lets engineers catch critical and time-consuming mistakes before actual hardware is available. As stated earlier, tracing mistakes to their source is much easier since the system-level model is the specification, tied directly to the requirements documents.

Table 1. Rapid prototyping and hardware-in-the loop testing scenarios.

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 real-time system. In this situation, engineers deploy the control algorithms to a real-time test system or to the intended target processor, and connect to the plant model, which also runs in real-time. HIL testing can also be accomplished by using the simulated plant model running on the desktop or workstation computer.

Production Quality Code Generation

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 code generation process optimizes the production quality code for a specific processor. It differs from the code used in real-time testing because the process 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, customizing the code format to conform automatically to a company's software style guide helps make the optimization complete and simplifies the use of the code by software engineers, usually responsible for integrating the code into a larger code set.

Summary

Model-Based Design is CAE for system-level design of mechatronic systems. Engineers develop and test a behavioral model of their equipment in software with these benefits:

1. The capability to inexpensively design and test multiple approaches without a costly commitment to prototype hardware early in the development process.
2. A collaborative design environment using a common executable specification that connects to requirement documents and lets all multiple engineering disciplines communicate in a common language.
3. The ability to reduce development costs by easily finding and correcting errors during an early simulation stage.
4. The capability to develop complex embedded systems that provide greater customer value, product quality, and sophistication in mechatronic systems.