This step is also demoed with this video :

(ongoing...)

Step 5b : Conditions for a valid architecture

To be valid, an architecture must fulfilled several conditions.

They are listed and explained in this step 5b, and illustrated with invalid and valid architectures.

For each condition, there are some examples. To install them, there will be a link to click on, it may take some time to install...

Once architectures are installed, you can proceed as as below :

• • select an architecture :

• • open it and/or ask for its validity, and get status :

Remark : you can modify the architectures and do your own tests, typically, try to make them valid. (modifications won't be saved)

• CONDITION 1 : the Simulink model of an architecture must be composed with a unique SubSystem at the top level

Install these architectures

• CONDITION 2 : an architecture must be exclusively composed with Inport, Outport, SubSystem, BusCreator

Install these architectures

• CONDITION 3 : SubSystems of an architecture must not be linked

Install these architectures

• CONDITION 4 : a room is only composed of 0, 1 or several inports, and 0 or 1 outport

Install these architectures

• CONDITION 5 : in a room, there must be no lines or unconnected lines, except at the top level of the architecture

Install these architectures

• CONDITION 6 : a room is named by a prefix like 'prefix_'

Install these architectures

• CONDITION 7 : a prefix can be found only once in the whole architecture

Install these architectures

• CONDITION 8 : in the whole architecture, there must not exist unconnected lines

Install these architectures

• CONDITION 9 : at each floor, inports, outports and BusCreators must be fully connected

Install these architectures

• CONDITION 10 : if an external entry finds a prefix name in a room, this external entry must find this same prefix in any other room it enters in

For this condition, preliminaries explanations are required.

During the auto assembly, each signal of each module must be connected to the inputs entering the room. There are two kinds of inputs :

• • those who come from the architecture

  • those who come from the outside of the architecture

MecaTroniX has to connect signal to one of these inputs, according to these following rules :

• • if signal is prefixed by a prefix coming from the architecture and entering in this room, and if provided, signal is connected to this input :

• • if signal is prefixed by a prefix coming from the architecture and entering in this room, but not provided, and there is no external entry, signal is connected to a nul constant :

• • but if there is one or more external entry, signal may be connected to the extern :

First it depends on the value of the option getSignalFromOutside (see step 7g). If it 0, signal is connected to a nul constant :

If the value is 1, signal may be connected to an external entry. Which one to choose?

• • if one external entry has been named as a prefix_ and it is the same prefix_, ana_ in our example, signal is connected to this input :

How to associate an external entry to a prefix_? It is done via the name of the inport in the room.

Remark 1 : there is no need to proceed in the same way for internal routing, because there implicitly defined by the room's name :

Names of these inports are not taken into account.

Remark 2 : once an external entry found a prefix_ definition in a room_, this same prefix_ must be explicitly found in other rooms.

For example, this is valid :

and this is not valid :

This is this condition 10 :

Install these architectures

Among thes architectures, consider the first architecture archi_cond_fa_vU0 of the list :

In room ana_, the entry n°1 enters as the prefix in1_. If an external prefix is found (it is not an obligation), it must be the same in any other room it enters in.

As in room can_, the entry n°1 enters with no prefix, the architecture is not valid.

This situation has been fixed with the next architecture archi_cond_fb_vU0 :

This is particularly useful when one assembly is feeding an other assembly.

Other installed architectures shows other configurations based on this rule.

Remark : name of inport/inport somewhere else than rooms are free and not taken into account at all :

• CONDITION 11 : in a room, among entries coming from the outside, there is at the most one entry not named by a prefix

Now condition 10 is explained, other explanations are required to introduce condition 11.

Let's go back to this situation :

in which signal ana_signal is not found internally and may be found thanks to external entries.

Suppose that, as shown on the previous figure, there are two external entries but none of them could be associated to any prefix_.

Then, it not possible to decide which external entry can be connected to ana_signal.

This is the reason why in a room, among entries coming from the outside, there can not be more than one entry not named by a prefix_

This is this conditon 11 :

Install these architectures

• CONDITION 12 : in a room, entries coming from the outside can not be named with the same prefix if any

As seen before, external entries can be named by a prefix thanks to the name of the inport, for example :

It is allowed to name different external entres with the same prefix_, for example :

as long as they are not routed in a same room, because if it is the case, it causes conflicts. As a result, this configuration :

is not valid. This is this condition 12.

Install these architectures

• CONDITION 13 : a room can not be routed to an other room several times

This kind of configurations

is not valid because a room enters an other room several times. This is this condition 13 :

Install these architectures

• CONDITION 14 : a room can not be routed in itself

This kind of configurations

is not valid because a room enters in itself. This is this condition 14 :

Install these architectures

• CONDITION 15 : if any, sampled subsystem in the architecture must be consistent

If any sample time are defined in the architecture, there must be consistent (see step 5a).

Install these architectures

At this stage of the tutorial, Basic functionalities and Simulink functionalities for Modules, Assemblies and Architectures have been explained :

Next step 6 deals with the community funcionalities.

Published with MATLAB® R2013a