AADL Meeting Toulouse
1. AADL Parser – Middle of Feb. for experimentation
2. Name AADL V2 rather than AADL2
3. Action: Contained Property and Prototype use together at the same level. Also a shortcut for properties? JM, Peter will look at.
4. Generic Port Category ? Will talk about later. (prototype ports?)
5. Informal ballot between this meeting and the next one. Target fall release of standard.
6. Virtual buses would not always be bound to a bus (different than virtual processors).
Like a connector. Protocols for communication even on the same processor.
Provides and requires virtual bus access?
What about when the software processing the protocol is different on each side? Would have to do through connection and components on each side.
7.
Do we have too many connection patterns for Arrays? Implementation issue.
OS. Problem may be when we have multiple dimensions (many things to connect).
8.
Action: Can a connection that goes between two processes, for example, with arrays of threads within each, have binding for a specific connection to a bus within the connection between the processes? Peter will look into it.
9.
Action: More discussion should be in the standard for Matching classifiers on
Connection. OS. Peter will look at.
10.
Q. OS At the high level, do we want to be able to say they will match – make it an incomplete model. Compiler will give you a working when typed and untyped are connected.
11.
Decision - With clause – will be enforced – no with clause then no access.
12.
JM
– should property sets also have this restrictions. This is another dimension.
We could consider. Property sets have unique names. Think about more.
13.
BL
– do we need nesting of property sets for system integrators?
14.
Action: TV – can we restrict a property to apply to only the port of a process (it’s a protocol that only should be on the port of a process). Peter will think about it.
PG: General agreement that this would be good for checking but may only be rarely used. We need not get too fine tuned with options.
15.
Contained properties in the type ? – only to enable moving the feature properties to the properties section. May want to remove.
16.
Property Value can be removed. Rare conflict that can be resolved by providing full property set name.
17.
Predefined property sets – we can break into more sets yet also not require the full qualifier. This may be the best approach rather than lists. Then order Alpha within the set.
18.
Action: JM: Peter. Put the constant property back in? Its needed to insure that someone does not override your property value. Peter and John will talk more about since constant was difficult to implement and not being used. There may be another approach.
19.
Action: Should we have conditional dispatching, conditional moding property?
Dispatch when all inputs are new? Guards of error model annex would be an

example. Perhaps a separate annex. Oleg is willing to work with Jeff, then with
Peter. As a small annex or part of the behavior annex. Oleg will lead.
20.
Elements of a port group without going down the hierarchy ?
PG
21.
All the text may not be in place in 1.6 for flows.
22.
We need to consider more about sync scopes – Reference-Time. Then would effect scope of modes. Hyperperiod would be over the sync area. Should it be both in the logical and physical domain? First thoughts are that it should.
23.
Need to update modes for multiple clocks.
Document:
1. Properties – can not have – packages, properties themselves, property sets
- properties will be applies to package then for all classifiers.
Want to apply to package and to all elements in a package. Peter will work on way to do it.
2.
Modes – if named in the type then all must be in the time, not the implementation.
Keep it simple. Can you refine the modes, yes by adding modes,
3.
Prototype matching rules. Uniformity is best. Leave default as is.
4.
Type extension matching rule should continue as rule against type.
5.
Need to describe the protocol through behavior annex rather than having a virtual bus to describe.
6.
Property dependency – a periodic thread must eventually have the period defined.
Calls for some type of constraint language. What do we need to make a specification complete. Future annex needed for constrain management.
Currently we check in the compiler for these constraints, will probably specify the constraints in the process.
7.
Derived property and annex for constraints. John will review the MARTE approach and Jerome will present the annex that ASSERT used. This annex exists. Explore derived property or other properties that would support the use of an annex. Jerome will post paper.
8.
Peter will create a group for discussing the Behavior Annex. Pierre D will develop the document to be balloted. He will have it out two weeks before the meeting so it can be discussed at the April meeting.
9.
Cheddar is working with the Behavior Annex to also incorporate taking info from the behavior description – for internal specification of data driven, timing can be in provided in the AADL.
10.
Peter will integrate into the permissions the additional sync mechanisms for subprograms (threads also).
11.
Jerome’s presentation – Code Generation Annex
12.
Peter – will put Data_Type: enumeration in the language, may have been lost.
See Jerome’s presentation.
13.
Peter – will look into cleaning up, Jerome will express them in Ada and C.
14.
Natural or Positive – some have and some do not – permission to not support all of them.
15.
Action: Jerome will provide the ASSERT property set for review by Peter.
16.
String literal to express what character set is being used

17.
Maximum size for a string, define to be static?
18.
How will we handle errors in a standard way.
19.
Action: Jerome – will be responsible for A5 data modeling in the standard.
20.
Conflicting names – need to be resolved.
21.
Bag, set, stream – some languages will not support, they are not required to implement but what about portability?
22.
Jerome and Mamoun will discuss mask for what parameters are frozen at dispatch. PortMask discussion.
23.
Action: Peter will provide paper on Buffer optimization to Mamoun and Pierre for use in the programming annex. For formal proof, for validation of generation.
Send to everyone on the mailing list.
24.
DO178C may be interested in these optimizations and validations, proofs.
25.
AADL code generator from MARTE will be provided – Madelaine will provide with also the text for annex.
26.
Peter has already added text in the AADL standard to explain logical threads vs the services processors provide, physical threads.
27.
Seville a.
Jeff – logic specifications – 1 hr b.
Jerome – Programming annex and data modeling– 3 hr c.
Madelaine – UML AADL profile – 2 hr d.
Pierre/Mamoun – Behavior Annex – 2 hr e.
Who to invite to User day – 8 hr f.
Informal Ballot review 10 hrs g.
WWT in the demo day.
28.
Decision : Do we need a property constant for prototypes when using arrays as an argument? Yes - prototypes should only be classifiers, not arrays. Array size can be a number, left out or a property constaint.
29.
Decision - Get rid of the anonymous name space, tell Pierre/SPICES
30.
Action: Thomas – will check on the division of properties in MARTE vs his recommendations
31.
Data modeling –
32.
Moving properties into an annex? Not yet. But having a separate document may be helpful because you always need to refer to the list of properties to select them.
Hypertext would be helpful. Its in the OSATE toolset but the hypertext does not work, the links get thrown out.
33.
Data modeling – should we add class. Thomas may provide. Data modeling will be a separate annex.
34.
Property required – should also be enabled for the port.
35.
Action: Use scenario – ports may have different protocol stacks, they reference lower than the top or at the top or …. Peter will work with John Mettenburg..
36.
UML 2 profile is dead (but we may need to add to the MARTE profile).
SPICES –
Issues:

a. Knowledge of AADL across the partners very important, is a major issue in working together and making progress. Yet many were not familiar so takes time to come up. b. Specification of the models, engineers are not used to modeling, but building instead, change of approach. c. Each has his own tool approach, working together across tools requires pulling together.
Coordination:
Would like to coordinate with joint mailings with the AADL.
Possible later joint meeting.
SPICES finishes at end of 2009
IP belongs to the companies but some will put them in the public domain in OPEES.
SPICES presentations will be added to our presentations. Made available to both.
Nice slide on tool integrations.
SAM – functional architecture capture before AADL, transformation into the ADL with
ATL. Flows, no architectural perspective yet. They do describe modes, ideas of port groups. Goes to database.
AIRBUS project related to the Air Traffic Control on the 380, experimenting
SYSML not hierarchical, also too complex so used SAM, from SADT.
Thales Radio – emphasis on getting the application the best way on the target with many types of processors.
Tools – industrial code generation and documentation objectives. Pierre Gaufillet.
Draft Document. Are the properties complete for our generation requirements ?
Pierre - time to discuss properties for code generation at the next meetings. Container properties. Relates to Hood. Inside the container and with behavior annex. To C and to
ASM. Linking to ARINC653.
Studies on ARINC 653 and POSIX platforms.
How do we know that the products are properly integrated. We will use flows and tests to the flows since they talk about the system. Also the behavior annex can give expected behavior.
AADL to SystemC generation – expected in March, involves creating the thread in software or hardware and dealing with the system analysis.
Execution platforms.- some questions:
AADL profile – not a UML profile, perhaps a subset of the AADL or patterns.
MDA – platform independent, with platform, from the platform up.
ADELE –
This will be the graphical editor available

Will be tracked on the Adele web page for problems.
Will be merged when the tool is delivered into the Topcased tracker.
Stable version to be provided in TOPCASED version 2, July 2008.
AADL source code will be exchanged from Adele and OSATE
TOPCASED released every 6 weeks. Starting point on version 2 is July.
Minor releases will not have major changes. The AADL meta model is not intrusive.
Look and feel is similar to current editor
Graphical id’s are not the same as source text lines so going back and forth the graphical identifier may change.
You need to carry information to go round trip. Could be in the XML.
Connection – code is cleanly re-imported.
Auto generation of AADL source so you can quickly evaluate.
AADL website should mention the creation of Adele and that it will be released with version 2 and with the new version of TOPCASED.
AAXL may also be the approach to exchange and then they invoke the source.
Traceability will be important so the AAXL will be important for tracing errors.
Develop a document. Between March 1-13 th
. Set-up a teleconference to discuss. Need a list of ideas. Pierre G. will propose.
CCM – Thomas – Common Object Request Broker Architecture (CORBA) 2
CCM: CORBA3 runs on CORBA 2 ORBS
Is a set of three notitions
IDL3 interface description language
CIF – is the API
D&C – deployment and configuration
How to connect to the AADL?
Mappings between modeling languages and programming language (implantation language)
You will implement the AADL interfaces in CCM
Run an AADL application on top of a CORBA
This would give a rapid prototype but not analyzable given its dynamics
CCM is from the enterprise world, they do not care about timing. Yet with restrictions it can be used. We just want to have the API, not actually use the CORBA ORB. We would get rid of CORBA. We use the CCM just for its familiar descriptive approach for interfaces. Brings in CORBA data types.
ARINC 653 –
POSIX mapping of MetaH – Peter and I can look at the papers for POSIX integration
Window slot property – on a virtual processor, it is the key, a windows slot..
Time slots are at the processor level. Allowed binding for virtual processor properties.
Property set for 653.
Ask Steve Hickman for his report.

Offset property for relative to partition. Do we have? Do we need.
Partition – guaranteed time vs general operating system thread which can be pre-empted.
&&&&&&&&&&&&&&&&&&
From Oleg:
AR: Ana Rugina
PD: Pierre Dissaux
BL: Bruce Lewis
PF: Peter Feiler
JH: Jerome Hugues
JM: John Mettenberg
PG: Pierre Gaufillet
TV: Thomas Vergnaud
BL: Brian Larson (by telecon)
JF: Jean-Francois Rolland
MF: Mamoun Filali
JT: Jean-Francois Tilman
BZ: Bechir Zalila
VS: Vincent Seignole tuesday, 2/5
============
BL describes current status of as well as related activities
------------------------------------------------------------
Planning future meeting. Need to arrange meeting space and look for potential sponsors. San Diego is a possible place for the next Winter meeting. PD proposes Brest as a possible location. Joint meetings are a priority.
Possible joint meetings are ESC Boston, OpenGroup
Target time frame for ballots on V2 is Spring 2008.
PF presents overview of changes in AADL V2
------------------------------------------
Do we call it AADL V2 or AADL2? AADL V2 is preferred.
JM: prototypes are shorthand for refinements. we should consider a similar facility for properties.

TV: a virtual bus does not have to be bound to a bus
PF: that's correct: two threads on the same processor can use a protocol to communicate.
TV: so a virtual bus is really a connector.
PG: what about properties?
PF: property attached to an array applies to all elements. Contained property associations can apply to different element.
Programmable pattern language can be made into a language annex, but not yet.
Is All_Neighbors a useful pattern? Up for discussion.
JH: what about graphical support for patterns?
PF: it is possible in the front end, and will be passed to the model and connection set.
JH: in the instance model, some name mangling will have to be done
PF: indeed, and details need to be discussed.
JM: does ordering of port inputs determine ordering of port outputs?
PF: rules for determining semantic connections are the same as were in V1. So individual ports do merging. Port groups remember who belongs to who.
JM: example I have is a multichannel receiver. Software is literally parameterized, it is not statically determined (for power management). And number of ports need to scale.
PF: You are really talking about modes, then.
Issue: we do not allow signature matching on refinements, but allow for prototypes. Not everyone agrees.
Issue: Scoping of the rules? Does it apply to the model as a whole, or to individual connections.
Issue: how much explanation of classifier matching should be in the standard.
JM: conversion appears the same as equivalence, or even subset.

PF: Equivalence, subset, and conversion indicate different types of matching.
Issue: currently, with enables referencing into other packages. Do we need a default? Tools can help construct with clauses, so it need not be a burden on the modeler.
Recommendation: use with clause to list packages that can be referenced
JM: do you have to explicitly reference property sets too? We are dividing our domains into property sets; it may be a good idea to list property sets that are known to the model.
PF: no, only classifiers currently. May be usefule, need to think about it.
Suggestion: think about property set referencing, do we need to restrict it sometimes?
BL: what about system integrator?
PF: properties have a single name space, currently. This can be changed.
Issue: renames clause is also just for classifiers. Do we want to extend it to properties?
Property sets need to be independent of any moment, to classifier names canont be used in apply to clauses.
TV: Is it useful to specify that a property can apply only to a subcomponent of a particular component type? (E.g. ports that are part of a thread).
PF: It remains on the table, but we are not including into the current version. Enforcing such constraints may be a tool issue.
TV: But you still need syntax to express it.
Issue: Do we want to move parts of the core standard (e.g., data modeling) moved to some standard annex? It is to reduce the size of the document.
Issue: we talked about organizing pre-declared properties into subgroups by using separate property sets. But the idea for pre-declared properties is not to specify property sets. But pre-declared properties will be unique, and we can allow to omit property set name.
JM: we may want to restrict changes to properties in ancestors. Useful in component-based design, if you do analysis of components separately.

PF: it may be a tool issue. We used to have it and removed: it was not used and a hassle to implement. It is similar to TV's suggestion and has to do with visibility.
Issue: timeout as a fault condition vs. timeout as event.
DS: what about other triggering conditions (not timeout-related)
PF: what we really want is conditional dispatches (and also for mode transitions). Also error model annex has guard rules. We can have an annex for conditional statements. But not in the core language.
OS and JF volunteered to drive conditional annex: remove guard transitions from error modeling annex and merge with conditionals in behavior annex to form a new annex.
JM: I am concerned about mixing physical and software features together.
Discussion clarified JM's concern.
Issue: We need to refine how user specifies synchronization scopes.
JT: we need to consder mode transitions in asynchronous systems.
Detailed discussion of AADL V2 draft
Issue: do we need properties for packages?
JM: we attach to packages (now in comments)
PF: possible solution, a property section in the package. Applies to the package only, not to classifiers inside the package. Package properties are not carried into instance models, which do not have packages. We can have a rule that, if a property is inherited, it is ultimately taken from the package.
BZ: we can modify property declaration; if its owner is the package, it applied to package itself. Otherwise, it applies to the classifiers in the package.
PF: let us capture the requirements we have for properties in packages, and make sure we have a consistent solution later. For applying properties to package contents is applies to clause or inheritance rules.
For certain pieces of informations, you can declare them property constants, and you declare them in property sets, not attach to anything. That can be used to specify infomration that applies to the whole workspace.

Issue: treatment of modes in types
Suggestion: Can have mode automata in type or in implementaiton, but not both. You can have transitions in type, if they depend on events in the interface.
MF: can we refine mode automaton?
PF: you can refine mode automaton by adding modes and transitions, but not changing existing modes. But let us not consider this for V2.
Issue: is Match the best default choice for prototypes. It will be the least used one, but for uniformity with other classifiers we may keep it as default.
Recommednation: since we do not know how often the other two will be used, uniformity is a good option.
Issue: do we allow type extension for prototypes or implementation extension also?
PG: replacing implementaitons may be dangerous, you can violate properties
PF: you can violate properties with type extension, too. But at least, with type extension, all implementations will implement the same type.
Recommendation: stick with type extension.
Issue: do we need to represent concurrency protocols as objects so that we can set properties on them? That's instead of having Required_Protocols property, where protocols are introduced by name.
JH: looks like an overkill on the modeling level. And what if two virtual buses use the same piece of data but specify different concurrency control protocols.
PF: maybe protocol reference should be part of the provides access port.
Recommendation: do not pursue virtual buses for concurrency protocols for V2.
The user can still use AADL to define meaning of the concurrecy protocol, but not as part of defining the model. (?!)
Issue: meaning of properties in the context of other properties.
JM: constraints can achieve the desired result
OS: we should not leave this completely to the user. For standard properties, it relates to the notion of a complete model. E.g. if we use "periodic" as

dispatch policy, then the model is not complete until the period property is specified.
Suggestion: we will have rules as text
Recommendation: constraint language is not for V2.
Issue: the use of self on the right-hand side of a connection.
Recommendation: remove for now, since there is no known case where it is needed.
Issue: It is possible to connect an outport with an inout port. But it is not possible within a port group. Do we need to change port group matching rule: allow as long as individual connection is allowed?
Recommendation: Adjust the matching rule.
Issue: add limited property manipulation operations: sums of children and concatenation of lists, rather than full arithmetic.
Issue: derived properties. AADL has made a decision to have properties as values.
OS: do we need an annex for capturing derived property-like values.
JM: look up MARTE for property definition, they have derived properties
JH: we already have annex for Ocarina for scripts for calculating
Recommendation: Leave the core language as it is and consider a standard annex for dealing with derived properties. Study the MARTE approach and consider
Jerome's annex as a possible prototype for the standard annex.
JH presents verification annex
------------------------------
PF: how is it different from OCL?
JH: it is not different conceptually, but more closely tied to AADL.
BL: post the proposal on the wiki and collect comments
Suggestion: for now, we will try to provide the concept of "derived" as means to hook up a constraint engine of choice. PF and JM to look at MARTE properties to see whether anything else needs to be introduced. The goal is to keep contraints or value calculations out of the core language.

PD and TV lead the discussion on extensions to graphical syntax for V2
----------------------------------------------------------------------
Proposal by TV is a clean slate. New symbols may be used as icons in a UML tool, but for a graphical environment we should have continuity with V1 graphical notation.
JH: users are interested in different notation for different kinds of connections. In a busy diagram, you may not see endpoints, but you see connections.
Wednesday, 2/6
==============
PD presents behavior annex
--------------------------
BL: could behavioral annex describe mode switch behavior?
MF: we do not redefine the basic execution model of AADL
All examples of annex use are to be put into a separate document.
Issue: we have not decided an the need for hierarchical states.
MF: we have a case study, where behavior has two levels that should not be mixed. It can be of course expressed in a flat state machine, but we lose the separation between two parts.
PG: we can handle it through views into the the flat state machine
MF: but this is just graphical syntax for hierarchical states
PD: maybe we can solve this problem by handling hierarchy on the AADL level
No resolution yet.
Issue: behavior annex for system components? May be useful on high level.
Similarly for devices.
Maybe the solution is to attach subprograms to these components and add behavior there.
JF: do we need distinction between specified behavior in the type and actual behavior in the implementation?

Issue: consistency with error annex
Need to review beh annex text
Issue: consistency with core AADL
MF: we captured all aspects of AADL V1, but timing specification in V2 has not been included yet.
Issue: maybe call protocols can address the issues with asynchronous execution in V2.
PF: we can extend the core standard to be able to express that calls can be asynchronous or semisynchronous. This will allow us to match call semantics specified in behavioral annex.
Action items: restructure the document to separate definition of the automata from action language.
BL: can we have the draft ready for informal ballot before the April meeting?
PD: we can have it as target to send the document to the committee to review before the meeting, by mid-March.
JH presents code generation annex
---------------------------------
Annexes A.4, A.5, and A.6 affect generation.
Issue: how to map base types onto native types. You have to interpret the name to know that an integer is an integer.
Proposal: add property Data_Type.
Suggestion: link floating points to IEEE 754 whenever possible
Question: do we need to generate code that enforces type such as Natural,
Positive, etc. if the target language does not support them.
Need to have property of processor that captures maximum integer size on the target machine (maybe Word_Size can be used). Max_AadlInteger cannot be used for this purpose, since it is intended to represent maximum value of a property.
Issue: exceptions on AADL level? Maybe link with fault conditions.
PF: it is a more general issue. The standard provides possibility for runtimes to propagate faults to the AADL level, but does not specify a mechanism for

doing this.
Issue: notion of time. Need to know what clock to reference. Has bearing on the asynchronous semantics.
Action item: JH will clean up A.5.
Issue: A.4 defines data structures, but not API for the data structures such as container.
Issue: if initial value is a list, and the data structure is a constant, what is the right value to use for initialization.
Clarification: Intent for the initial list is intended for initializing records. For simple data types it should be illegal.
Peter has a paper on memory management for buffers and port variables. It provides a framework for validation of code generation. PF to broadcast the paper to the committee. PF and MF are to look into formal verification of the approach. Explanations should be in the code generation annex.
Long discussion of optimization and certification follows.
Conclusions: we do not need to change the core language. Code generation annex and related annexes needs to be clarified and cleaned up. Then we can start building the case for certification and optimization.
Madeleine Faugere presents MARTE profile
----------------------------------------
Issue: what option do we use to represent operating system threads/processes.
We may use AADL threads, and it seems the only option for V1. For V2, virtual processor seems a better option.
MARTE will reevaluate the mapping w.r.t. V2. Maybe both choices can be listed as options.
Issue: guidelines do not address instance model. Need to see what instantiation means in MARTE/UML context. Off-line discussion between PF and
Madeleine will take place.
Issue: Need to identify aspects of AADL that will require extensions to MARTE.
PF continues with V2 issues
---------------------------
Issue: cannot parameterize just the size of an array.

JM: you should know whether you have a scalable component or not, even if the component is a prototype. Supplying just the classifier in prototype instantiation simplifies the language.
Recommendation: Accept JM's suggestion. Array type is declared in the subcomponent, not passed via prototype. Keep property constant in array specification, as opposed to property.
Issue: anonymous namespace is meant to be local workspace, not visible from other packages.
Proposal: remove anonymous namespace to simplify things.
Recommendation: accept.
Issue: groups for predeclared properties
Suggestion: move data modeling annex into separate document
PF leads discussion on data modeling annex
------------------------------------------
Suggestion: object orientation for AADL.
Recommendation: reconsider when TV provides rationale
Planning for April meeting
--------------------------
List of people to invite for the user group session? Everyone send e-mail to
BL with suggestions.
10 hours for the core standard review, plus at least 2 hours for behavioral annex, plus at least 3 hours for code generation and data modeling annexes.
MARTE for 2 hours.
AADL is not planning to have a separate UML profile. The plan is to go along with the MARTE profile, with the possibility to extend the MARTE profile if the need be.
Thursday, 2/7
=============
SPICES Overview, Vincent Seignole
---------------------------------
AADL V2 Overview, PF
--------------------

JM: The fact that ADELE is a tool separate from OSATE is a problem. This means
OSATE will not have a graphical editor.
PG: ADELE can be tied to OSATE like Topcased was.
SPICES demonstrators, Vincent Seignole
--------------------------------------
PG: Air Traffic Control demonstrator involves transformation tools to reuse common information from a high-level spec model (SAM language) in the construction of the AADL model. Work is on the on-board component of the system. SAM is a simple language to handle functional decomposition. SysML can be used for this purpose, but it is too complex.
VS: Modeling proceeds top-down, even when a demonstrator involves an existing system.
JM: we do not have the luxury to start from scratch. Most engineers work on evolving existing product lines.
JM: when modeling platform aspects, question is what load do you assume?
PG: we do not get real numbers from system developers, so we assume an environment and then pass it to the system developers to see if it is acceptable to them.
PG: SPICES code generation approach
-----------------------------------
Schedule discussion of SPICES needs for code generation at the next meeting.
PG is connecting existing code generation pragmas to AADL properties.
Code generation is limited to containers and some aspects from behavior from the behavioral annex.
Another aspect is compatibility with various OS. There are some problems with
POSIX.
Integration testing is one of the missign parts. Current thinking is to work with AADL flows. What kind of information needs to be added to generate tests, will have to be explored. Beh annex can be used to capture the environment's reaction to components' outputs.
BL: SystemC mapping may appear as annex to the standard.
VS: we need to know what is relevant to standardization. Many things in the project are implementation details. Maybe component interfaces are relevant.
We are dealing with the system where blocks can be implemented in hardware or

software. We aim to generate glue code, but not allocation decisions.
BL: there will be a lot of interest to make this a part of AADL toolset.
For late hardware/software decisions, abstract components make good sense. It may also be a matter of applying different mapping.
POSIX and ARINC 653 are the primary platform mappings for SPICES. But not all of POSIX will be used.
Execution consideration
-----------------------
The MDA-oriented approach has little value to standardization, since platform-specific mappings may be considered a tool issue.
The DSL-oriented (platform-specific) approach may be interested for mapping of domain-specific notions to AADL.
In the bottom-up approach need to make sure that semantics of existing platforms are faithfully represented in AADL.
PF: People should not assume that an AADL thread will be a thread in an implementation. Virtual processor is a logical entity that needs to be executed on some (physical or virtual) processor and get scheduled.
JM: virtual processor is a terminology mismatch for many people, who will not connect it to an OS notion.
PF: We run into terminology mismatches all the time.
PF: You make decisions and assumptions for these decisions, and you want a record of that. Rate group optimization as mapping threads to virtual processors creates such records.
In platform independent/platform specific mapping, it depends on whether we go top down or bottom up: an OS thread may appear as a thread going bottom up but as a virtual processor for top down.