[aadl]: [aadl-modeling]: AADL meta-model changes

[Peter Feiler]

Hi Alexandr,

2.1 internal features. They can only be declared inside component implementations. You can then reference them in mode transition declarations that you add to the implementation.
Modes can be declared in the type. You can then add mode transitions to the type that are caused by external interaction, e.g., an incoming port. 
In the component implementation you then add transitions that are triggered by the implementation, either an internal feature or a subcomponent feature.

1.1 Processor features: When a thread interacts with the processor it is bound to we want to declare this with connection declarations to the features of the processor.
We have done that by adding the keyword processor to the connection end of a connection declaration. The connection end labeled this way implicitly provides a proxy for the feature of the processor the thread will be bound to.
Everywhere else in AADL we have explicit declarations of model elements, thus, we proposed to do the same for internal features and processor features.
In the case of the processor features they act as proxies for the features of the processor instance the thread is bound to.

We do have a consistency rule (C2) that requires the named feature to match one of the features of the processor being bound to.
We will update and refine this rule.
If the user declares an AllowedProcessorBindingClass we can make sure the proxy processor features are consistent with those of the expected classifier. 
Interesting thought to have a mapping specification between the proxy features and those of an actual processor if name matching is not sufficient.

Peter


-----Original Message-----
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 Alexandr Ugnenko
Sent: Monday, February 17, 2014 6:57 AM
To: sae-aadl-users at lists.sei.cmu.edu; 'AADL Modeling'
Subject: Re: [aadl-modeling]: AADL meta-model changes

Hi Julien,


There are several questions about updates:

1.1 If I understand the essence of 'processor features' - the ability to use these features within a component declaration (for example, in the declarations of connections). Then this can be achieved with the use of existing kinds of features: ports and subprogram access. Why introduce a new kind of declarations? Only to highlight the features, which should only connect to the features of the processor?

1.2 Maybe the presence of declarations of 'processor features' implies implicit connections when threads are bound to processor? That is, if you bound thread 'T.i' to processor, it is assumed that the 'processor features'
with identifiers 'e' and 'ed' connected to corresponding features, declared in the processor declaration. From this it follows that the 'processor features' identifiers must match the features identifiers in the processor declaration. Which in turn limits the threads bindings (we can't bound thread to processor with same set of features but with different identifiers). Maybe it makes sense to introduce rules of mappings between 'processor features' and features declared in the processor.

2.1 'Internal features' are used to describe the features, which are a source of internal events that are not available outside of the component.
Is that correct? And they can be used as references in the mode transitions declarations. AADLv2 specification allows the declaration of modes and mode transitions in the component type declaration. Why 'internal features' can be declared only in the component implementation declaration. Or am I mistaken and they can be declared in component type declaration?

2.2 If 'internal features' can be declared in the component type, it turns out, that the component type partially describes the internal structure of the component. Then the question arises - why specification provides two kinds of component declarations: 1 - the component type declaration that can partially describe the internal structure of the component; 2 - component implementation, which also can partially describe the internal structure and can fully describe the internal structure. Maybe we should use one kind of component declarations - declarations of the component implementation. To do this, it will be enough to allow to declare features in the component implementation.

Best Regards,
Alexander Ugnenko.
Software Engineering Department, ISPRAS



-----Original Message-----
From: sae-aadl-users-bounces+ugnenko=ispras.ru at lists.sei.cmu.edu
[mailto:sae-aadl-users-bounces+ugnenko=ispras.ru at lists.sei.cmu.edu] On Behalf Of Julien Delange
Sent: Wednesday, February 12, 2014 11:17 PM
To: sae-aadl-users at lists.sei.cmu.edu; AADL Modeling
(aadl-modeling at lists.sei.cmu.edu)
Subject: [aadl]: AADL meta-model changes

Dear AADL users,

According to the last changes and revisions in the AADL standard, the meta-model has been updated. Changes have been applied and propagated in the develop branch of OSATE and will be included in the next stable version that will be released in April. Please note that these changes might impact tools and plugins built on top of OSATE.

For that reason, it might be useful that all developers check that their tool is compliant with the new meta-model in order to make sure it will work with the next stable release. You can review the changes made on the meta-model here:
https://wiki.sei.cmu.edu/aadl/index.php/Metamodel_updates#Internal_Features_
and_Processor_Features

Best regards.


 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 9418 (20140213) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru/.ml
 
 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 9432 (20140217) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru/.ml
 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <http://lists.sei.cmu.edu/pipermail/sae-aadl-users/attachments/20140217/e72cd0dd/attachment.sig>