Issue 11852: MARTE-AADL Issue 5 (marte-ftf) Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com) Nature: Enhancement Severity: Significant 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: a) Not all the AADL properties exist in MARTE. b) Some enumeration types existing in MARTE do not contain the options supported by AADL. c) 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: 1) We add the required stereotype attributes in the MARTE spec. 2) 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 stereo type (or at least AADL profile label for MARTE stereo types that are identical to AADL). Do we need to introduce a new stereo type 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 stereo types 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" Actions taken: December 21, 2007: received issue February 17, 2010: closed issue Discussion: see ptc/2008-06-05 for revised text End of Annotations:===== m: webmaster@omg.org Date: 21 Dec 2007 04:57:21 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Madeleine Faugere, Huascar Espinoza, Peter Feiler Company: Thales TRT, CEA LIST, CMU SEI mailFrom: madeleine.faugere@thalesgroup.com Notification: Yes Specification: UML Profile for MARTE Section: Annex A: AADL-like models with MARTE FormalNumber: ptc/07-08-04 Version: Beta 1 RevisionDate: 21/12/07 Page: 345-382 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; InfoPath.1) Description [MARTE-AADL Issue 5] 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: a) Not all the AADL properties exist in MARTE. b) Some enumeration types existing in MARTE do not contain the options supported by AADL. c) 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: 1) We add the required stereotype attributes in the MARTE spec. 2) 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 stereo type (or at least AADL profile label for MARTE stereo types that are identical to AADL). Do we need to introduce a new stereo type 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 stereo types 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).