By Seth Popinchalk, MathWorks
If you neglect implementation details when you begin building a Simulink model you may face unexpected errors and warnings later in the project. Here are some good practices for preventing that scenario.
At the outset, most settings come from the defaults. All the solver settings are configured to accommodate the broadest possible range of models, and many sources are configured to use the base rate, or continuous update. Data types default to double to ensure the most flexibility in the environment and enable you to assemble a high-level proof of concept.
As the design matures, it’s a good idea to lock down settings. By doing so you ensure that the final model meets requirements and that discrepancies between the design and implementation can be addressed early. You can lock down model behavior by doing the following:
The Model Advisor catches many common modeling errors and gives most users a good starting point for refining their model.
Simulink diagnostics provide checks for problems that commonly occur when modeling with default settings (Figure 1). They are a first line of defense.
Most diagnostics can range between warnings levels of None, Warning, and Error (Figure 2). When you have corrected any settings that are causing warnings, consider raising the diagnostic levels to Error. This will guarantee that your model informs you when a design change produces a suspect behavior.
|Solver: Automatic solver parameter selection||Report solver parameters that are computed or changed from their specified values||Warning||Alerts you to changes in your model, such as the removal of continuous states or the use of default step sizes|
|Connectivity Buses: Mux blocks used to create bus signals||Alerts you to instances where elements of a muxed signal are being selected by a bus selector||Disabled||Enables advanced bus features. Raise this diagnostic to Error as early as possible in model development|
|Connectivity Buses: Bus signal treated as vector||Detects when Simulink converts a bus signal to a vector signal to anable it to be connected to a block that does not support buses||Disabled||Enables advanced bus features. Only available when the Mux used as bus diagnostic is set to Error|
|Sample Time: Multitask rate transition||Detects unspecified data transfer between rates||Error||Alerts you to the transfer of data components from different tasks in the model|
Figure 2. Key diagnostics.
Root-level input ports and inputs to atomic subsystems should be fully specified unless the atomic subsystem is required to dynamically size or inherit its sample time and data types. When bus signals pass through boundaries between components, use bus objects to provide this level of type and size checking. You can use Signal Specification blocks, but a better option is to add Simulink. Signal data objects to the model workspace to control type and size information. Fully specify Mux and Demux port dimensions by using vectors of widths to set the number of ports. For example, for a Demux with a vector of 8 elements at its input and 3 outputs of width 2, 2, and 4, the number of outputs is [2 2 4].
Use your knowledge of the model to set the appropriate step size for the solver. If you are working with a variable step solver, and using “auto” for the “Max step size” Simulink computes your maximum step size to be (Tstop – Tstart) / 50. Set the value explicitly to ensure that a change in simulation length doesn’t unexpectedly change the simulation. Uncheck “Automatically handle data transfers between tasks” and manually insert rate transition where needed.