This step is also demoed with this video :

(ongoing...)

Step 6 : COMMUNITY functionalities

Previous steps dealt with Basic functionalities and Simulink functionalities for Modules, Assemblies and Architectures :

MecaTroniX manages modules, assemblies and architectures created by the user :

As amount of design is increasing, it might be necessary to add some designers and to work in community :

Modules and architectures defintions ease to determine the work area of each designer.

An architect can then allocate work area for each participating designer :

There also might be a role for a tester or a tuner who tests and/or tunes the system but not designs the system :

Of course, in very small orgnisation, one person can be architect, designer, tester and tuner all in one.

As soon as several people work on a system, it appears the need to clearly define the state of the art of the team, this is to say,

to make a clear difference between what is validated and what is under development.

This is the aim of the two possible kinds of versions used so far :

• • vU : user versions, these versions are under development

  • v###d### with # an integer : capitalized versions, these versions are validated

A capitalized version is a version that has been declared validated by a relevant person : we call it performance keeper.

Once a version has been capitalized, it means that a new state of the art of this module has been defined, and is now the new start for further development of this module. This is the Capitalization process :

These capitalized versions must be then available for other contributors, via the Synchronization process :

The "State of the art" must be accessible by all the contributors, this is easily feasible by a simple remote storage capability via network. We call it a server :

User versions and capitalized versions are applied to modules, but also to assemblies and architectures.

Remark : this the choice of user(s) to use capitalize functionality. Especially when small, a team can work with only user versions vU.

Designers, architects, testers and tuners may also exchange their user versions, via a classical import/export functionnality :

These functionalities enable the co-working, and they are more precisely described in sub steps of step 6 :

• • 6a : Export modules

  • 6b : Import modules and delete imports files

  • 6c : Capitalization process

  • 6d : Synchronization process

  • 6e : Synchronization process with several servers

  • 6f : Sort functionality

  • 6g : Other effects of capitalization

Published with MATLAB® R2013a