[aadl]: Connection between features within a component

[Julien Delange]

Hi Jerome,

First of all, sorry if the e-mail was missing some context information. But you understand correctly, the goal: connect incoming features to outgoing features. From my perspective, this is already provided by flow and I do not see why we would like to allow this. But as for many features, you do not see the need until you have an appropriate example, that is why I was wondering if somebody has one.

It seems that the standard has no explicit rule about such construct - clarifying this aspect might be useful.

Julien.



From: Jérôme Hugues [mailto:Jerome.HUGUES at isae.fr]
Sent: Thursday, April 09, 2015 4:55 PM
To: Julien Delange
Cc: sae-aadl-users at lists.sei.cmu.edu; AADL Modeling (aadl-modeling at lists.sei.cmu.edu)
Subject: Re: [aadl]: Connection between features within a component


Le 9 avr. 2015 à 22:30, Julien Delange <jdelange at sei.cmu.edu<mailto:jdelange at sei.cmu.edu>> a écrit :


I would like to ask you about how to interpret connections within the same component. If we have one component with one input port and one output port, do you think it would be possible to connect the input port directly to the output ports?
As of today, inputs ports are connected with subcomponents. I would like to know if from your perspective, connecting input ports to output ports within the same component is a legal construct or should raise an error.

It took me a while to understand, by lack of a schematic: output to input, I can make a sense, e.g. for control/command

for input to output, do you mean

system foo
features
 I : in event port;
 O : out event port;
end foo;

system implementation foo.bar
connections
 port : I -> O;
end foo.bar; ?

(model not tested), just the impression of your email

imho, this looks like a way to represent flows the cheap way: it captures one set of port dependences at the component level.
>From that, Ocarina has (or had, I think I disabled it) a mode to generate all possible flows from port connections of a model instance, thus we could leverage such simple patterns in case of complex systems without the need of enumerating all possible flows. This could have some interest for early design explorations

But I agree, this is a particular use case


-
Jerome HUGUES
Enseignant-Chercheur/Associate Professor
Ingénierie des Systèmes Embarqués/Embedded Systems Engineering

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr<http://www.isae-supaero.fr/>
Tel (+33) 5 61 33 91 84 - Fax (+33) 5 61 33 83 30
Plan d'accès/Access map<http://plan.univ-toulouse.fr/#783>

-------------- next part --------------
HTML attachment scrubbed and removed