[aadl]: [aadl-modeling]: Connection between features within a component

[Peter Feiler]

Jerome,

For modeling a flow through a component without subcomponents we support flow implementations to go from input to output.
Given the description of what a connection is in the standard (information flow from one component to another component - or mapping the ports up/down the hierarchy), it does not make sense to have a connection from input to output.

Peter

From: aadl-modeling-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu [mailto:aadl-modeling-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu] On Behalf Of Jérôme Hugues
Sent: Thursday, April 09, 2015 4:55 PM
To: Julien Delange
Cc: AADL Modeling (aadl-modeling at lists.sei.cmu.edu); sae-aadl-users at lists.sei.cmu.edu
Subject: Re: [aadl-modeling]: [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