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

[Peter Feiler]

Mike,

 

allowable processor features are defined with the processor component. When we defined them we had in mind the interface between the SW running on a processor and the processor, where processor could be the basic HW or the HW including an OS. In the latter case it would be the API to the processor, e.g., a collection of functions that can be called (provides subprogram (group) access) or ports to communicate through. These ports could include event ports, e.g., IRQs triggered by the HW.

These features are defined with the processor type (or virtual processor type).

When declaring a thread we wanted to be able to indicate that the thread interacts with the processor it is bound to, thus, the ability to connect to them or to call them in a call sequence. Since we did not know the specific processor we had the keyword processor as part of the reference specification in the call or connection end.

With the processor features section in a thread we allow you to explicitly declare which features in a processor you make use of before referencing them in the call or connection. Those declarations act as proxies to the features in the processor type of the processor the thread will be bound to.

 

Peter

 

From: Mike Whalen [mailto:mike.whalen at gmail.com] 
Sent: Monday, February 17, 2014 4:01 PM
To: Peter Feiler
Cc: AADL Modeling; sae-aadl-users at lists.sei.cmu.edu
Subject: Re: [aadl]: [aadl-modeling]: AADL meta-model changes

 

Peter,

 

  What kind of "processor features"?  Would these be things like IRQs?  If so, this might be very helpful to me.  Where would I find more documentation on this?

 

Mike




Michael Whalen
Program Director, UMSEC
200 Union St. 4-192
Minneapolis, MN 55455
Office: 612-624-5130
Cell: 651-442-8834

 

On Mon, Feb 17, 2014 at 9:43 AM, Peter Feiler <phf at sei.cmu.edu> wrote:

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 <mailto:aadl-modeling-bounces%2Bphf> =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 <mailto:sae-aadl-users-bounces%2Bugnenko> =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 --------------
HTML attachment scrubbed and removed
-------------- 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/2a9d9bb2/attachment.sig>