This step is also demoed with this video :

(ongoing...)

Step 3c : Attach a model configuration to an assembly

Starting with this raw Simulink model :

architectures and modules have been created so that the new Simlulink model turned into :

Logically, the architect wants now to integrate the overall monitoring system flag mon_system in the architecture archi_traininng_vU1 :

Usually, when integrating new code in an existing one, questions are :

• • can this piece of code be allocated in the existing architecture?

  • or does this architecture have to be modified?

First, this code deals with monitoring, the room mon_ has been created and inserted inside the architecture for that purpose.

It is logical to insert this code in this mon_ room.

Secondly, a module mon_... must be created : it's done with the module mon_system_v000d000 :

Once it's done, module mon_system_v000d000 can be inserted in an assembly and auto assemble upon archi_training_vU1.

The assembly abl_training_vU1d1 has been provided in this way in the tutorial, and then if you auto assemble it,

the newly module has been automatically inserted and connected.

As we can see, the system monitoring flag is calculated but has been detected as not used, it has been then connected to a terminator.

Moreover, this module needs these signals target_YawRate, target_LatAcc, FB_YawRate, FB_LatAcc.

Though, these signals are indeed calculated in the target_ room and FB_ room but are not transmitted to the mon_ room, they are unavailable.

Architect has then to fix :

• 1. unavailable signals

  2. unused signals

For the first point, architecture has clearly to be modified to feed the mon_ room with results of targets_ and FB_ rooms.

Architecture archi_training_vU1 has been modified in that way to archi_training_vU12 :

The assembly abl_training_vU1d1 has been evoluted to abl_training_vU1d2 attached to this architecture archi_training_vU12.

Then, the auto assemby of abl_training_vU1d2 produces :

As expected, MTX detected that signals target_YawRate, target_LatAcc, FB_YawRate, FB_LatAcc are available thanks to the new routing of archi_training_vU12 and can be then be connected.

For the second point about the unused system flag monitoring mon_system : like the other flags mon_can_LatAcc and mon_can_YawRate, this flag is useful for modules FB_LatAcc_ and FB_YawRate_.

So both of these modules are updated to FB_LatAcc_v006d000 and FB_YawRate_v006d000

The assembly abl_training_vU1d2 has been evoluted to abl_training_vU1d3 with these two new modules.

Then, the auto assemby of abl_training_vU1d3 produces :

System monitoring flag mon_system is now used.

Note that it creates two invalid function-call connections : they are treated by automatic insertion of Unit Delay 1/z thanks to the insertUD option set to 1 (see Steps 2c & 7f).

At this stage, all the initial simulink model :

is inside an auto assembly :

based upon this architecture :

Next step can be the inregration of the inputs and outputs when coming from an other plaform, like quick prototyping :

As done before, the architect draws a new architecture in this way :

and it finally yields archi_training_vU13 :

This is a closed architecture.

The assembly abl_training_vU1d3 has been evoluted to abl_training_vU1d5 using this architecture and rawCan_, rawAna_, canTx_, anaTx_ modules :

In steps 2 & 3, Simulink functionality auto assembly has been explained.

Both next steps 3c and 3d give details about :

• • the assemble process

  • the 'Go To' module functionality with an assembly

Published with MATLAB® R2013a