MATLAB: How are Simulink Requirement links stored

controlgitperforceRequirementssimulinkSimulink Requirementsversion

Our team is working together on the same Requirement Set using version control. We are noticing some strange behaviour on the Simulink Requirements links. Sometimes we get warnings about unfound paths from our colleagues local file system.
To investigate what is happening, I ran the following script:
rs = slreq.load('MyFile.slreqx')'
reqs = find(rs, 'Type', 'Requirement');
for i = 1 : nume(reqs)
   req = reqs(i);
   lnks = req.inLinks;
   for j = 1 : numel(lnks)
      lnk = lnks(j);
      disp(lnk.source.artifact);
   end
end
which returns a list of lines with absolute paths ('C:\ … ') including paths from my colleagues file system. At the same time, there are lines with just the model name. After checking, and all the entries corresponding to the local file system are on the MATLAB path but, again, some of them are returned as full path, and some just as the file name.
Hence, I have the following questions:
1. Which links are stored as filename and which are stored as full path?
2. How to avoid full paths in newly created links\s?
3. Is there a way to change the full path to filename in existing links?
4. Is it possible to avoid the warnings from my colleagues files?

Best Answer

When you display the value of link.source.artifact, this is meant to display the "resolved" path to artifact, in the current session. This is not necessarily what was loaded. The stored and loaded full path to artifact may be different if stored by another user on another workstation. If you make any changes to the links that require resaving the LinkSet, the best known path to the linked artifact will be captured in the updated .slmx file. However, if you do not resave the .SLMX file, the stale full path may last for a while. It is expected that files move between workstations and folders, and the stored folder path should not be taken for granted. When the linkSet is loaded by the next user, there are two cases to consider:
1) linkSet is loaded as a post-action of loading the linked artifact; for example, you open a Simulink model, the associated .SLMX file is located and loaded. In this case the location of artifact (the .SLX file) is known for sure, and link.source.artifact will display the correct full path to it. If you make and resave any link changes, the updated full path to artifact will be stored.
2) linkSet loaded as part of "discover incoming links" process when you start by loading the Requirement Set. This is the use case exercised in current support ticket. The source artifacts (models) are not loaded, you are loading a Requirement Set, and the available metadata is used to locate dependent LinkSets. In this case the .SLMX file may get loaded before the location of .SLX file is known. When we can locate the corresponding .slx file on MATLAB path, the value of link.source.artifact will reflect the correct full path to the matching model file on MATLAB path. However, if MATLAB fails to locate the .SLX file for the loaded incoming linkSet, you may see a short model name displayed by the link.source.artifact API.
For the cases when just a short name is displayed, please check whether the model is on MALTAB path.
The cases with the incorrect full path, allegedly the full paths from other user's workstation, may need extra effort to understand. This should not happen under normal circumstances. One bad situation happens when the .slmx file was manually renamed on the file system outside MATLAB. For example, USER1 had MODEL1 linked to a requirement set, model was renamed as MODEL2, and this resulted in two .SLMX files, MODEL1.SLMX and MODEL2.SLMX; later a subset of files was passed to USER2, and MODEL2.SLMX was missing, USER2 knows that MODEL2.SLX is a very close copy of MODEL1.SLX, so they simply make a copy of MODEL1.SLMX into MODEL2.SLMX. Now, when MODEL2.SLMX is loaded when looking for incoming links for the requirement set, the internally stored model name does not match, no adjustments are made to the internally stored full path, and you may see the outdated full path displayed as link.source.artifact value.
Related Question