Carrying on from the previous post on the Introduction to System Modelling Before Building Models, which details preparing to build a system, this post will focus on what to consider when building models and systems.
Where to Start?
It can be very difficult to know where to start making a system. Once you’ve considered the points mentioned in the previous post, you should know the scope of the system you’re trying to model. But this can also give you indications of where you should start as well. Discussing with a specialist can give you great insight into what to look for or what pitfalls to look out for.
Most likely, if you’re not modelling a totally novel system, there is a library that could be suitable to your needs. This should allow a lot of streamlining regarding development time and costs. The example below shows an example of a hybrid vehicle model from the VeSyMA library. Most will provide both templates and examples to help build and guide you. Vendors and developers are usually very happy to discuss with you the best way to achieve your desired outcome. But it is always preferable to have a broad understanding before opening discussions.
Once you know the system and fidelity that you want to model, it is very useful to look at any pre-existing examples. If you can look at a working example of the system that you’re going to be modelling, even better.
First thing that you need to get your head around is what the example system is doing. Next you need to evaluate what is different about the system you want and the example you’ve got.
Reviewing Example Systems
So, you’ve got an example, or better still several examples, that you can look at and review. What do you need to do to understand it, and what can you gain from it?
First thing to check is, does the system example run in the tests that you want to evaluate? It’s an obvious question but sometimes easily overlooked. Can you find or create a test where this system example works? For example, if your aim is to use the system in a vehicle and run a double lane change test; can you create or modify a vehicle that incorporates a preexisting sub-system similar to yours? And then can you simulate the example in a similar test? If so, great.
Example Experiment Troubleshooting
If incorporating your system model into a pre-existing larger system doesn’t work, why not? There are lots of possible issues that could arise, so many that listing them all would be a fool’s errand trying to name them all. In a broad sense there are 3 areas where failures could occur:
- System Failure – The system will not run; there is something missing, something that isn’t connected or something that will not interface properly. This could be because the chosen (sub)system was not designed to be used in the application, or you’re missing a key element/connection. I would recommend trying to find other examples and see what’s different; then trying to change one sub-system or component for another one at a time and see what component “breaks” the experiment.
- Initialisation failure – A very common issue that can be difficult to diagnose. You’ll normally see this when the system tries to simulate but either fails because something can’t be calculated at the start; or the system initialises doing something unexpected. If you can’t get it to even start, it’s recommended to break it down into sub-system experiments (bench test) and see if you can get the initialisation right there. If it’s initialising oddly, try and trace the unusual behaviour back through the variables to the source of the problem and adjust start conditions.
- Simulation failure – Very similar to initialisation, it could be because one system or model has reached the limit of its capability. This may not be within the system you’re modelling. But your (sub)system change could have a larger knock-on effect on the overall system. Again, breaking it down into sub-system tests can be very useful in isolating issues and finding limitations.
There is a full blog post regarding troubleshooting a failing Dymola model that could help you get your model working if you’re working in Dymola.
Example Experiments Evaluation
Once you’ve got an experiment running, next find and interrogate the variables you want to investigate:
- Do they exist?
- Do they look sensible in the context of the system modelled?
- Does the rest of the system perform as expected?
- Is the overall system negatively affecting the model you’re interested in?
- Is the fidelity correct?
- Are you seeing the variation of the signals at the frequency/magnitude you would expect?
Most importantly, do you understand the model? Do you understand how it behaves and do you know how to troubleshoot it when it doesn’t? Can you control the model effectively to find edge cases or tune the experiment?
After completing all of this, which may take some time, you will not have started making your system. But you have gained understanding of what you need, both in terms of required data and the models to be created or modified. Now is also a good time to review the original scope of project, can you still get what you need from what you have? You should also gain good understanding of how your system should run, and how to get it running if you have any issues.
How Best To Build Systems
There can be many creation routes to build the same system or component. Below briefly outlines some of the most common ways, with pros and cons associated with each. From least to most work:
| Building method | Description | Pros | Cons |
| Parameterise Pre-Existing System/Models | Duplicate and modify library supplied systems that match the structure and ability of your desired systems | -Least amount of work required -Most amount of supplier support -Structure and systems tried and tested -Most amount example experiment -Guides can be included to lead you | -Least amount of user control over system architecture -No novel components/experiments -Largest amount of learning of external library required -Highest initial cost |
| Building Models From Interfaces/Templates | Some tools provide a hierarchical system of model development where the layout and structure is defined and users have choices of sub-systems models to parameterise or modify. | -Only pick and choose models to suit application -More examples to improve understanding -System definition established -Time is spent only on developing novel components and applying parameterisation -Supplier support available -More examples of systems | -Less user control as templates controlled by supplier -Some time required to understand library and systems |
| Building Systems From Generic Components | Building systems and sub-systems from a library (or libraries) of generic component | -Focus time on system development -Relies on validated components -Quickest way to create novel systems -Component example tests | -No system templates -No parameterised models -Time consuming -Little amount of supplier support for system -No system example models |
| Build Everything From Scratch | Building everything yourself, without any outside models | -Full control over all models -Full understanding of all models | -Very time consuming -Most likely to have issues -Validation of components is all self-generated -Templates and structure also require development -No supplier support -No examples to compare/build from |
In reality, when creating a system, it will most likely entail using a combination of some or all of these ways of working. Commonly creating your system entails creating novel sub-components and using them with modified pre-existing components.
Choosing a Method
With that in mind, in my opinion, the best way to approach building any system is to start with the top of the list, and work your way down. This helps both in time saving and model reliability:
- If you can use pre-existing models that match the layout, architecture, fidelity and ability of the system you want, use that. That only requires you to parameterise components.
- If the system doesn’t exist, but the sub-systems and architecture do, then build a new system (or modify an existing one) to suit your purpose.
- When you require a novel system, see if you can use pre-existing interfaces and components, to lessen workload and improve interfacing.
- If you need a novel component, try and use generic/ideal components initially to get the system working, then refine. You can always improve efficiency after you’ve got a system working.
- Last and worst case is that you need to create something from scratch. This can be a laborious process and requires more understanding of the appropriate language. It also requires a lot of forward planning of systems to make sure that any future development is accommodated.
Building Sub-Systems And Models
Whether you’re building a novel system or building on the templates/architecture of another library, it is always best to break systems down to sub-systems and components. Don’t try and build or modify the whole system in one model. This helps in a great many ways. It can help isolate issues; aid troubleshooting; allow you to test components in isolation; give you easier replaceability and gives a more structured development. But the key benefit is that making lots of simple components then combining them is the best way of making sure that everything works as expected.
In most modelling tools there are specialist libraries but there are most likely lots of non-speciality libraries, such as the Modelica Standard Library. These give you generic components that are widely applicable, allowing you to build systems from generic parts. This reduces your work down to just making the novel parts for your system and making the system. Components such as masses, calculations, functions and animation blocks can be of help and a great time saver.
Bench Tests
Next it is best to create isolated component tests. These come in many forms, but they essentially test low level components, or sub-systems, to check that they work. The simpler the test, the easier it is to verify and ensure its working correctly. This is the best way to find issues before you assemble everything to build the larger system model. If you know that everything works in isolation but fails as a system, the problem exists in your system construction.
Plan Ahead
Finally, it is always best to plan ahead and add as much structure to your development as you can. Make the models easy to understand and easy to modify. Putting the ground work in early can help in the long run. Reverse engineering/restructuring complex systems can make it very difficult to find issues. Getting the structure right to start helps you all the way through the development.
If you can animate components, such as multibody systems, then it can be a great way of easily spotting issues early on; seeing a spring or connection in a wrong place is a lot easier to see when in context of a system animation.
Written by: David Briant – Project Engineer
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion