Modeling is the art of deriving equations to represent the pertinent.
What constitutes "the pertinent" depends on the particular analysis being performed and the maturity of the design. For example, worrying about getting a sensor bandwidth accurate to the 1/100th of a Hz before operating conditions (including disturbance profiles) are well defined is usually a waste of time. The sensor may change because operating conditions dictate the sensor must survive certain shock loads or temperature variations.
First order effects are the place to start. Second order effects are usually modeled but third order effects are only modeled if the precision of the analysis result require it. Also, acquiring the necessary data for proper modeling of third order effects is typically time consuming and costly.
Simulink block diagrams in their default form are difficult to read. Difficult to read means difficult to maintain, especially for anyone who is not the original author. There are some simple steps for making Simulink models more readable.
- Label everything with a meaningful name and units. Not abbreviations unless they are obvious to everyone which really means obvious to the village idiot.
- Scopes will use your labeling information allowing for immediate use of scope data as results data and more automated post-processing scripts.
- Mask subsystems and add pictures to each subsystem's mask.
- Adding pictures to a subsystem after has been masked in Simulink is easy to do. The most time consuming part will be finding the correct picture.
- Layout the model in a logical order. Simulink disregards this information but it makes the model easier to follow, maintain, and extract intermediate infromation from.
There are 2 benefits to making your Simulink models more readable.
- Easier development and maintenance
- Direct Copy-and-Paste into PowerPoint or Word
The benefits to maintenance are obvious. If the subsystems have pictures and someone is looking to update a sensor model they just look for the picture of that sensor. If all signals are labeled well then it becomes obvious that swapping a rate sensor with an output of deg/sec for one that outputs rad/sec will require more effort than simply copying-and-pasting a new transfer function and noise model in. Without the labelling it could be days before it is discovered that there was a units mismatch.
The benefits to development come primarily from having intermediate data in obvious places. The scopes will use the label information and intermediate scope will automatically present meaningful information without the need to trace out the exact signal that feeds that scope.
The benefits for presentation of the model and its results is underestimated. Everyone likes a well formatted picture of the model being developed and used. A picture of a well formatted Simulink model can serve as both a picture of the model and the system block diagram.
3 Instructions for modeling individual components
3.1 Start with the low hanging fruit
Most models have both simple components and complex components. Also, the current system being modeled is often just the next generation of a system that has already been modeled in Simulink. This leads to 2 types of low hanging fruit:
- simple components (i.e., second order systems with band limited white noise)
- components that are shared or at least similar between systems
Most individual sensors and actuators that can be procured commercially can be modeled with a second order transfer function. Noise modeling is more complex but a good initial approximation can usually be achieved by using band limited white noise with a careful choice of PSD magnitude.
Components that have already been modeled for other systems can be copied into the new system during early stages of model development. The component doesn't have to be an exact match in the early stages. However, copying a pre-existing component (especially one validated against test data) allows for a more realistic representation of acheivable system performance. The final system performance may be better but what you've modeled is realistic.
Copying component models allows the modeling engineer to focus on components that have not been previously modeled and on reasonable estimates of system performance. These early models can lead to trade studies regarding certain techniques with different fundamental pros and cons. Copied component models can always be updated or upgraded later.
4 Quick Verification of Component Models
Quick verification is intended to determine if the model behaves as expected not if the model behaves as the real-world system would behave. Vadlidation to test data is required to determine if the model accurately predicts the model in reality.
Quick verification checks typically involve a constant, well understood, input such that the output is reasonably predictable. For example, a simple matrix multiplication block could be tested against a matrix full of zeros, and identity matrix, and 10x the identity matrix or something else intended to test diagonality or some other condition. The constant for testing a bandpass filter would be a single sine wave with a frequency equal to the bandpass frequency and 2 others with frequency far enough away that they shouldn't pass through the bandpass filter.
In this manner each component can be tested. As each component is test and verified to work correctly you check it off the list. Then integrate all the components into a single model.
5 Integrating Models
Always start simple. Start with simple or well understood components. Then build onto those components with one or more additional components. Test that the output of these combined components is as expected. Double check units (i.e. degrees vs. radians, meters vs. feet, etc.) and coordinate transformations. Then add the next layer of components and repeat.
It is suggested that any controller be added as late as possible in the integration process. Once feedback is introduced to the system it is difficult to determine if the system is unstable or behaving oddly because of a units, coordinate transformation, or controller issue. With feedback in the system the ability to determine the source of many irregularities becomes impossible for all pratical purposes.
Results are the point of the model. Typically the customer is interested in predicted performance as it compares to system requirements. With the proper toolboxes from the Mathworks direct incorporation of final performance requirements into the model can make sense. However, most engineers don't have these toolboxes (such as the Optimal Response Toolbox) so it makes more sense to compare the predicted performance against the requirements in post processing.
6.1 Requirements Comparison
It's best to present predictions against the performance requirements. For requirements that are out in the open a simple line (red is a good color) on a plot with the predicted results makes for an adequate if not good presentation. For more sensitive requirements the use of normalized plots where the requirement would be a red line equal to 1 with the predicted performance being plotted only after having been scaled or normalized to the requirement is generally acceptable.
- Mechanical System Modeling Notes from Dr. Psiaki at Cornell, May 2008
- Mechanical Modeling Notes from Dartmouth, No Author Attributed
- Mechanical Systems Modeling by Dr. Buckman at Univ. of Texas
- Electrical System Modeling Notes from Dr. Psiaki at Cornell, May 2008
- Op Amp Circuit Modeling Notes from Dr. Psiaki at Cornell, May 2008