[aadl]: Modelling best practices

[dominique.blouin]

Hi Julien,

We have worked on a similar approach for modeling FPGA components with 
AADL. We use three layers of extension according to different genericity 
levels, using the AADL extend and refined to mechanisms. Basically, the 
first level is very generic and captures the fact that every FPGA may 
contain static (or built-in) components and a configurable component. 
The second level, defines the actual static components for a specific 
platform (e.g.: Xilinx Virtex ...). The third level captures the actual 
synthesized design of the configurable component.

More info is available here: 
http://www.hindawi.com/journals/ijrc/2011/425401/. Hope this helps,

D.

Le 31/10/2011 14:57, julien.delange at esa.int a écrit :
> Dear all,
>
> I am currently using AADL to capture a system architecture. It is composed
> of many heterogeneous components.Then, I am wondering about the best
> modelling patterns and I think this could interest different persons on
> this list. The thing is that for some components, there is only few
> variability but they share a lot of common properties/requirements.
> For example, imagine a monitoring system with camera and an audio
> recorder. These devices have some properties and constraints and are
> connected to a network using a 100M ethernet link. The vendor also has the
> SAME devices but with a wireless link.
>
> So, one approach would be to first model generic components like
>
> device generic_camera
> properties
>      ....
> end generic_camera;
>
> device generic_recorder
> properties
>      ....
> end generic_recorder;
>
> And then, create new device components that extend the generic one.
>
> device camera_eth extends generic_camera
> features
>     link : requires bus access ethernet_bus;
> end camera_eth;
>
> device camera_wifi extends generic_camera
> features
>     link : requires bus access wifi_bus;
> end camera_wifi;
>
> device recorder_eth extends generic_recorder
> features
>     link : requires bus access ethernet_bus;
> end recorder_eth;
>
> device recorder_wifi extends generic_camera
> features
>     link : requires bus access wifi_bus;
> end recorder_wifi;
>
>
> But on the other hand, it forces to redeclare the features access while it
> could be declared only in one generic component and then, be inherited.
>
> So, we could add
> device generic_eth
> features
>     link : requires bus access ethernet_bus
> end generic_eth;
>
> And then, if we have multiple inheritance, one would be able to write
> device camera_ethernet extends generic_camera, generic_eth
> end camera_ethernet;
>
> This would ensure that devices using the same network have the same
> properties each other. Otherwise, network-related properties and
> requirements must be duplicated, which could be error-prone. On the other
> hand, adding multiple inheritance would raise new issues.
>
> So, I'm wondering what are the best practices to model such components
> with few variability. I'm quite sure that some AADL users already face
> such issues and so, having a feedback about existing experience would be
> nice ! On the other hand, I hope this could be useful for other people and
> then, show some useful modelling patterns !
>
> Thanks for any comment/suggestion,

-- 
Dominique BLOUIN

Ingénieur de Recherche / Research Engineer

Université de Bretagne Sud
Lab-STICC / CNRS UMR 3192

Centre de Recherches
BP92116 / 56321 LORIENT Cedex
Tel:0297874616 / Fax:0297874527

http://www.labsticc.fr/