In a previous post, I wrote about general best practices for version control. In today’s posting, I am going to cover using version controls in the Model-Based Design workflow. Note for this blog post, I will be using generic terms for version control practices.
Derived and source objects
A derived object is any file that is generated from a source object or process. Within a traditional C language development process this would include
- .lib /.o / .exe
- Coverage reports
- Test results
- Data files
- …
Like a traditional text-based language approaches a Model-Based Design has both source and derived objects; in the case of Model-Based Design the design objects are one level of abstraction removed from the C source files (1).
Utilities and project files
Within the MBD development process, there are both project and utility files(2). Version control best practices map are influenced by the data and architectural best practices. We will look at how releases are defined within this context.
What is a release? When to release?
Within the Model-Based Design context, a release is defined as the set of data and models that
- Contains consistent interfaces: the interfaces between the parent and child models are correct and the data definitions are compatible(3)across all the models.
- Reached a significant milestone: the models and data capture a significant portion of the desired functionality(4).
- Is stable: the models and the data pass a significant(5) percentage of the tests associated with the model.
Keep in mind, releases should not be made on a temporal basis. E.g. having a release every two weeks is not a good practice unless the conditions above are meet (at least condition 1 and 3.) At the same time allowing a long time to go between releases can make it more difficult for developers to integrate into the final project.
Version control, models, data and the system architect
Best practices for model architecture recommend a multi-level (integration level/child level) systems. Within this structure, the controls engineers are responsible for the checking in/out of their models. Further, they are responsible for ensuring the data that is unique to their models is correct.
The role of the system architect is to ensure that the individual models integrate together. They do this through the following tasks
- Validate that the model’s functional interfaces are compatible
- Validate that the use of global data is consistent across models(6)
- Running system level tests
In the case where there is a conflict between the functional interfaces or the use of global data, the system architect is responsible for arbitrating those conflicts.
Summary thoughts
Version control best practice for Model-Based Design or any software development is, in the end, dependent on communication between the team working on the software. The larger the team is the more the need for communication increases. Both documentation of the intended process and linking development to requirements will improve this process. In the end, try not to be this group…
Footnotes
(1) For Model-Based Design, the “source files” could be C / C++ / VHDL / PLC or any other textual language.
(2) Utility files should also be placed under version control.
(3) For any given release the data may not be correct, e.g. having the final values as determined through requirements and testing; hence the term “compatible.”
(4) Note in some cases a release may be a ‘branch’ or experimental branch which may not be part of the final release of the software.
(5) The collection of the models and the data do not need to pass all tests, rather they should pass the tests that engineering judgment are considered significant at that point in time. However, it should be noted that best practice is that as release advance towards the final release the number of tests passing should increase.
(6) Globally used data includes parameters and variables as well as structure definitions and enumerated data types. As with all software development use of global data should be minimized.