On Simulink (some beginner tips)
[Feb 2025]
Intro: This post covers some beginner tips for Simulink. I recently took on some modelling work with these tools and have learned some lessons. Hopefully, someone will find this useful and insightful.
Terms: Simulink is a graphical model building and simulation tool. It sits on the MATLAB language1, which can be used to set input variables and run Simulink models via scripts. Simscape blocks are special Simulink blocks that come with logic specific to certain physical systems (gas, air, mechanical, three-phase, etc.).
This brings me to my first tip. If in doubt, always stick to Simulink blocks, and stay away from Simscape. When Simscape is truly required, it brings with it logic that would be incredibly verbose – if not impossible – to replicate in pure Simulink. However, it requires more inputs and compute. When thinking about the system you wish to model, do you know the fundamental principles/equations that drive it? Do you care about the subtleties where those equations aren’t strictly true? If not, then stick to Simulink blocks and capture the math. It will become clear when you need to move to Simscape.
The first question above leads to the most important tip when using any modelling tool: if you don’t understand the fundamentals of the system you wish to model, no tool will help you. Start with the equations and principles you know to be true. Modelling is all about capturing the most important dynamics as simply as possible2. Blocks you do not understand have a magic ability of not working for you. This also explains why the Simulink Help Center can seem unhelpful if you don’t understand the block you’re attempting to use. Do you know what a Two-Quadrant DC/DC Converter is? If yes, check the docs for its implementation in Simscape. If no, don't go to the Help Center looking for an explanation of the fundamentals. This is the way it should be.
Next, not all questions are Simulink questions. There is always the temptation to empirically find out how X affects Y, but empirical runs carry assumption baggage and time costs. If you can3 quickly do the math or dimensional analysis to answer a question without your model, do it. It gives you a more robust answer.
Models should have objectives. Optimising subprocess capacity and storage size to minimise cost? Then model the component’s dynamics simply, or even black box4 them. Without clear objectives, you risk creating models that attempt to answer low-level subprocess questions that could be addressed more simply—and conversely, using verbose subprocesses for high-level questions that should be streamlined. Simplification aids both reliability and speed.
misc tips:
- Deny the urge to quickly push new logic into a MATLAB function block. Yes, they’re less verbose than replicating math in Simulink blocks, but they are harder to debug and can block plant linearization for features like PID control. If you find yourself writing many MATLAB function blocks, consider using MATLAB scripts instead.
- Annotate the Simulink logic with a text box that explains the functions. This enhances readability and aids debugging.
- Become a GOTO maxi—but stick to a logical naming convention.
- Ensure all flows have units of measurement. If you want the ability to switch units, some dashboarding blocks can help. Never leave units ambiguous.
- The Onramp tutorials are good, but 3x the time to complete "estimate".
- If the simulation appears to be failing, it is your fault. Debug!
On cost: To me, the entire Mathworks product suite is incredibly expensive, and the add-on pricing model is especially annoying. However, it does incentivise keeping things simple. The arbitrary 1000 block limit on a home license is egregious.
Footnotes:
1 Simulink models compile down to C/C++, which is helpful for control applications.
2 Simply enough to robustly achieve its goal.
3 It will be obvious where the inverse is true and you really need the model.
4 Have a separate focused model capturing low-level behaviour and create a mapping of input to output.