This step is also demoed with this video :

(ongoing...)

Step 1f : Impact of copying modules on assemblies

Step 0i explained the copy functionality of a family of modules :

At this step 0i, we've seen that a table is available on the right :

What is it for?

This table aims to manage potential impact of assemblies containing a module which is currently in copy process.

Indeed, suppose that some assemblies use a module from the family FB_LatAcc, and this family is currently copied to FB_LatAcc_copy,

User may want that for these assemblies FB_LatAcc turns into FB_LatAcc_copy :

This table enables this choice, for example, if user wants to modify only abl_synhcro_vU0, the matching checkbox can be checked this way :

As a result, you can check that FB_LatAcc is still in use in abl_anOtherOne_vU1 :

whereas FB_LatAcc_copy is now in use in abl_synchro_vU0 instead of FB_LatAcc :

Main possibilities of the synchro functionality have been explained so far.

This step 1 was dedicated to Assemblies and model synchro Simulink functionality.

The two following steps 2 & 3 deal with auto assembly Simulink functionality :

• • Step 2 : upon empty architecture

  • Step 3 : upon not empty architecture

Building architectures is a specifc task explained in step 5. Architectures used in step 2 and 3 are already designed.

Published with MATLAB® R2013a