Every model needs some TLC, but how do you make make it easy to give the model the care it needs?
Maintenance starts with the foundation. The foundation of a model consists of the guidelines that are followed. In the MATLAB./ Simulink world that means using the M.A.A.B. style guidelines. The Modeling guidelines focus on model readability and correctness; so what is the “first floor” in our house?
The “correct” size
Size is not an absolute number, rather it needs to be viewed in a metric encompassing complexity, number of associated requirements and commonality of the blocks & code.
Common code: e.g. Reuse
The more you can reuse code across portions of your project (or projects) the simpler maintenance becomes (though you need to have the highest level of validation for reused code). For an overview of reuse I will reuse this blog.
What is complexity?
Like reuse, complexity is a topic I have covered before. The key take away here is to link complexity to maintainability; lower complexity generally means easier to maintain models. However, there is an absolute complexity to any problem e.g., you can’t make a problem simpler than it truly is. Arbitrary decomposition of a complex problem into smaller subproblems can increase the complexity of the system by making it difficult to understand the data or concept flow. Which brings us to…
Requirements and maintainability
The ultimate metric that I recommend for ensuring that models are easy to maintain is linked to the number of requirements per model. Ideally each model will be associated with one or two top-level requirements.
Since maintenance of the model is associated with either changes to the requirements or bugs found in the field, the more top level requirements associated with a model, the more frequently the model will need to be updated.
Updates to a model requires the revalidation of the model and associated requirements. If you change a model with only one associated requirement you only need to revalidate that requirement. If you change a model with multiple requirements, even if you are only changing with respect to one you need to revalidate all of the requirements. Every time you pull out a thread…
Raise the roof!
To finish our “This Old House” metaphor, we will talk about the roof. In this case the roof is our test cases. In most if not all cases of model updates the test cases will need to be recoded and revalidated. This is a secondary reason to limit the number of requirements associated with a given model; the more requirements the more test cases that must be updated.
Built well and and with proper care, your model can be a home for generations to come.
