In this age of the Internet of Things, Big Data, analytics and mechatronics it is the multidisciplinary intersections of mechanical, electrical, and control systems that provide the product and experience opportunities the marketplace is seeking for applications raging from autonomous vehicles to wearable devices
Dr. Michael Hoffmann | Senior Vice President - Math & System Modeling
Why Model Based Development?
Model-Based Development (MBD) is a process that helps to manage and reduce the risk of creating complex systems by allowing design and testing of control system software continuously and iteratively even as it is developed to reduce defects, development time, and improve collaboration between engineers. This process relies on simulation models and flows from abstract to the specific, which means that design starts with system-level requirements, and flows from functional system models to detailed system models to component models, and back up to implementation through testing. Throughout this process, simulation assists in driving from the high-level requirements down to component level design. System-level simulation tools help engineers and designers to analyze designs based on different levels of fidelity throughout the process, which is based on the needs of the simulation and the data available at the time. MBD development consists of 3 main phases - simulation phase, also known as Software in the Loop or SIL; the microprocessor in the loop phase, also known as Processor in the Loop or PIL; and the hardware in the loop phase, also known as Hardware in the Loop or HIL.
Embedded software systems are growing in capability and complexity at an extraordinary rate promoted by faster and more capable microcontrollers, broader multi-disciplinary requirements, and higher reliability standards. In order to meet these growing demands, engineers turn to the MBD process. Any control system consists of four basic components; the controller, the plant, sensors, and actuators. The basic objective of any control system is to design the controller such that the plant is controlled in a way that satisfies all requirements while subjected to uncertainties including environmental conditions, sensor & actuator errors, nonlinear dynamics, failures, and others. Modeling provides a way to describe the design of a control system graphically using block diagrams, state charts, or code based functions. Simulation is the numerical solution of the model over a time or frequency range. Together, the modeling and simulation steps are foundational in the MBD process.
Initially in the MBD process, design requirements are converted from their normal text format into Design Models. Design Models are dynamic block diagram based models that display the requirement as a time history or frequency response with an acceptable range of variation. Complex systems may have hundreds of requirements, hence, hundreds of Design Models. During the Software-in-Loop(SIL) phase the plant, controller, actuator, and sensor models are executed entirely on the Host. It is also common to include the sensor and actuator models as part of the plant model, at least initially. Sometimes they are neglected entirely implying they are ideal unity gain models with no dynamics. The controller is separately modelled and interfaced with the plant model through the actuator and sensor interface signals. Initial design iterations often use a continuous time model for the controller which allows standard frequency domain methods to be employed for design. Once the design requirements are satisfied and adequate stability margins are achieved, the controller model is converted to discrete time for further investigation of update time, multi-rate sampling, fixed point implementations, time jitter, quantization, time delays, and other issues. The level of confidence in meeting the design requirements during the SIL phase depends significantly on the accuracy of the plant model.
Unlike code based controller development (C, JavaScript, C#, Python ...) where the lowest common denominator building block is a line of code, MBD uses block diagram models as the common denominator. All design changes are made by modifying or augmenting models. The automatically generated code from a model is never directly altered. Models developed during the SIL phase are reused and possibly supplemented with additional models as development moves into the Processor-in-Loop (PIL) and Hardware-in-Loop(HIL) phases.
Modeling of systems of any complexity rely on a hierarchical block based architecture. In solidThinking Compose, Activate and Embed(sTCAE), Compound Blocks are used to encapsulate models or parts of models into sub-level blocks. Compound blocks save screen space, hide unnecessary detail, can be easily replicated, can be controlled to operate as needed, and preserve calculations from accidental change. The number of compound blocks and the number of levels in the hierarchy is limited only by the hardware limits of the Host computer. Compound blocks receive input signals through their input pins and provide output signals through their output pins.
Access to compound blocks may be restricted to protect intellectual property contained therein using either of two methods; password protected and read-only. Passwords may contain up to 10 characters and include any combination of case sensitive letters and numbers. If a compound block is password protected and locked, it can be opened, viewed, and edited, provided the correct password is used. Additionally, if the compound block is set to read-only, it can be opened and viewed only.
In the solidThinking Embed tool for example, compound blocks have several key features worth noting. The Create Dialog from contained Dialog Constants provides the ability to create popup menus with default values to configure compound block parameters. Enabled Execution provides the ability to conditionally execute the compound block. The triggering mechanism to execute the compound block may come from logic within the model or, if you are using solidThinking Embed with a Target, it could be through an interrupt. Local Time Step provides the ability to execute the compound block at a specified update time, this feature and Background Thread is especially useful for embedded applications with hard real time constraints. Finally Use Local Bounds provides a "do loop" capability useful when reading or writing serial information in embedded applications as well as performing calculations that require iteration such as Newton-Raphson division. The 3D plot to the right uses two nested "do loops" to produce a three dimensional image.
