This step is also demoed with this video :

(ongoing...)

Step 6d : Synchronization process

Previous steps explained import/export and capitalization of the Comunity functionalities :

This step specifically deals with the synchronization, which is actually the dual process of capitalization process :

As the capitalization process, there must be first a declared server, which is already the case in this context 6d :

By pressing the Synhcro button, user will get a status of local content in comparison with content of activated server.

There is a status for each prefix, and for prefix FB_, status is :

• • for the prefix FB_, there are 2 modules present on the server and not locally : FB_LatAcc_v000d000 and FB_YawRate_v000d000

  • for the prefix FB_, there are 0 module present locally but not on the server

Then, if user wants to get both modules FB_LatAcc_v000d000 and FB_YawRate_v000d000 from server, user selects these modules and the action Copy selection locally must be chosen (default configuration) :

Important remark : theoretically, additional modules on the server can be either copied locally or deleted from the server.

On the principle, once a module is on the server, it does not aim to be deleted. This possibility has been maintained in the GUI but it is not recommended.

Once the capitalization is done, both modules FB_LatAcc_v000d000 and FB_YawRate_v000d000 are present locally :

As we can see, a version is always associated to its Origin version : this association enables to maintain the traceability between modules.

The principle is simple : to be capitalized, the Origin version of a module must be equal to the highest version of a family on the server.

If it's not the case, it won't be possible to capitalize this module.

To illustrate traceability, suppose that two users User #1 and User #2 works locally on their PCs on versions respectively vU1 and vU2 :

Moreover, there is not capitalized module of FB_LatAcc yet.

Suppose that on Monday, version vU2 of User #2 is good enough to be capitalized. It is then capitalized for the first time with the version v000d000 and the traceability process can start :

Suppose that on Tuesday, further development of User #2 are worthy to be capitalized, version v001d000 is chosen and the traceability becomes :

At this stage, state of the art for FB_LatAcc is version v001d000. Suppose then that User 1 wants to capitalize its vU1 version coming from no version.

Since this version does not come from the highest version of FB_LatAcc on the server, it means that it does not come from the state of the art of FB_LatAcc.

As a result, it is not possible for User 1 to capitalize its vU1 :

Messages from the GUI is in this case can be :

If User 1 has significant modifications to add to FB_LatAcc, he needs to :

• • create an evolution (for example vU3) from the current state of the art of FB_LatAcc, i.e. v001d000

  • merge its modifications from vU1 into vU3

At this stage version vU3 can be capitalized, for example into v002d000 :

Version v002d000 is the new state of the art for FB_LatAcc.

Note that User #2 has to update its working version to work upon an uptodate version.

In terms of process, if there are recurrent conflicts between one or several users while capitalizing , this means that the architect could advantageously split the module, so that User #1 and User #2 can develop independantly.

As mentioned previously, community functionalities are available for modules, assemblies and architectures :

At this stage, all functionalities have been explained.

The 3 remaining sub steps 6e, 6f and 6g explain details about capitalized feature.

Step 7 list the options available for the users.

Published with MATLAB® R2013a