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

[Mike Whalen]

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=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 --------------
HTML attachment scrubbed and removed