This step is also demoed with this video :

(ongoing...)

Step 1 : ASSEMBLY

With the previous steps, tutorial went through modules functionalities.

In this step 1 and sub steps of step 1, tutorial deals with basic functionalities on Assemblies and Simulink functionality model synchro

As explained in the presentation of the tool, an assembly logically comes after having defined modules :

An assembly is nothing more than a set of modules.

It aims to actually define the modules that user would like :

• • to be part of an existing Simulink model : Process 1

  • or to be automatically layed out and connected upon an architecture : Process 2

This step 1 is dedicated to the process 1, this is to say compare content of a Simulink model with an assembly and synchronize these two contents.

Process 2 deals with architectures and auto assembly of an assembly upon an architecture. Steps 2, 3 and 5 are dedicated to this process with :

• • Step 2 : auto assembly upon empty architecture

  • Step 3 : auto assembly upon unempty architecture

  • Step 5 : designing architectures

Taking a look at the functionalities figure, process 1 is actually the model synchro functionality and process 2 is the auto assembly functionality :

Whatever the chosen process is and prior to that, user has to operate basic functionalities for an assembly, such as creation, removal, etc... as it was the case for modules previously.

Fundamentally, basic functionalities for assembly are exactly the same as for modules :

Instead of using the MODULES view, the ASSEMBLIES view is used :

As explained previously, modules must start with a prefix, for example 'prefix_'. To be easily recognizable, rule is the same for an assembly, except that the prefix is 'abl_'.

In step 0, family of modules FB_LatAcc was first created. Here, let's create the familes of assemblies abl_thisIs_ForTrain.

Then user can enter the requested family name and leave a comment, and press Valid when completed.

Next step is to create a version. As a user version, it starts with vU, as an example, let's begin with vU0 for abl_thisIs_ForTrain family.

(exactly as for modules, the other capitalized type of version exists, it is explained in Step 6 : Community functionalities).

enter a version and a comment and Valid :

The new version appears in the list of versions :

An assembly does not have Simulink library, but like module, it does have its calibration script that you can open by pressing the Open button :

This file is available in this folder :

There is the same evolution principle, like for modules :

For example, to make an evolution of abl_thisIs_ForTrain_vU0 to vU1

• • in the ASSEMBLIES view, select assembly abl_thisIs_ForTrain_vU0

  • and press Evolution in the 'Management zone'

Then appears a rank 2 GUI to enter the evolution name and comment :

The new version then appears in the list of versions available for 'abl_thisIs_ForTrain':

Basic functionalities on assemblies have been explained :

As said at the beginning of this step :

• • an assembly can be compared with a Simulink model and be synchronized with it : this is the model synchro functionality

  • modules of an assembly can be auto assembled upon an architecture, i.e. automatically layed out and connected : this is the auto assembly functionality (see step 2 & 3)

model synchro functionality uses a Simulink model as source to synhcronize modules between this Simulink model and an assembly.

Once the list of modules has been establihed on both sides, classical synchronization operations are available :

There are two other sources permitting to add and remove modules from the assembly : user's modules and another assembly

Further step 1a specifically deals with this Source Modules,

whereas further steps 1b, 1c, 1d deal with the Source Models, i.e. the model synchro functionality,

and step 1e deals with the Source Assembly, i.e. synchronization between two assemblies.

Published with MATLAB® R2013a