Best practices and tips for versioning and merging complex Simulink models

Greetings,

I work within the automotive industry where we recently started up a new Simulink project. We are basing the work on previously used libraries but are now diverging from the originals as we are adding and changing as the project goes on. One of the goals with this project is that we want to use a more software like development setup for versioning where we are using feature branches and merging models.

One of the issues that we have found is that there will be a lot of conflicts, could this be caused because we have complex models or are this to be expected? We have also experienced that there are problems selecting theirs in the three way merge sometimes, selecting theirs will result in errors like the block could not be found.

One example is seen above, where the signals have been removed in theirs (right) (the version I would like to keep) but in the target (left) the signals have been moved and not removed. It is not seldom that it is simple things that does not merge automatically.

As you can see in the picture there are a lot of conflicts that have been resolved automatically but there are a lot of changes that needs to be handled manually. Even though there are a lot of aesthetic changes, it will take a long time to step through them all, especially since there are 10-15 files to resolve conflicts.

What are your tips and best practices working with versioning in Simulink? The obvious answer is to not try to merge large projects, but that solution does not seem very progressive. I have looked around but I have not really found anything were there is more complex models involved, any links we should checkout?

Thanks!

Answer 1

[Steven Green]

Hi Adam,

Thanks for taking the time to send this question with detailed feedback on the tool. As with large complex source code files, large complex models can sometimes take some time and concentration to branch and merge. I’ve included some guidelines for versioning and merging Simulink models below. Hopefully you will find some of these useful.

Versioning Simulink Models:

A lot of the best-practices for versioning and merging program source code also apply to Simulink models. For example:

• Make small changes often and integrate branches frequently.
• Break up your Simulink project into small manageable models using, for example, small libraries and model references.

Using Simulink Three-Way Merge:

When using Simulink Three-Way merge with a complex model merge sometimes working through the merges in the following order can help.

1. Use the ‘Filtered View’ with the ‘Lines’ filter enabled to first perform the block and parameter merges.
2. Disable the lines filter and then perform the line merges, manually correcting merges, like the one you describe above, where the tool hasn’t quite got it correct.
3. The remaining merges should be largely cosmetic or aesthetic merges as you mention so at that point you could decide to just accept the default ‘mine’ versions for these cosmetic changes knowing that they won’t affect the model's behavior.

Related links:

• Blog: Guy on Simulink - Three-Way Model Merge and Git
• Doc: Merge Simulink Models from the Comparison Report
• Doc: Component Based Modeling

Best wishes,

Steven

[Scott Snowden]

It seems that Simulink struggles to differentiate between blocks which have the same names (I expect this is because the block name or path is used as the unique identifier for blocks). Therefore, if say, a model contains a 'Sum' block called 'Sum1', and I copy and paste to reuse it, then Simulink will increment the block name to 'Sum2'. If another contributor does the same, but for some different logic, then they will also have a block called 'Sum2', but performing a different function. I think this will generate a merge conflict which will not resolve correctly automatically, and in fact, the tool does not even allow to select both versions of 'Sum2'. See the attached image for an example.

Presumably, there would be various ways Simulink could handle this better - perhaps at least not select an automatic resolution, plus give the option to choose both 'Sum2' blocks and rename one of them. As developers are we expected to give block names according to their function to avoid this conflict? I couldn't find anything in the MAAB style guides or elsewhere with a cursory look. Text based languages are less likely to suffer this problem, because new lines of code will always be considered as required in the merged version, and if they happen to be on the same lines in the 'Mine' and 'Theirs' then there will be a conflict. KDiff3 will handle this situation on text based files by either auto-merging all new lines, or indicating a conflict and allowing the user to choose any combination of A,B,C (Mine, Theirs Base)

Of course, the reverse issue is also true, in that two developers could create exactly the same functionality, which we would ultimately want to be merged into a single example of that function, but Simulink may not see that if the block names are different. Text based languages would have the same problem, however.