Disposition: Resolved OMG Issue No: 11852
Title: AADL pre-declared property set representation with MARTE
Source:
THALES (M. Faugère, Madeleine.faugere@thalesgroup.com)
Summary:
The representation of AADL properties with UML Notes, does not provide the AADL capabilities of the Properties language. Annotations in notes are not formal, as users use a free-text zone without any constraints for the annotated elements, and syntax checking. Furthermore, most of the AADL Properties defined in the Predeclared Property Set annex (AADL spec.) are already existing in MARTE stereotype attributes. The more appropriate way is to use these attributes to model AADL properties. However, additional problems rise from this approach:
-
Not all the AADL properties exist in MARTE.
-
Some enumeration types existing in MARTE do not contain the options supported by AADL.
-
Stereotype attributes are not always annotated in the same model elements (according to the mapping MARTE-AADL at the conceptual level).
This aspect can be solved in at least two ways:
-
We add the required stereotype attributes in the MARTE spec.
-
New stereotypes are created in this annex only to support AADL.
While the first option could not be in the scope of MARTE (we cannot align MARTE to all other language in the domain!), the second one requires to follow a set of formal rules to create the new stereotypes (naming, extended UML metaclasses, etc.) A third option is to create stereotypes for all the AADL concepts, but inheriting from MARTE concepts. An optimal solution should be evaluated with regard to criteria such as: tool reusability, automation of model transformations, timelines, etc. The third option goes along with the question of having an explicit profile for AADL, with AADL stereotype (or at least AADL profile label for MARTE stereo types that are identical to AADL). Do we need to introduce a new stereotype just because we have to add some properties to a MARTE stereo type? AADL allows users to introduce new properties through property sets. In MARTE terminology, users can introduce new stereotypes that carry properties specific to an analysis framework. Those we need to be able to associate with the base concepts of describing an embedded architecture (what we call core language). What would be a good approach and guidance for doing so? In that sense there are two issues: 1) describe what mechanisms are available to allow users to extend the base modelling language of AADL/MARTE – in essence meta modelling capabilities). In AADL we have an explicit textual representation in addition to extending the meta model of AADL, while in MARTE it is solely done through meta modelling. 2) capture specific sets of standardized (and not yet standardized sets of properties).
Resolution:
According to the implicit MARTE modeling process where modeling and analysis features are modeled by distinct features in separate diagrams, most (80%) of the AADL pre declared properties found their equivalent in MARTE. The complementary part will be explicitly modeled by the end user using the “Nfp” concept. The following table presents the mapping between the AADL pre-declared property set and their equivalent in MARTE.
Revised Text:
To be added after the “Component and associated features representation” table concerning the Data component section 3.3.4.
AADL data component properties
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
Shared data aspect
|
MutualExclusionRe-source stereotype
|
swMutualExclusionResource stereotype
|
swMutualExclusionResource stereotype
|
Concurrency_Control_Pro-tocol: enumeration
|
NA
|
|
concurrentAccessProtocol stereotype attribute
|
|
Priority_Inheritance
|
|
|
“PIP” enumeration literal of “ConcurrentAccessProtocol-Kind” enumerate
|
|
Interrupt_Masking
|
|
|
New issue raised
|
|
Priority_Ceiling
|
|
|
“PCP” enumeration literal of “ConcurrentAccessProtocol-Kind” enumerate
|
|
Maximum_Priority
|
|
|
New issue raised
|
|
|
|
|
Data access via interface
|
Resource, ConcurrencyResource, ProcessingResource of GRM depending on the user’s precision requirements
|
Associated SRM equivalent concepts i.e. swConcurrencyResource, etc
|
To be added after the “Component and associated features representation” table concerning the Subprogram component section 3.3.5.
AADL subprogram component
AADL properties
|
Marte Design
|
|
Marte Analysis
|
|
Compute_execution_time: Time_range
|
NA
|
NA
|
“ExecTime: NFPDuration[*]” attribute on SaStep or SaCommStep stereotype
|
Compute_Deadline
|
|
|
“Deadline: NFPDuration[]” attribute on SaStep or SaCommStep stereotype
|
Queued_Processing_Protocol enumaration
|
|
|
“MessageQueuePolicyKind” attribute
|
|
FIFO
|
|
|
“FIFO” enumeration literal from “QueuePolicyKind” enumerate
|
|
Other
|
|
|
“Other” enumeration literal from “QueuePolicyKind” enumerate
|
To be added after the “Component and associated features representation” table concerning the Thread component section 3.3.2.
AADL Thread component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
Dispatch protocol: enumeration
|
NA
|
NA
|
Specified at the WorkloadEvent concept triggering the SaScenario
|
|
Periodic
|
|
|
“PeriodicPattern” enumeration literal selected for “Pattern” attribute for the WorkloadEvent stereotype
|
|
Sporadic
|
|
|
“SporadicPattern” enumeration literal selected for “Pattern” attribute for the WorkloadEvent stereotype.
|
|
Aperiodic
|
|
|
“AperiodicPattern” enumeration literal selected for “Pattern” attribute for the WorkloadEvent stereotype
|
|
Background
|
|
|
New issue raised
|
Period: Time
|
|
|
“Period” attribute from the “PeriodicPattern” attribute specified by the WorkloadEvent stereotype
|
Deadline: Time (inherited from period)
|
|
|
At this level, the same as “Period” attribute defined above
|
Compute_execution_time
|
|
|
Computed from the different “Steps” concepts supported by the thread; shall be defined in scenarios
|
Compute_deadline
|
|
|
Computed from the different “SaSteps” supported by the thread; shall be defined in scenarios
|
Initialize_execution_Time and Initialize_deadline
|
|
|
Specific “execTime” and “deadline” attributes from SaStep stereotype corresponding on mode switch operations defined in the SwPlatform model
|
Active_execution_time (specific for mode switch) and Active_deadline (specific for mode switch)
|
|
|
Specific “execTime” and “deadline” attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model
|
Deactive_execution_time (specific for mode switch) and Desactive_deadline (specific for mode switch)
|
|
|
Specific “execTime” and “deadline” attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model
|
Recover_execution_time (specific for mode fault handling) and Recover_deadline (specific for mode fault handling)
|
|
|
Specific “execTime” and “deadline” attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model
|
Finalize_execution_time and Finalize_deadline
|
|
|
Specific “execTime” and “deadline” attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model
|
Synchronized_component
|
|
|
Nfp stereotyped attribute defined by the end-user
|
Active_thread_handling_proto-col (specific to mode switch): ex abort, complete_one_flush_queue, complete_one_transfer_queue,complete_one_preserve_queue, complete_all
|
|
|
Nfp stereotyped attribute with associated end-user defined enumeration
|
To be added after the “Component and associated features representation” table concerning the Process component section 3.3.1.
AADL Process component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
Scheduling_protocol
|
NA
|
NA
|
Specified by the “schedPolicy” attribute of Scheduler stereotype
|
|
Ex: EDF, RMS, SporadicServer, SlackServer, ARINC653
|
|
|
Scheduler and SchedulableResource stereotypes modeling with associated scheduling policy kinds, and scheduling parameters.
|
load_time and load_deadline
|
|
|
Specific “execTime” and “deadline” attributes from SaStep stereotype corresponding to operations defined in the Swplatform model
|
Period and deadline are specified for inheritance
|
|
|
Period and deadlines are specified at the thread level on WorkloadEvent and SaSteps.
|
-----------------------------------------------------------------------------------------------------------
To be added after the “Component and associated features representation” table concerning the Processor component section 3.4.1.
AADL Processor component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Anaysis
|
|
Thread_limit
|
|
AssociationEnd cardinality between ” Scheduler” and “swSchedulingResources” concepts modelized in the sw Platform
|
|
Assign_time: Time
|
|
|
Nfp stereotyped attribute defined by the end-user
|
Assign_byte_Time: Time
|
|
|
Nfp stereotyped attribute defined by the end-user
|
Assign_fixed_Time: Time
|
|
|
Nfp stereotyped attribute defined by the end-user
|
Clock_Jitter
|
|
|
Nfp stereotyped attribute defined by the end-user
|
Clock_period
|
|
|
Nfp stereotyped attribute defined by the end-user
|
Clock_Period_Range
|
|
|
“Op_frequencies” attribute from HwProcessor stereotype
|
-----------------------------------------------------------------------------------------------------------
To be added after the “Component and associated features representation” table concerning the Memory component section 3.4.2.
AADL Memory component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
MemoryProtocol (R,W,RW)
|
|
“MemoryBroker” concept allocated on “HwMemory”
|
“AccessPolicy” attribute from “MemoryBroker” stereotype
|
Read_Time:Time[]
|
|
|
“ExecTime: NFPDuration[*]” attribute on SaStep or SaCommStep stereotype
|
Write_Time:Time[]
|
|
|
“ExecTime: NFPDuration[*]” attribute on SaStep or SaCommStep stereotype
|
-----------------------------------------------------------------------------------------------------------
To be added after the “Component and associated features representation” table concerning the Bus component section 3.4.3.
AADL Bus component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
Propagation_delay
|
|
|
Nfp stereotyped attribute defined by the end-user
|
Transmission_Time
|
|
|
“ExecTime: NFPDuration[*]” attribute on SaStep or SaCommStep stereotype
|
Allowed_Message_Size
|
|
|
“MessageSizeElements” attribute on MessageComResource stereotype
|
-----------------------------------------------------------------------------------------------------------
To be added after the “Component and associated features representation” table concerning the Port component section 3.6.1.
AADL Port component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
Compute_execution_time
|
|
|
Time and Deadline are either specified in the associated communication media or component
|
Compute_Deadline
|
|
|
Queue_size
|
|
|
“MessageQueueCapacityElements” attribute on MessageComResource stereotype
|
Queue_Processing_proto-col
|
|
|
“Mechanism” attribute on MessageComResource stereotype available values are “MessageQueue, Pipe, BlackBoard, undef, other)
|
Overflow_handling_proto-col
|
|
|
Nfp stereotyped attribute defined by the end-user, typed bt end-user defined enumeration
|
Dequeued_protocol
|
|
|
Nfp stereotyped attribute defined by the end-user, typed bt end-user defined enumeration
|
To be added after the “Component and associated features representation” table concerning the Flow component section 3.8.
AADL Flow component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
Latency
|
|
|
See end-to-end flow latency
|
Throughput
|
|
|
See end-to-end flow throughput
|
To be added after the “Component and associated features representation” table concerning the Flow component section 3.8.
AADL End_to_end Flow component
AADL properties
|
Marte Design
|
Marte SW/HW platform
|
Marte Analysis
|
|
Expected_Latency
|
|
|
“End2EndD: NFPDuration[*]” attribute on SaEnd2EndFlow stereotype with qualifier attribute “SourceKind” set to “req”
|
Actual_Latency
|
|
|
“End2EndT: NFPDuration[*] “attribute on “SaEnd2EndFlow” with qualifier attribute “SourceKind” set to “est”
|
Expected_Throughput
|
|
|
“Throughput: NFP_Frequency[*]” attribute on “Sa/GaScenario” with qualifier attribute “Sourcekind” set to “req”
|
Actual_Throughput
|
|
|
“Throughput: NFP_Frequency[*]” attribute on “Sa/GaScenario” with qualifier attribute “Sourcekind” set to “est”
|
Disposition: Resolved
Dostları ilə paylaş: |