[aadl]: [aadl-modeling]: Connection between features withina component

[Pierre Dissaux]

you can also use the Behavior Annex to express the relationships between output and input ports of the same component:

subprogram add
features
  input1 : in parameter int;
  input2 : in parameter int;
  output : out parameter int;
annex behavior_specification {**
  states s : initial final state;
  transitions t : s -[]-> s { output := input1 + input2 };
**};
end add;

Pierre

From: Peter Feiler 
Sent: Thursday, April 09, 2015 11:18 PM
To: AADL Modeling ; Julien Delange 
Cc: sae-aadl-users at lists.sei.cmu.edu 
Subject: Re: [aadl]: [aadl-modeling]: Connection between features withina component

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> 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 

Tel (+33) 5 61 33 91 84 - Fax (+33) 5 61 33 83 30

Plan d'accès/Access map

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