UML Profile for MARTE Avatar
  1. OMG Specification

UML Profile for MARTE — Closed Issues

  • Acronym: MARTE
  • Issues Count: 386
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
MARTE13-3 Questions on observators within GQAM and SAM MARTE 1.0 MARTE 1.3 Resolved closed
MARTE13-11 Annotation of Criticalities of NFP constraints MARTE 1.1 MARTE 1.3 Resolved closed
MARTE13-39 The type of a composite aggregation Stereotype property cannot be a Stereotype MARTE 1.2b1 MARTE 1.3 Resolved closed
MARTE13-33 Carbon footprint modeling MARTE 1.2b1 MARTE 1.3 Resolved closed
MARTE13-16 Missing a property to PeriodicServerParameters MARTE 1.1 MARTE 1.3 Closed; No Change closed
MARTE13-7 Missing mappings between analysis duration, arrival patterns and clock constraints MARTE 1.0 MARTE 1.3 Closed; No Change closed
MARTE13-25 XMI files for MARTE 1.2 Profile and Library are not accessible without login MARTE 1.2 MARTE 1.3 Closed; No Change closed
MARTE13-10 Annotation of Criticalities of NFP values MARTE 1.1 MARTE 1.3 Resolved closed
MARTE13-14 MARTE issue: Observation does not allow specification of time value MARTE 1.0 MARTE 1.3 Resolved closed
MARTE13-13 The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE MARTE 1.0 MARTE 1.3 Resolved closed
MARTE13-6 Align the NFP profile and domain model with the QUVD meta-model MARTE 1.0 MARTE 1.3 Closed; Out Of Scope closed
MARTE13-9 [Time: Examples] MARTE 1.0b1 MARTE 1.3 Closed; No Change closed
MARTE13-1 About Gacenario::utilization property MARTE 1.0 MARTE 1.3 Resolved closed
MARTE13-5 SwResource should be a direct specialization of Resource, like its hardware counterpart MARTE 1.0 MARTE 1.3 Closed; No Change closed
MARTE13-12 Precise the shape of an array of ports of an array of parts MARTE 1.0 MARTE 1.3 Closed; No Change closed
MARTE13-26 Typo fixes MARTE 1.2 MARTE 1.3 Resolved closed
MARTE13-4 Refinement issue from GQAM to SAM MARTE 1.1 MARTE 1.3 Resolved closed
MARTE13-2 «GaWorkloadGenerator» and its pop attribute MARTE 1.0 MARTE 1.3 Resolved closed
MARTE13-15 Need a reference to a softwareSchedulable resource for Periodic, Aperiodic and sporadic pattern MARTE 1.1 MARTE 1.3 Deferred closed
MARTE13-8 Missing mappings between analysis duration, arrival patterns and clock constraints MARTE 1.0b2 MARTE 1.3 Deferred closed
MARTE12_-86 MARTE issue: Observation does not allow specification of time value MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-79 The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-69 Precise the shape of an array of ports of an array of parts MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-60 Annotation of Criticalities of NFP constraints MARTE 1.1 MARTE 1.2 Deferred closed
MARTE12_-58 Annotation of Criticalities of NFP values MARTE 1.1 MARTE 1.2 Deferred closed
MARTE12_-23 Missing mappings between analysis duration, arrival patterns and clock constraints MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-22 Align the NFP profile and domain model with the QUVD meta-model MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-52 Missing mappings between analysis duration, arrival patterns and clock constraints MARTE 1.0b2 MARTE 1.2 Deferred closed
MARTE12_-53 [Time: Examples] MARTE 1.0b1 MARTE 1.2 Deferred closed
MARTE12_-9 Refinement issue from GQAM to SAM MARTE 1.1 MARTE 1.2 Deferred closed
MARTE12_-1 About Gacenario:: MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-4 «GaWorkloadGenerator» and its pop attribute MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-6 Questions on observators within GQAM and SAM MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-18 SwResource should be a direct specialization of Resource, like its hardware counterpart MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-31 Allocations kind and nature MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-35 TIME model: clarification of ClockConstraint properties MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-84 Flow properties cannot be characterized with an RtSpecification MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-75 Page 269: Section 14.2.3.2, Stereotype Descriptions MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-7 Typo in diagram 14.25 for stereotype SwSchedulableResource MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-93 Specification of real time properties at "part with port" level MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-48 The IntervalType attributes are not the same ones in the profil diagram and profil elements description MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-62 Missing HwRouter stereotype to allow modeling of Networks-on-Chips MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-63 Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type MARTE 1.0b2 MARTE 1.2 Resolved closed
MARTE12_-107 Completion of Issue 12-63 MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-82 Missing synchronization resource in UML mapping for PpUnit MARTE 1.1 MARTE 1.2 Closed; No Change closed
MARTE12_-76 Update Table of Contents MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-2 Coherency between active resource of MARTE and active class in UML MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-46 The "Mb/s" baseUnit should be "Kb/s". MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-47 The DurationUnitKind doesn't exist any more MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-59 GRM:Support for Time table driven schedules MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-30 ImpliesConstraint of Allocate and Assign relationships MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-89 MARTE, sterotype <>, MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-54 VSL, Section B.3.3.9. The following attributes are missing (see figure B.7): MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-72 ClientServerFeature: possible ambiguity on provided/required status of signal reception MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-71 a verb is missed in last sentence of first § MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-64 The semantics of the Reshape should be precised MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-68 Constraint 6 on the tiler is just "Notation", this should be precised MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-80 ConcurrentAccessProtocolKind MARTE 1.0b1 MARTE 1.2 Closed; No Change closed
MARTE12_-91 use the stereotype <> alone MARTE 1.0b1 MARTE 1.2 Closed; No Change closed
MARTE12_-34 TIME model: name of referred section and name of section differ MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-36 TIME model: reference to TimeStructureRelation Library does not exists MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-37 TIME model overview: consistency of bullet descriptions MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-8 MARTE Clocks MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-39 TIME model: examples should be more pedagogical MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-38 TIME model: wrong section name MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-5 Typos issues in GQAM MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-87 MARTE: VSL short form for NFP_Real subtypes MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-20 Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-21 Missing constraint between scheduler and scheduling parameters MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-3 NfpConstraint stereotype: rename property mode to modes MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-17 Cannot precisely allocate an application to an execution platform described as a series of composite structures. MARTE 1.0b2 MARTE 1.2 Closed; No Change closed
MARTE12_-10 Introduce new chapter in section 6.4 MARTE 1.0b1 MARTE 1.2 Closed; Out Of Scope closed
MARTE12_-19 Runtimes may have multiple stacks MARTE 1.0b1 MARTE 1.2 Closed; No Change closed
MARTE11-108 GRM:Support for Time table driven schedules MARTE 1.0 MARTE 1.1 Resolved closed
MARTE_-66 stereotype GRM::SchedulableResource should have an attribute describing its activation parameters MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-65 MARTE/section 7.2.1/ "No Metamodel root" bug MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-64 Example in Figure 10.21 makes use of directed arrows MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-63 align the notation section of 11.3.2.7 to the profile diagram. MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-62 associations between Instance and ModelElement (subclasses) MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-61 MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-60 Section: 10/3 MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE11-110 The concept of System in Annex A.2 maps to a SysML concept MARTE 1.0 MARTE 1.1 Resolved closed
MARTE_-59 There should be a section to describe the different possible notations for the allocation MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-56 Typos in example Figures 17.15/16/17/27 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-58 Marte: more complete definition of contextParams in GaAnalysisContext (ch 15) MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-57 Marte: consistent capitalization of stereotypes in Sec 17.4 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-55 In HRM, the structure of the subprofile is ill formed MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-54 Missing attributes MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-53 In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)?? MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-52 In B.3.3.16, namespace must be replaced by namespace ::= ['.' namespace] MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-51 In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-48 In B.3.3.14, first rule, parentheses are not optional MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-47 Variable call expression and property call expression are ambiguous MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-46 In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-50 In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-49 In B.3.3.13, namespace must be replaced MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-43 In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid). MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-42 In B.3.3.7, the first rule allows defining bounds of different type, This should be forbidden MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-41 In B.3.3.7, literal-interval-bound should be separated in two interval bounds MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-45 In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-44 Properties of TupleType and ChoiceType should be constrained to be DataType only. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-39 Section B.3.3.3 is duplicated. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-38 In Section B.3.3.12 (Variables, p 416), the text is not aligned with the grammar MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-37 Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-40 In Section B.3.3.4., the DateTimeLiteral rule can be optimized MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-36 FlowPort stereotype MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-35 The notion of value is missing the NFP_Declaration domain model Description MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-34 ARINC 653 Annex of MARTE MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-33 The dependency between NFP and VSL is not necessary MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-32 using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-31 In GCM, domain model and profile do not match in ways that are not fully documented MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-30 GCM Classes Description in Annex should be revised: MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-29 MARTE/section 12.2/ "No assemblyConnectorEnd in the Metamodel" bug MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-28 MARTE/annexe E/ "No MultiplicityElement owner in the metamodel" bug MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-27 MARTE/RSM/repetition index port missing MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-26 MARTE/RSM/generalization of the reshape stereotype MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-25 inconsistencies in the HLAM subprofile MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-24 Figure 13.1 (pg 149) MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-23 Section: Annex D MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-22 Figure12.4 is wrong MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-21 Section: GQAM-SAM-PAM MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-18 NFP_Type MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-17 concrete syntax MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-20 Figure 16.6: multiplicity MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-19 definition of ResourceUsage (F.4.27) in annex F MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-16 clarify the semantical difference between an UML "Port" and a MARTE "Messag MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-15 Clarification in chapter "General Component Model" needed MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-14 MARTE aligment with SYSML 1.1 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-13 check UML 2.2 modifications impacts on MARTE Metamodel and definitions MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-12 What about a System Configuration concept having a set of OperationalModes? MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-11 rteConnector concept MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-10 Fig 15-7 shows that GaCommStep has the property MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-9 ordered association "subUsages" MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-8 property 'msgSize' in figure 15-7 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-7 MARTE profile-library interdependency should be revised and enhanced MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-6 HRM, fig 14-70, the stereotype HwMedia extends UML::Connector MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-5 typos in section E.3.2 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-4 Missing illustration for "Shape" and "reshape" stereotype MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-3 MARTE Beta: 12.3.2.4 FlowBFeature issue # 2 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-2 MARTE Beta: 12.3.2.4 FlowBFeature issue # 1 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-1 Annex 3 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE-187 TimedElements::TimedObservation (fig. 9.18) does not exist MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-186 Section: 13.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-185 first sentence of sub-section 6.4.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE11-109 RequestEventStream changed by WorkloadEvent MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-106 MARTE Beta 3: Invalid stereotype label in figure 11.8 MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-105 VSL - Absence of rule for calling behaviors MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-104 VSL - B.3.3.15 - typos in rule in the context of Property Call Expression MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-107 Domain concept (definingEvent) not implemented in the UML representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-103 VSL - B.3.3.17 - In conditional expressions, should not be optional MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-102 VSL - B.3.3.11 and B.3.3.12 - Introducing optional keywords ‘Tuple’ and ‘Choice’ MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-101 VSL - B3.3.9 - Typos in rule MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-100 GCM behavioral representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-99 MARTE Issue: Overloaded relationship Scenario to Step in Analysis MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-98 Inconsitencies in MARTE::GCM MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-97 Timing observer naming MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-96 MARTE AADL Annexe MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-95 13.3 UML Representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-94 • polling: PollingParameters [0..1] MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-93 Diagram shows {ordered usedResouces}, it should be {ordered usedResources}. MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-92 <> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML) MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-90 Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-91 Figure 8.5 UML profile diagram for NFPs modeling MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-86 Align notions of duration in NFP, Time and GQAM MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-85 Clarify the additional semantics brought by the GRM::TimingResource stereotype MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-88 The Step.host attribute is redundant, MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-87 Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-89 Typo in Figure 10.13: multiplicity of event property MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-84 NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-81 Typo in Figure 10.13: enery property MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-83 In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-82 ResourceUsage.requiredAmount aggregation kind should be composite MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-77 Inconsistency between the Time domain model and related profile MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-76 Inconsistent definition of CommunicationChannel properties MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-79 SAM Workload Figure defines a new property for GQAM::WorkloadBehavior MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-78 TimedElement.on default value should refer to the ideal clock MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-80 Figure 16.3 inconsistent with Figure 15.3 MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-74 SecondaryScheduler should be an association of the Scheduler instead of a specialized class MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-73 Update the GCM ClientServerPort to take into account evolutions in UML 2.3 MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-72 Remove the TimedObservation stereotype MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-71 AssigmentKind/AssignmentNature are redundant with AllocationKind/AllocationNature MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-75 PortGroup concept used in Annex A.2 is not defined in the MARTE profile MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-70 Different multiplicities in the GQAM meta-model and profile MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-69 Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-68 MARTE-AADL software concept upgrades MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-67 MARTE-AADL software concept upgrades MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-65 MARTE-AADL component implmentation modeling MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-64 MARTE-AADL connectors modeling MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-63 Annexe introduction MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-66 MARTE-AADL summeray table upgrade MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-62 DATA : MARTE AADL mapping MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-61 Feature group MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-60 FLOW : MARTE and AADL alignment MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-59 MARTE AADL annexe MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-58 Implied NFP constraint on stereotypes Assign and Allocate MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-57 Nature and Kind of Allocation and Assignment MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-56 Example of RtFeature update required MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-55 GQAM::RequestedService metaclass has no definition MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-54 Meta class BehaviorScenario not synchronized with its representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-53 NFP_Constraint metaclass syncho with its underlying stereotype MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-52 MARTE domain model: defintion of Trigger MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-51 Semantics description of TimedObserver MARTE 1.0 MARTE 1.1 Resolved closed
MARTE-184 Base unit errors in Figure D.3 MARTE 1.0b1 MARTE 1.0b2 Duplicate or Merged closed
MARTE-183 SendFlowAction and FlowSendAction MARTE 1.0b1 MARTE 1.0b2 Duplicate or Merged closed
MARTE-182 Movement of some stereotypes and attributes from PA to GA MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-181 MARTE PAM Parameters for behaviour demanded by a Step MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-98 MARTE-AADL Issue 5 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-94 Section: Annex A: AADL-like models with MARTE MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-93 description of the Clock stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-97 MARTE-AADL Issue 4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-96 MARTE-AADL Issue 3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-95 Section: Annex A: AADL-like models with MARTE -- issue 2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-92 Enhance the concept of Observer in GQAM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-91 How to model the size of code occupied in ROM? MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-100 MARTE-AADL Issue 7 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-99 MARTE-AADL Issue 6 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-107 Add short rationale in section 10.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-106 Explanation in section 7.3 hard to read MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-105 In section 2.4.2, the list of extension units and table 7.2 are redundant MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-104 Table 2.1, I would suggest using the profile names MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-103 Table 2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-102 Explain 'business management perspective" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-101 MARTE-AADL Issue 8 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-128 Support for Views or sets of profile annotations MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-127 Missing Delay and Offset in SAM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-130 page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-129 Consistency between RTEMoCC, SAM, and SRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-133 Missing attribute in figure MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-132 attribute “resMult” of Resource appears under its old name MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-131 use of stereotype names in UML model examples is inconsistent MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-138 RTF stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-137 Incorrect cross-reference to Figure numbers MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-126 HRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-125 HRM::HwMemory MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-134 Typos: MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-136 Incorrect cross-reference to chapter number on Page 309, third paragraph MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-135 Unfinished sentence on Page 313, the sixth paragraph MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-124 HRM::HwMemory stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-86 the GCM chapter should define a causality model for flows MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-75 Giving an attribute a variable name and an expression value MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-74 ports in GCM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-85 What are semantics of real-time features on provided/required interfaces? MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-84 chapter 11 (GCM) should be moved in the Part II of the specification MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-83 Find a better name of the RTEMoCC profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-82 RTEConnector should be removed from RTEMoCC MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-81 Figure E.10 (p 468): MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-90 How to model the size the heap size of an Ada runtime with SRM? MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-89 HwMedia.bandwidth attribute may need to be generalized in GRM ancestor clas MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-79 Tiler stereotype (pp 465,466 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-78 Shaped stereotype (pp 464,465): MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-88 How to model the amount of memory occupied by an OS resource MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-87 Support for flows in activities MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-77 Reshape stereotype (pp 463,464) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-76 Figure E.6 (p 460) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-80 E.4 Examples (pp 467,468): MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-159 Section: Annex A3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-158 TimingObserver in GQAM should be renamed to TimedObserver MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-161 Specify a maximum number of period for periodic real-time constraints MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-160 MARTE-GQAM) Kinds of delay in a Step MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-155 MARTE name prefixes MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-167 Clock stereotype needs to extend UML::Property MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-166 BFeatureSpecification constraint MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-164 Type NFP_Weight does not exist MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-163 ConstraintKind not documented MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-169 MARTE needs naming conventions for stereotype names and tag values. MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-168 Clarify the nature of DRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-157 no link between GRM::SchedulableResource and SRM::SwSchedulableResource MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-156 Section: 11.3.2.7 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-162 Dispatch protocols MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-165 "proreq" / "reqpro" literals do not exist in Beta 1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-70 SAM: General MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-69 GRM, GQAM, SAM: DomainModel & Profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-71 NFP: value syntax MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-73 Section: 1 MARTE spelling missing in the introduction MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-72 Section: HRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-140 Section: 8.3.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-139 stereotype attribute "GaExecHost.throughput" that is not documented MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-142 Section Allocation: Wrong direction of the allocation MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-141 using $ in naming variables MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-146 Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow". MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-145 expressing requirements MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-144 TimingResource of GRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-143 Section: 15.3 and 17.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-147 Correct the inconsistency between the diagram and the text MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-154 Section: Annex B (VSL) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-153 page 288: change explanation MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-149 picture 11.8, ports "loc" and "ftp" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-148 page 64 ClockConstraintSpecification MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-152 Section 16.2.2 (SAM) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-151 GQAM-SAM cyclic dependency due to GQAM::WorkloadBehavior MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-150 VSL variable declaration (inconsistency between the BNF and the metamodel) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-171 GQAM Domain view inheritances MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-170 GQAM Observers: inconsistency between domain view and UML representation MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-173 TimedDomain stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-172 wrong multiplicity in sharedResources required for a SaStep MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-178 figure 10.18 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-177 Inconsistencies in GQAM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-180 Section: Annex D.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-179 Errors in definition of GaEventTrace and GaWorkloadEvent MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-175 wrong numbering of figures MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-174 OCL rules for the Clock stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-176 The tiler stereotype should be applied on the UML::Port metaclass MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-123 Annex B: how VSL constructs shall be typed and evaluated MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-122 In Annex D, I would suggest make unit names (e.g. bits, bytes) singular MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-111 improve the usability of the RtBehavior stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-110 RtAction.isAtomic MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-109 Names should be identical MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-108 concept of refinement MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-117 VSL MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-119 GRM::SchedulableResource should have a period property MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-118 allocatedTo and allocatedFrom properties should not be derived MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-116 NFP does not introduce the concept of dimension MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-115 In section 6.1, I would suggest mentioning RTCORBA and CCM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-121 MARTE primitive types MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-120 Relationship between Alloc::Allocation and SRM::EntryPoint MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-113 suggest removing the notion of feature in the conformance section MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-112 For the sake of consistency, the rtf stereotype should be renamed MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-114 Section 6: Remove the MSWord comment MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-63 [GQAM: General] MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-62 HRM: Examples MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-61 MoCC: Examples MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-60 [Alloc: Profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-59 GRM: Examples MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-58 GRM: Domain Model MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-65 GQAM: Domain Model & Profile (02) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-64 GQAM: Domain Model & Profile (01) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-68 [SAM: Profile] MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-67 GQAM: Domain Model & Profile (04) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-66 GQAM: Domain Model & Profile (03) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-57 [Time] Fig. 9.29 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-56 [NFP: Profile]. Fig 8.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-55 Section: NFP MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-54 Consider providing a tabular notation (as in SysML) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-50 HwTiming model of the HwLogical profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-49 Section: 14.2 add two stereotypes corresponding to HwSensor and HwActuator MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-45 Section: 11.3.1 figure 11.6 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-44 Section: 11.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-53 In 12.4, all references to figures are wrong MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-52 Editorial issue MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-51 Suggest to extend ClockConstraints to ClockTypes MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-48 Section: 14.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-47 Section: 11.4.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-46 Section: 11.3.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-43 Section: 11.3.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-37 Minor edits to MARTE Chapter 17 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-36 Section: Annex B.2.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-42 Section: 11.2.1 (data reception) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-41 Section: 11.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-29 Class descriptions are missing MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-33 Section: 15.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-32 Section: 15/3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-8 Section: GRM / 10.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-7 concept of "resource" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-20 grammar defined for conditional expressions MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-19 Annex D MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-23 Annex B VSL BNF MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-22 VSL meta-model MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-5 Section: Annex B3.3.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-4 MARTE_Library::MeasurementUnits model library MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-10 rtf stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-9 Section: GRM / 10.3.1 - p 96 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-2 Consider adding a new attribute to «boundedSubtype» MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-1 UML Profile for MARTE acronym list MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-3 Naming conventions and typing errors MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-6 Section: Annex B3.3.3 p 397 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-17 Section 6/6.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-16 Section 6/6/2/1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-11 Annex D3 MARTE model library for time MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-25 non-terminal symbol MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-24 The VSL grammar does not define the "( )" symbol MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-26 automotive example MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-13 Figure 14.70 - HwCommunication package details MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-12 the property named "isSynchronous" is misspelled MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-18 Section 6/6.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-35 Section: Annex B MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-34 Section: 14.2.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-31 Section: 14/2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-30 Class descriptions are missing in the MARTE model library for GRM (Annex D4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-40 Section: 11.2.1 figure 11.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-39 Section: 11.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-27 GRM::SchedulableResource should not have a property "host:ExecutionHost" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-28 no explicit dependency to QVT concepts MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-21 Wrong references in page 397 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-15 Section 2/2.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-14 The type NFP_Price does not exist in the document. MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-38 Section: 11.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed

Issues Descriptions

Questions on observators within GQAM and SAM

  • Key: MARTE13-3
  • Legacy Issue Number: 18567
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    I was wondering, why two kinds of observators was designed within the GQAM as denoted in the figure shown below:

    Why not gathering both into one single stereotype? I propose to keep the second one, GaLatencyObs.

    In addition, I was also wondering why the <<SaSchedObs>> stereotype defined within SAM was not inheriting from <<GaLatencyObs>> instead of <<GaTimedObs>>?

    What do you think?

  • Reported: MARTE 1.0 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Clarification text on possible joint usage of GaLatencyObs and SaSchedObs

    GaLatencyObs specializes GaTimedObs to collect duration between two events which can be used in more domains than schedulability, while
    SaSchedObs is used to collect schedulability related metrics. The specified specializations are coherent with the intented usages.

    The specification misses a high level description introducing the usage of SaSchedObs. This resolution adds this text to the specification and fixes a typo related to GaTimedObs.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Annotation of Criticalities of NFP constraints

  • Key: MARTE13-11
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    Mix-criticality systems have the need to include allocated (or assigned) in the same model, representing either hardware or software platforms, elements with different levels of criticality. Eventually, for different levels of criticality different versions of the modelling element may need to be used. To handle this multiversions of modelling elements as well as to indicate the level of criticality at which a concrete condition expressed in a constraint must hold, there is the need to attach a level of criticality to the NFP_Constraint element in the MARTE profile.

    The simplest way to have this available in MARTE is by adding to NFPConstraint an attribute of the type NFP_Integer, called "Criticality".

    This would need a change in Figure 8.3 (page 41) , Figure 8.5 (page 44) , and the texts describing the NFPConstraint stereotype in cluse 8.3.2.5 on page 47 and the NFP_Constraint domain element in clause F.2.12 on page 566, by adding the attribute: criticality: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP constraint must hold.

    In a separate issue we express also the need to annotate criticalities for NFP Valuse, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP constraints.

    Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value represented with NFP_Integer is sufficient to annotate the criticality level for a value or a constraint.

  • Reported: MARTE 1.1 — Thu, 31 Mar 2016 13:28 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    NFP_Constraint criticality attribute

    This proposal adds an attribute criticality to NFP_Constraint and creates a NFP_Type named NFP_Criticality to capture criticality levels.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

The type of a composite aggregation Stereotype property cannot be a Stereotype

  • Key: MARTE13-39
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    The current MARTE specification contains 11 composite aggregation Stereotype properties typed by a Stereotype. This is not allowed by UML (Clause 12.3.3.4) : "The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotypes are owned by their
    Extensions) or a metaclass (since instances of metaclasses are owned by other instances of metaclasses);".

    The type of aggregation shall be changed to "reference". There are 11 changes to be done in HRM subprofile and one in Time subprofile.

  • Reported: MARTE 1.2b1 — Fri, 31 Mar 2023 17:38 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Remove composite aggregations types for Stereoypes properties

    Change the aggregation types from composite to reference for Stereotypes properties. These changes should be done on figures: 9.29, 9.30, 11.4, 11.5, 14.65, 14.66, 14.67, 14.68, 14.69, 14.72 and 14.73.
    These changes have impact on the XMI file.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Carbon footprint modeling

  • Key: MARTE13-33
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    The Carbon footprint is an interesting property for Hardware resources as well as Software ones. In fact, nowadays it is important to evaluate the CO2 footprint of a system (a laptop, a data center…).
    This criteria is depending on the usage of the resources (mainly for the software resources).
    We suggest adding a new property « co2Footprint » either in the “ResourceUsage” Stereotype” or in the Resource Stereotype for more general cases.

    The unit that measures the carbon Footprint is Kg of carbon dioxide equivalent (KgCO2e) per Year. This implies the addition of a new dimension in the Marte::MeasurementUnits «CarbonUnitKind» with new unit « kgCO2e » as well as a new NFP_Co2footprint that inherits from NFP_Real with unit = kgCO2e.

    The value of the CO2Footprint can be proportional to the origin of the energy used to produce the device in kWh eqC02. The proportional factor is country dependent https://app.electricitymaps.com/map

  • Reported: MARTE 1.2b1 — Wed, 28 Sep 2022 14:23 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Include a CarbonFootprint property

    Include a CarbonFootprint property to ResourceUsage.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Missing a property to PeriodicServerParameters

  • Key: MARTE13-16
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    In some case, when PeriodicServerParameters are used to model the parameter of a PSS (Posix Sporadic Server). it's happen that in some cases some SoftwareSchedulable resources could have the same background priority. So, to identify which one must be executed we need another parameter : order

    it is possible to add a property like this:

    order: NFP_Integer to the PeriodicServerParameters DataType.

  • Reported: MARTE 1.1 — Thu, 12 Apr 2018 13:04 GMT
  • Disposition: Closed; No Change — MARTE 1.3
  • Disposition Summary:

    MARTE 1.2 Specfication already provides this capability

    This is already supported by MARTE by the use of hierarchical schedulers.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Key: MARTE13-7
  • Legacy Issue Number: 14899
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The mappings between the analysis arrival patterns (periodic, sporatic, …) and Time durations, and clock constraints in CCSL should be defined in the specification.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.3
  • Disposition Summary:

    The two modelling approaches are not converging.

    The two modelling approaches are not converging so far and used for different purposes in different contexts.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

XMI files for MARTE 1.2 Profile and Library are not accessible without login

  • Key: MARTE13-25
  • Status: closed  
  • Source: No.Org ( Henning Riedel)
  • Summary:

    The MARTE 1.2 profile PDF are released and accessible, but the XMI files are only available by Member login.

  • Reported: MARTE 1.2 — Mon, 20 Jan 2020 22:27 GMT
  • Disposition: Closed; No Change — MARTE 1.3
  • Disposition Summary:

    MARTE 1.2 XMI files are accessible

    The MARTE XMI files are accessible here: https://www.omg.org/spec/MARTE

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Annotation of Criticalities of NFP values

  • Key: MARTE13-10
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    Mix-criticality systems have the need to host for a concrete magnitude (e.g. WCET) different values, each corresponding to a different level of criticality.

    The simplest way to have this available in MARTE is by following the same approach used for the source qualifier, this is by including an attribute of the type NPF_Integer (or even integer), called "CriticalityLevel" in NFP_Common_Type.
    This way the currently available versions of the MARTE profile do not need to be updated; only the parsers of VSL values commited to support mixed critical systems would need to be modified to parse the criticality attribute on VSL values if present.

    This would need a change in Figure D.5 and the text describing the NFP_Common_Type on page 504, by adding the attribute: criticalityLevel: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP annotation is valid.

    In a separate issue we express also the need to annotate criticalities for NFP_Constraints, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP values.

    Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value (better if represented with NFP_Integer) is sufficient to annotate the criticality level for a value or a constraint.

  • Reported: MARTE 1.1 — Thu, 31 Mar 2016 12:47 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Adding NFP_Criticality in NFP_CommonType

    To accommodate for the necessary values to express criticalities for any NFP value, the proposal is to:
    Create a new NFT type called NFP_Criticality inheriting from NFP_Integer with its value being the integer number to use for the criticality and two additional optional attributes:
    literal: String [0..1]
    standard: String [0..1]
    Typical values for them would be “ASILA”, “ASILB” or “ASILC” for the attribute denominated literal and “RAAML” or “ISO26262” for the attribute called standard.
    An attribute of this type, NFP_Criticality, is to be added under the name of criticality to NFP_CommonType, this is, adding the attribute:
    criticality: NFP_Criticality [*]

    Concrete changes would be:
    Change Figure D.5, in page 500, to this:

    In clause D.2.7 NFP_CommonType, in the section of the attributes add:
    criticality: NFP_ Criticality [*]

    Insert a clause D.2.8 NFP_Criticality between "D.2.7 NFP_CommonType" and current clause "D.2.8 NFP_DataTxRate, NFP_Frequency, NFP_Length, NFP_Area, NFP_Power,
    NFP_DataSize, NFP_Energy, NFP_Weight" with the following contents

    Generalization
    • NFP_Integer
    Attributes
    • literal: String [0..1]
    A string representing the label given to the corresponding level of criticality in the context of the concrete annotated model and the standard used to express it, if given. Typical values to this attribute might be “ASILA”, “ASILB” or “ASILC” for example
    • standard: String[0..1]
    A string indicating the nominal syntactical frame, usually a safety standard in which the label assigned to the corresponding criticality level is to be considered. Typical values for this attribute would be "IEC 61508/61511", "DO-178C", "DO-254", "RTCA DO-297", “RAAML” or “ISO 26262” to mention just some of which might be used to delimit a domain for which various criticality levels might need to be expressed.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

MARTE issue: Observation does not allow specification of time value

  • Key: MARTE13-14
  • Legacy Issue Number: 18657
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the current UML metamodel, there is no link from the metaclass Observation to a ValueSpecificaiton that can be used to specify the time value of the Observation. As a result, it is not possible to directly assign time values to TimedInstantObservation or TimedDurationObservation.

    This means that it is not possible to refer to the time values of such observations in a time expression.

    One easy solution is to create an association from the TimedObservation stereotype to the UML ValueSpecification metaclass (role name "value"). This could then be used to store the time value associated with either kind of time observation.

  • Reported: MARTE 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Add associations to UML ValueSpecification from TimedInstantObservation and TimedDurationObservation stereotypes

    Modify the UML representation by:

    • adding value role of type ValueSpecification to TimedInstantObservation and TimedDurationObservation stereotype
    • no need to modify the domain model because the issue of the missing value placeholder comes from UML
  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE

  • Key: MARTE13-13
  • Legacy Issue Number: 15275
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE

  • Reported: MARTE 1.0 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    add notion of access for AADL port

    Add new definition of "access property" to a connection in the section 4.2.6.2 page 404

    Fix the Issue by adding a "Access property" to the link between two aadl ports

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Align the NFP profile and domain model with the QUVD meta-model

  • Key: MARTE13-6
  • Legacy Issue Number: 14893
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Previous discussions between the SysML and MARTE communities have allowed relationships between both languages. An important convergence area relates to the notions of quantities, unit and dimensions. The SysML 1.2 RTF and the MARTE FTF work resulted in the definition of the QUVD meta-model (SysML Annex C.5). The MARTE NFP profile has not been yet entirely aligned on the QUVD meta-model. It would need aligned stereotyped when applicable (e.g. dimension vs. quantity type)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Closed; Out Of Scope — MARTE 1.3
  • Disposition Summary:

    Out of RTF scope

    The MARTE NFP profile and the QUVD meta-model have different scopes, and use different modeling approaches. Some mapping rules between a subset of the NFP profile and the QUVD meta-model (and vice-versa) could be done, but would require changes that are not achievable in the scope of an RTF.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

[Time: Examples]

  • Key: MARTE13-9
  • Legacy Issue Number: 11767
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [Time: Examples] One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.3
  • Disposition Summary:

    MARTE 1.2 Specification already provide this capability

    MARTE 1.2 provides Timing examples for the most used UML diagrams including sequence diagrams. Coming to UML Timing diagrams (which are one specialization of UML interactions diagrams), duration observations are used in the same manner as in sequence diagrams, and instant observations are explicitly specified. Constraints refering to those observations are used in the same way for all diagrams.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

About Gacenario::utilization property

  • Key: MARTE13-1
  • Legacy Issue Number: 18581
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    GaScenario has the attribute utilization. Its definition is : “The occupancy of the scenario, computed as the mean number of scenario instances active at any one time.”. What does “occupancy” mean?

  • Reported: MARTE 1.0 — Tue, 26 Mar 2013 04:00 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Clarification of the description of Utilization property.

    Clarification of the description of Utilization attribute.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

SwResource should be a direct specialization of Resource, like its hardware counterpart

  • Key: MARTE13-5
  • Legacy Issue Number: 14898
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the SRM meta-model, the SwResource specializes ResourceManager which makes SwSchedulableResource themselves. SwResource should be a direct specialization of Resource, like its hardware counterpart.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.3
  • Disposition Summary:

    Misunderstanding of the MARTE specification

    Software resource and Hardware resource are of different nature. Software resources gather bith the resource itself and the management of these resources. A detailed explanation of this inheritance is given in section 14.1.2.1 (MARTE 1.2) describing the SW_ResourceCore Package.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Precise the shape of an array of ports of an array of parts

  • Key: MARTE13-12
  • Legacy Issue Number: 15659
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    When a shaped port belongs to a shaped part, one should understand its shape as the product of both shapes as stated in the definition of the tiler. This should be stated here for the case when the reshape stereotype can be ommitted.

  • Reported: MARTE 1.0 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.3
  • Disposition Summary:

    The issue description is not clear.

    The issue description is not clear. Due to the long time since its submission, the reporter does not remember anymore what kind of precisions should be provided and proposed to close the issue.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Typo fixes

  • Key: MARTE13-26
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    p16 6.4.1 5th bullet

    This latter annex described [...] for defining the UML profile for
    MARTE itself, but also usefull for user models.

    -> MARTE itself while also being useful for user models.



    p17 3rd para (last before 6.4.3)

    [...] firstly we try to reduce the size of
    stereotype names as much as possible, but without scarifying their meaning

    -> sacrificing



    Globally replace contraint by constraint and Contraint by Constraint.
    Occurrences:
    p42 1st para (NFP_Contraints)
    p56 1st para 2nd line (Contraint)
    p56 2nd para 1st line (NFP_Contraints)
    p326 16.3.2.6 (Contraints)
    p327 16.3.2.7 (Contraints)
    p328 16.3.2.8 (Contraints)
    p444 B.3.2.1 (Contraints)



    Globally replace brokedResource by brokeredResource :
    p99 Figure 10.11 association from ResourceBroker to Resource
    p99 Figure 10.11 association from Scheduler to ProcessingResource
    p243 Figure 14.58 association from HW_Media to HW_Arbiter
    p606 F.4.22 Associations 1st bullet
    p610 F.4.30 Associations 1st bullet
    p653 F.9.8 Associations bullet
    p678 F.9.48 Associations bullet



    p100 Figure 10.13 upper left corner

    Causaility::CommonBehavior::

    -> Causality::CommonBehavior::



    p104 Figure 10.18 class ResourceUsage last attribute

    enery:NFP_Energy

    -> energy: NFP_Energy



    Globally replace occurence by occurrence and Occurence by Occurrence :
    p145 ReceiveOccurence (5x)
    p203 Figure 14.13 OccurencePolicyKind (2x), occurenceCountElements



    p188 Figure 13.12 statebox with start state

    Invation
    action

    -> Invocation



    p230 paragraph below Figure 14.40

    Figure 14.41 illustrates [..] (from UML::CompositesStructures::InternalStructures

    -> CompositeStructures



    p231 paragraph below Figure 14.42

    [...] On the right side, the SRM profile is used
    to describe the MemoryPartiton

    -> MemoryPartition



    Globally replace symetricalArray by symmetricalArray :
    p240 Figure 14.55 PLD_Class 1st attribute
    p250 Figure 14.66 PLD_Class 1st attribute (figure is duplicate of 14.55 ?)
    p274 Description 1st bullet
    p682 F.9.57 Literals 1st bullet



    p266 Attributes 4th bullet

    • throughput:NFP_DataTxRate
      Speciifes the throughput in a memory.

    -> Specifies



    Replace frequeny by frequency :
    p269 HwProcessor Constraints

    [3] ipc must derive from mips attribute and clock frequeny

    p672 F.9.39 Constraints

    [3] ipc must derive from mips attribute and clock frequeny



    p270 HwResource Associations 4th bullet

    • endPoints: HwEndPoint[0..*]
      Specifies the connection points of the HwReource.

    -> HwResource



    Globally replace adaptative by adaptive and Adaptative by Adaptive :
    p243 Figure 14.58 class HW_Router 2nd attribute (isRoutingAdaptative)
    p253 Figure 14.69 class HwRouter 2nd attribute (isRoutingAdaptative)
    p272 HwROM Attributes 2nd bullet (isRoutingAdaptative)

    Specifies whether the HW_Router supports adaptative routing or not.

    p677 F.9.46 Attributes 2nd bullet (isRoutingAdaptative)

    Specifies whether the HW_Router supports adaptative routing or not.



    p306 Attributes 8th bullet

    • utilizationOnHost: NFP_Real[*]
      The occupancy of thehost processor, executing Steps [...]

    -> the host



    p307 15.3.2.13 Attributes 2nd bullet

    • blockT: NFP_Duration [0..1]
      A delay inserted in the execution of the Step, waiting for an event [...],
      or for a condition such as the availability of passive protected resources nedded

    -> needed



    p311 16.1 2rd para 2nd sentence

    [...] aids developers to detect potentially
    unfeasible real-time architectures

    -> infeasible



    p321 Figure 16.8 class SaSchedObs 1st attribute

    suspentions: NFP_Integer [*]

    -> suspensions



    p323 3rd bullet from top of page

    • timing: TimedObs [*]
      Set of timing requirements or preditions that constrain local fragments

    -> preconditions



    p325 16.3.2.5 Attributes 2nd bullet

    • ISRprioRange: NFP_IntegerInterval [0..1]
      Range of ISR priorities supporte by the platform.

    -> supported



    p333 16.3.3.4 4th sentence

    [...] The software that
    hendles this is usually not part of the application

    -> handles



    p341 17.2.2.6 1st para

    3. [...] This may be a
    middlware layer (a web services connection,

    -> middleware



    p376 A.2.1.7 1st para 2nd sentence

    If not, they will be added through “NFP” and “NFP constraints”, precising the MARTE
    characteristics.

    Replace precising by tightening.



    p383 A.2.3.2 table cont'd, 1st row left column

    Deactive_execution_time (specific for mode switch) and
    Deactive_deadline (specific for mode switch)

    There is no such word deactive Please clarify.



    p383 A.2.3.2 table cont'd, 2nd row right column

    [...] “NFP” attributes by the enduser within the different threads

    -> end user



    p385 table 5th row right column

    <<swSchedulableResource>>
    hybride_task : my_comp

    -> hybrid_task



    p386 sentence between diagrams

    This model library is then instanciated:

    -> instantiated



    p393 table AADL Properties right column heading

    Marte Anaysis

    -> Analysis



    p395 table cont'd from p394 right column heading

    Marte Anaysis

    -> Analysis



    p395 A.2.4.6 4th sentence

    Alternatively, they may require driver softwares [...]

    -> programs



    p399 1st table right column AADL View

    thorttle_command: out data port

    -> throttle_command



    p404 A.2.6.3 4th para

    In MARTE, the FeatureGroup semantical perimenter will be [...]

    -> perimeter



    p415 Table A.1 2nd row 4th column (MARTE Stereotype)

    refering to an RtSpecification to denote

    -> referring



    p461 B.3.3.15 2nd para 2nd sentence

    When specifiyng values making reference to properties

    -> specifying



    p484 C.3.1.3 Constraints

    definingEvent->None.mpty( ) = defBody->isEmpty( ) }
    

    None.mpty looks incorrect, please clarify.



    p514 D.4.9.1 1st sentence

    This is a ChoiceType that [...] to express an offline time trable

    -> table



    p554 F.1.14 Associations 2nd bullet

    Instance that starts the invocartion.

    -> invocation



    p557 F.1.19 Attributes 2nd bullet

    * / upper : UnilimitedNatural

    -> UnlimitedNatural



    Globally replace AccesControlPolicy by AccessControlPolicy :
    p595 F.4.1 (2x), F.4.2 (2x)
    p601 F.4.14 Generalizations
    p612 F.4.32 Generalizations



    p604 F.4.20 Associations 4th and 5th bullet

    • provided: MARTE::NFP_Modelig::NFP_Declaration::NFP
      [...]
    • required: MARTE::NFP_Modelig::NFP_Declaration::NFP

    -> NFP_Modeling



    p609 F.4.27 Semantics 5th sentence

    [...] Two general forms of usage are defined the
    StaticUsage and the DinamicUsage,

    Two general forms of usage are defined, the
    StaticUsage and the DynamicUsage, [...]
    (comma after defined and spelling of DynamicUsage)



    p609 F.4.29 Generalizations

    * ConcurrencyResource (fromMARTE::GRM::ResourceTypes)

    -> from MARTE



    p610 F.4.29 Associations 2nd bullet

    * dependentScheduler: MARTE::GRM::scheduling::SecondarySceduler

    -> SecondaryScheduler



    p626 F.6.13 Attributes

    Drection of the flow property: either incoming (in),

    -> Direction



    p629 F.6.21 Semantics

    This concept matches the CompositeStructures::InternalStructures::StructuredClassier

    -> StructuredClassifier



    Globally replace Concurency by Concurrency :
    p629 F.7.1 CallConcurencyKind (title and text)
    p630 F.7.3 ConcurencyKind (title and text)
    p632 F.7.7 Attributes CallConcurencyKind



    p635 Associations 1st bullet

    * behaviors: RtBehaviror [*]

    -> RtBehavior



    p644 F.8.17 Associations 1st and 2nd bullet

    • readServices: BehaviroalFeature
      [...]
    • writeServices: BehaviroalFeature

    -> BehavioralFeature



    p644 F.8.18 Associations

    * accessedElement: CoreElements::Foudations::Property

    -> Foundations



    p665 F.9.29 Semantics 2nd para

    refined to a detailed model for [...] or ISS (Instuction Set Simulator)

    -> Instruction



    p672 F.9.39 Constraints

    [3] ipc must derive from mips attribute and clock frequeny.

    -> frequency



    p674 F.9.42 Associations 1st bullet

    • endPoints: HW_Communication::HW_EndPoint [0..*]
      Specifies the connection points of the HW_Reource.

    -> HW_Resource



    p685 F.9.63 Attributes 3rd bullet

    Specifies that the swithcing type is other than packet [...]

    -> switching



    p693 F.10.15 and F.10.16

    Constaints

    -> Constraints



    p700 F.11.5 Attributes 2nd bullet

    Range of ISR priorities supporte by the platform.

    -> supported



    p705 F.12.6 Attributes 2nd bullet

    • behaviorDemand: PBehaviorDemand [*]
      Set of demand sfor a behavior described by a scenario, [...]

    -> demands for



    p713 F.13.9 DataType (from DataTypes)

    DateType matches with the UML concept of [...]

    -> DataType

  • Reported: MARTE 1.2 — Mon, 10 Feb 2020 21:40 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Typo fixes

    This issue gathers typos in MARTE 1.2 specification and provides fixes for these issues.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Refinement issue from GQAM to SAM

  • Key: MARTE13-4
  • Legacy Issue Number: 18565
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The domain model of SAM defines the concept of EndToEndFLow which is described as being a container for a set of request event streams that trigger processing flows (identified as WorkloadEvent in the figure 16.3) and a set of end-to-end execution scenario (identified as BehaviorScenario in the figure 16.3) as response to a related set of request event stream.

    The domain model of GQAM defines the of WorkloadBehavior which is described as being a container for a set of behaviors defined as Scenario and a set of demands defined as WorkloadEvent. WorkloadEvent are defined as the cause of the Scenario. In this context, this latter is considered as being the effect of a WorkloadEvent.

    This specification raises both next issues:

    • Firstly, the stereotype «SaEndToEndFLow» introduced to map the SAM domain model element EndToEndFLow does not have properties fitting the endToEndStimuli and endToEndResponse properties of this latter. Consequently, the specification of stimuli and responses of a SaEndToEndFlow has to be done implicitly within the user model using containment relationships of the UML. The issue with such modeling mean is that the relationship between the SaEndToEndFlow and its containment is less formal and relies on specific means/choices to model the link between the SaEndToEndFLow and its stimuli and scenarios.
    • Secondly, the duality between both concepts, EndToEndFLow and WorkloadBehavior, seems to introduce unnecessary complexity. I would like to propose to define EndToEndFlow as a specialization of WorkloadBehavior, where both endToEndStimuli and endToEndResponse would refine respectively demand and behavior properties of the WorkloadBehavior concept.

    Miscellaneous:

    • In figure 16.3, EndToEndFLow has an association toward SAM_Obsrever::TimedObserver. A priori, it should be SchedulingObserver instead of TimedObsever.
    • In section “16.3.2.7 SaSchedObs”, SaSchedObs should inherit from GaTimedObs and not TimedObs as shown in figure 16.8.
    • In section “16.3.2.1 SaEndToEndFlow”, the timing attribute should be typed as SaSchedObs and not TimedObs.
  • Reported: MARTE 1.1 — Sat, 16 Mar 2013 04:00 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Refine SAM EndToEndFlow definition from GQAM WorkloadBehavior definition

    SAM EndToEndFlow concept is defined as a specialization of GQAM WorkloadBehavior, and the SaEndToEndFlow stereotype as a specialization of GaWorkloadBehavior stereotype. The SaEndToEndFlow stereotype provides now the placeholders for the formal specification of the end-to-end flow stimuli and response. This change is implemented with updates of text and figures accordingly in section 16 and Annex F.11.

    As explained in section 16.2.3 in SAM there are two kinds of Timed Observer that are used (LatencyObserver and SchedulingObserver). So figures 16.3 and sections 16.3.2.7 and 16.3.2.1 content is correct wr.r.t Timed Observers.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

«GaWorkloadGenerator» and its pop attribute

  • Key: MARTE13-2
  • Legacy Issue Number: 18576
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Can someone clarify the meaning of the pop attribute of the «GaWorkloadGenerator» stereotype?

  • Reported: MARTE 1.0 — Mon, 25 Mar 2013 04:00 GMT
  • Disposition: Resolved — MARTE 1.3
  • Disposition Summary:

    Add semantics description for pop attribute

    The description of pop attribute is missing.
    Add a semantics description for pop attribute in section 15.4.2.17.
    Add the population attribute and its description in section F.10.21 page 697

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Need a reference to a softwareSchedulable resource for Periodic, Aperiodic and sporadic pattern

  • Key: MARTE13-15
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    In the context of ARINC653 (but in other cases as well), we need to specific that a Periodic Pattern or Aperiodic or Sporadic is synchronise with the partition (schedulable Resource). that mean this king of events pattern starting synchronously with the partition (that mean the reference is the partition)

    So, could add this feature to MARTE to model Partition synchronised events whatever it is periodic, sporadic or aperiodic

  • Reported: MARTE 1.1 — Thu, 12 Apr 2018 13:41 GMT
  • Disposition: Deferred — MARTE 1.3
  • Disposition Summary:

    Issue Deferred

    Issue Deferred

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Key: MARTE13-8
  • Legacy Issue Number: 13654
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.

  • Reported: MARTE 1.0b2 — Tue, 3 Mar 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.3
  • Disposition Summary:

    Deferred to next version of MARTE

    The idea is interesting and can be applied to all other MARTE subprofiles.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

MARTE issue: Observation does not allow specification of time value

  • Legacy Issue Number: 18657
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the current UML metamodel, there is no link from the metaclass Observation to a ValueSpecificaiton that can be used to specify the time value of the Observation. As a result, it is not possible to directly assign time values to TimedInstantObservation or TimedDurationObservation.

    This means that it is not possible to refer to the time values of such observations in a time expression.

    One easy solution is to create an association from the TimedObservation stereotype to the UML ValueSpecification metaclass (role name "value"). This could then be used to store the time value associated with either kind of time observation.

  • Reported: MARTE 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Resolution of this issue is deferred to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE

  • Legacy Issue Number: 15275
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE

  • Reported: MARTE 1.0 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Precise the shape of an array of ports of an array of parts

  • Legacy Issue Number: 15659
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    When a shaped port belongs to a shaped part, one should understand its shape as the product of both shapes as stated in the definition of the tiler. This should be stated here for the case when the reshape stereotype can be ommitted.

  • Reported: MARTE 1.0 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Annotation of Criticalities of NFP constraints

  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    Mix-criticality systems have the need to include allocated (or assigned) in the same model, representing either hardware or software platforms, elements with different levels of criticality. Eventually, for different levels of criticality different versions of the modelling element may need to be used. To handle this multiversions of modelling elements as well as to indicate the level of criticality at which a concrete condition expressed in a constraint must hold, there is the need to attach a level of criticality to the NFP_Constraint element in the MARTE profile.

    The simplest way to have this available in MARTE is by adding to NFPConstraint an attribute of the type NFP_Integer, called "Criticality".

    This would need a change in Figure 8.3 (page 41) , Figure 8.5 (page 44) , and the texts describing the NFPConstraint stereotype in cluse 8.3.2.5 on page 47 and the NFP_Constraint domain element in clause F.2.12 on page 566, by adding the attribute: criticality: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP constraint must hold.

    In a separate issue we express also the need to annotate criticalities for NFP Valuse, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP constraints.

    Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value represented with NFP_Integer is sufficient to annotate the criticality level for a value or a constraint.

  • Reported: MARTE 1.1 — Thu, 31 Mar 2016 13:28 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Annotation of Criticalities of NFP values

  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    Mix-criticality systems have the need to host for a concrete magnitude (e.g. WCET) different values, each corresponding to a different level of criticality.

    The simplest way to have this available in MARTE is by following the same approach used for the source qualifier, this is by including an attribute of the type NPF_Integer (or even integer), called "CriticalityLevel" in NFP_Common_Type.
    This way the currently available versions of the MARTE profile do not need to be updated; only the parsers of VSL values commited to support mixed critical systems would need to be modified to parse the criticality attribute on VSL values if present.

    This would need a change in Figure D.5 and the text describing the NFP_Common_Type on page 504, by adding the attribute: criticalityLevel: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP annotation is valid.

    In a separate issue we express also the need to annotate criticalities for NFP_Constraints, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP values.

    Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value (better if represented with NFP_Integer) is sufficient to annotate the criticality level for a value or a constraint.

  • Reported: MARTE 1.1 — Thu, 31 Mar 2016 12:47 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Legacy Issue Number: 14899
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The mappings between the analysis arrival patterns (periodic, sporatic, …) and Time durations, and clock constraints in CCSL should be defined in the specification.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    The kinds of timing specification that can be done with arrival patterns are in an expressive domain (vocabulary, and abstraction intent) different than the one expected for the use of CCSL. But they are compatible in their usage over behaviorSpecifications. It may be good to have this mapping as a Library in the Annex C, but this does not invalidate the current specification. I suggest deferring again this issue for a possible future version of the standard.

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Align the NFP profile and domain model with the QUVD meta-model

  • Legacy Issue Number: 14893
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Previous discussions between the SysML and MARTE communities have allowed relationships between both languages. An important convergence area relates to the notions of quantities, unit and dimensions. The SysML 1.2 RTF and the MARTE FTF work resulted in the definition of the QUVD meta-model (SysML Annex C.5). The MARTE NFP profile has not been yet entirely aligned on the QUVD meta-model. It would need aligned stereotyped when applicable (e.g. dimension vs. quantity type)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    This issue needs further discussion with the SysML group in order to converge on the profile design of the QUVD meta-model. For timing reason, we decide to defer the resolution of this issue in order to get this time and propose a common resolution with the SysML group.

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Legacy Issue Number: 13654
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.

  • Reported: MARTE 1.0b2 — Tue, 3 Mar 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    In principle I though of using those in SRM and HRM plus some for those not defined. But a detailed review must be done. I suggest deferring this issue for the next version of the standard.

  • Updated: Tue, 8 Jan 2019 19:22 GMT

[Time: Examples]

  • Legacy Issue Number: 11767
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [Time: Examples] One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    No consensus

    No consensus has yet been reached on which diagram would be pertinent to insert in the specification itself.

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Refinement issue from GQAM to SAM

  • Key: MARTE12_-9
  • Legacy Issue Number: 18565
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The domain model of SAM defines the concept of EndToEndFLow which is described as being a container for a set of request event streams that trigger processing flows (identified as WorkloadEvent in the figure 16.3) and a set of end-to-end execution scenario (identified as BehaviorScenario in the figure 16.3) as response to a related set of request event stream.

    The domain model of GQAM defines the of WorkloadBehavior which is described as being a container for a set of behaviors defined as Scenario and a set of demands defined as WorkloadEvent. WorkloadEvent are defined as the cause of the Scenario. In this context, this latter is considered as being the effect of a WorkloadEvent.

    This specification raises both next issues:

    • Firstly, the stereotype «SaEndToEndFLow» introduced to map the SAM domain model element EndToEndFLow does not have properties fitting the endToEndStimuli and endToEndResponse properties of this latter. Consequently, the specification of stimuli and responses of a SaEndToEndFlow has to be done implicitly within the user model using containment relationships of the UML. The issue with such modeling mean is that the relationship between the SaEndToEndFlow and its containment is less formal and relies on specific means/choices to model the link between the SaEndToEndFLow and its stimuli and scenarios.
    • Secondly, the duality between both concepts, EndToEndFLow and WorkloadBehavior, seems to introduce unnecessary complexity. I would like to propose to define EndToEndFlow as a specialization of WorkloadBehavior, where both endToEndStimuli and endToEndResponse would refine respectively demand and behavior properties of the WorkloadBehavior concept.

    Miscellaneous:

    • In figure 16.3, EndToEndFLow has an association toward SAM_Obsrever::TimedObserver. A priori, it should be SchedulingObserver instead of TimedObsever.
    • In section “16.3.2.7 SaSchedObs”, SaSchedObs should inherit from GaTimedObs and not TimedObs as shown in figure 16.8.
    • In section “16.3.2.1 SaEndToEndFlow”, the timing attribute should be typed as SaSchedObs and not TimedObs.
  • Reported: MARTE 1.1 — Sat, 16 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

About Gacenario::

  • Key: MARTE12_-1
  • Legacy Issue Number: 18581
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    GaScenario has the attribute utilization. Its definition is : “The occupancy of the scenario, computed as the mean number of scenario instances active at any one time.”. What does “occupancy” mean?

  • Reported: MARTE 1.0 — Tue, 26 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

«GaWorkloadGenerator» and its pop attribute

  • Key: MARTE12_-4
  • Legacy Issue Number: 18576
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Can someone clarify the meaning of the pop attribute of the «GaWorkloadGenerator» stereotype?

  • Reported: MARTE 1.0 — Mon, 25 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Questions on observators within GQAM and SAM

  • Key: MARTE12_-6
  • Legacy Issue Number: 18567
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    I was wondering, why two kinds of observators was designed within the GQAM as denoted in the figure shown below:

    Why not gathering both into one single stereotype? I propose to keep the second one, GaLatencyObs.

    In addition, I was also wondering why the <<SaSchedObs>> stereotype defined within SAM was not inheriting from <<GaLatencyObs>> instead of <<GaTimedObs>>?

    What do you think?

  • Reported: MARTE 1.0 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

SwResource should be a direct specialization of Resource, like its hardware counterpart

  • Legacy Issue Number: 14898
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the SRM meta-model, the SwResource specializes ResourceManager which makes SwSchedulableResource themselves. SwResource should be a direct specialization of Resource, like its hardware counterpart.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Allocations kind and nature

  • Legacy Issue Number: 16835
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    There are many possible usages for the Allocation concept which cannot be restricted to those listed in the AllocationKind and AllocationNature enumerations.

    The “kind” and “nature” attribute of both <<Allocate>> and <<Assign>> stereotypes should be optional (multiplicity: [0..1]). Alternatively, a literal could be added to the enumerations named above, such as “unspecified” or “other”, to address usages which are not covered by the existing literals.

  • Reported: MARTE 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Adopt proposal

    I propose to adopt the first proposal that do not break anyway the forward compatibility of the MARTE profile. Anyway according to the diagram shown in figure 11.4, multiplicity of both properties kind and nature should be [0..1].
    A priori, the same should be done for the assign stereotype.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

TIME model: clarification of ClockConstraint properties

  • Legacy Issue Number: 17343
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    problem:

    In section 9.3.1.3, on figure 9.28, the ClockConstraint stereotype have three properties named "isCoincidenceBased", "isPrecedenceBased", "isChronometricBased". These three attributes refers to the kind of relation(s) resulting from the constraint enforcement. This kind of relation are described by three named bullets in the time model overview, chapter 9.1. The name of the bullets and the name of the properties should conform. These properties are described in section 9.3.2.2, the names should also refer to the bullet names.

    proposed resolution:

    rename the properties of the ClockConstraint stereotype to conform with the name of the bullet in section 9.1. The section 9.3.2.2 should be kept consistent with such changes.

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Rename the properties

    rename the properties of the ClockConstraint stereotype to conform with the name of the bullet in section 9.1. The section 9.3.2.2 should be kept consistent with such changes.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Flow properties cannot be characterized with an RtSpecification

  • Legacy Issue Number: 16583
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    The type of the derived property RtSpecification::context is BehavioralFeature. It can be used to specify that the RtSpecification actually concerns a particular behavioral feature (i.e. Operation or Reception) exposed by a port (the port being identified by the RtFeature owning this RtSpecification).

    This works well with ClientServer ports. However, it cannot be used to characterize flow properties of FlowPort, since a FlowProperty is a StructuralFeature, not a BehavioralFeature.

    An easy solution to address that is to make the type of /context Feature, instead of BehavioralFeature.

  • Reported: MARTE 1.1 — Thu, 6 Oct 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Change text

    Change RtSpecification::context: BehavioralFeature into RtSpecification::context: Feature.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Page 269: Section 14.2.3.2, Stereotype Descriptions

  • Legacy Issue Number: 16248
  • Status: closed  
  • Source: International Business Machines ( Mr. Irv Badr)
  • Summary:

    Add the following :
    McProcessor
    The McProcessor stereotype maps the McProcessor domain element
    Generalizations
    HwProcessor
    Attributes
    Core_Id: NFP_Natural

  • Reported: MARTE 1.0 — Tue, 17 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Resolved

    {Summary of how the issue is to be resolved}

    The Intention seems to be having a way to label the specific affinity or identification of all and each of the cores of a multi-core processor. This leads to include a new kind of Processor, called Hw_McProcessor, which inherits from Hw_Processor but add the Core_Id as an attribute.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Typo in diagram 14.25 for stereotype SwSchedulableResource

  • Key: MARTE12_-7
  • Legacy Issue Number: 16229
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Attribute schedulers : NamedElement [1] of SwSchedulableResource should be "scheduler : NamedElement [1]"

  • Reported: MARTE 1.1 — Thu, 12 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Update figure

    Update the figure in question according to the proposal of the issue summary.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Specification of real time properties at "part with port" level

  • Legacy Issue Number: 15166
  • Status: closed  
  • Source: Intecs ( Stefano Puri)
  • Summary:

    Currently HLAM::RtSpecification,RtFeature stereotypes allow modeling of real-time features for operations provided/required through ports at class level, while is not possible to use RtFeature/RtSpecifcation at "part with port" level. It would be useful to have this feature in order to be able differentiating quantitative attributes like deadline, period at part (i.e. instance) level in a composite structure diagram.

  • Reported: MARTE 1.0 — Thu, 8 Apr 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Enable to annotate the connector

    If we add the possibility to annotate the parts with RtFeature, it may be ambiguous to distinguish the port of the part the RtFeature is applied on expect of we add an extra property to this stereotype to explicitly specify it when the stereotype is applied on a part. Consequently, we propose to enable to annotate the connector end linked to the port of the part. In that case, there is no ambiguity. Next revised text consists then of a description of all the subsequent changes needed to be done in the specification.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

The IntervalType attributes are not the same ones in the profil diagram and profil elements description

  • Legacy Issue Number: 15433
  • Status: closed  
  • Source: Softeam ( Emilie Houziaux)
  • Summary:

    page 436, the IntervalType has the "intervalAttrib" attribute.

    page 451, the IntervalType has both "minAttrib" and "maxAttrib" attributes.

    The IntervalType attribute(s) should be the same ones.

  • Reported: MARTE 1.0 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Resolved

    This issue actually refers to the following pages:

    • Page 436: In figure B.7, stereotype «IntervalType» is depicted with on single property intervalAttrib
    • Page 439: According to section B.3.2.4, sub-section Attributes, interval type carries two attributes, minAttrib and maxAttrib
      As suggested in the summary of the issue, the same attributes should be used in both cases. According to section F.13.18 (description of IntervalType from the domain model) and exemple of Figure B.9, intervalAttrib must be used.
      The proposed resolution consists in updating section B.7. Also, while the “associations” clause of F.13.18 is correct, the “semantics” clause still reference properties minAttribute and maxAttribute. In the proposed resolution, this “semantics” clause is also updated.
  • Updated: Wed, 19 Dec 2018 16:37 GMT

Missing HwRouter stereotype to allow modeling of Networks-on-Chips

  • Legacy Issue Number: 16158
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    An extension to the HwMedia stereotype should be added to allow the modeling of Networks-on-Chips in addition to buses as the become more and more the communication media of choice for new generation systems-on-chips.

    This HwRouter stereotype could have the following attributes:
    + fifoSize: NFP_DataSize
    + isRoutingAdaptative: NFP_Boolean
    + switchingType: SwitchingType
    + isSynchronous: NFP_Boolean
    + fifoLocation: FifoLocationSpecification

    with the following definition of SwitchingType:
    «Enumeration»
    SwitchingType
    paquetSwitching
    circuitSwitching
    other
    undefined

    and of FifoLocationSpecification:
    «Enumeration»
    FifoLocationSpecification
    input
    output
    both

  • Reported: MARTE 1.0 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept proposed changes

    As proposed in the issue text, a stereotype has to be added to the HwCommunication sub-profile. This impacts the summary of the HRM profile domain view (14.2.2), its UML representation (both the diagrams, 14.2.3.1, and the list of stereotypes, 14.2.3.2) and the description of the corresponding domain elements (F.9).

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type

  • Legacy Issue Number: 13668
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type do allow to discriminate between interleaved and non interleaved multi-bank memories

  • Reported: MARTE 1.0b2 — Tue, 10 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Modification may be done easily without introducing any compatibility issue.

    N/A

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Completion of Issue 12-63

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The issue resolution for 12-63 aims to add an isInterleaved property to the MemoryOrganization stereotype. This resolution is not complete since the MARTE domain model is not updated at the same time than the profile.

  • Reported: MARTE 1.1 — Wed, 16 May 2018 11:40 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Completion of Issue 12-63

    Section 14.2.2.2 shall be updated to include new version of Figure 14.56. In this updated version, the Figure 14.56 shall show the property isInterleaved : NFP_Boolean in the MemoryOrganization concept.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Missing synchronization resource in UML mapping for PpUnit

  • Legacy Issue Number: 18165
  • Status: closed  
  • Source: Universidad de Cantabria ( Alejandro Péz Ruiz)
  • Summary:

    We have detected an inconsistency between the semantic description and its mapping to UML for Protected Passive Unit (PpUnit). In figure 13.3 and in the Annex F.7.7, PpUnit inherits from BehavioredClassifier and SynchResource. But when you see the UML Representation (Section 13.3) in Figure 13.8, the PpUnit inheritance from BehavioredClassifier is taken into account by using it as the base elements to be extended with the stereotype. Its nature as synchronization resource is not explicitly mapped to UML.
    For these reasons, and considering the need to link a PpUnit with its implementing mutual exclusion resources that we propose a PpUnit to have an additional attribute (with multiplicity 0..n) that includes the MutualExclusionResource that the existence of the PpUnit implies. Being a GRM:: MutualExclusionResource a specialization of SynchResource, this attribute maps the synchronization resource nature of the PpUnit as it is expressed in its definition in the Annex F.

  • Reported: MARTE 1.1 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Closed no change

    The concept of PpUnit is part of HLAM which provides a set of high level concepts for dealing with real-time, parallel and concurrent modeling concerns without “implementation” flavors. Adding such properties as previously denoted in the issue summary would introduce such dependency with “implementation” concern.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Update Table of Contents

  • Legacy Issue Number: 16247
  • Status: closed  
  • Source: International Business Machines ( Mr. Irv Badr)
  • Summary:

    Updated Table of Contents to reflect topics according to updated formatting

  • Reported: MARTE 1.0 — Tue, 17 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Regenerate ToC

    Need to regenerate the ToC using Framemaker. It will be done when the issue resolutions will be integrated in the specification and the 1.2 version will be produced.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Coherency between active resource of MARTE and active class in UML

  • Key: MARTE12_-2
  • Legacy Issue Number: 16224
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In GRM, a Resource may be active. MARTE needs to specify the relationship(coherency) between an active resource and and active class.

  • Reported: MARTE 1.1 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept changes

    Before stating the resolution taken, let us have here a summary of the discussion held:
    >>Sebastien Gerard:
    This issue is about the relationship between UML active class and the concept of active resource as defined in GRM.
    An active class is defined in UML (clause 13.3.8) as:
    “An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as “the object having its own thread of control.”) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.”

    In GRM, the concept of Resource owns an attribute named isActive which definition is following:
    “If true it indicates that the resource has an initial behavior associated that allows it to possibly perform its services autonomously or by the triggering and animation of behaviors on others.”

    Semantics seems to be equivalent, but the stereotype Resource extend Classifier and not only class, meaning that any kind of classifier can be active.
    Question: are we sure that it make sense for <<resource>> to extend Classifier and not only Class?
    What are the other know use cases of using this stereotype on other classifiers than Class?
    >>Bran Selic:
    Good point. The notion of "isActive" was intentionally restricted to objects (as the definiton states). It seems inappropriate and inconsistent with UML semantics for MARTE to extend that to classifiers in general. Note that, in principle at least, profiles should exist solely within the confines of UML semantics (stretchable as they may be).
    >>Julio Medina:
    Regarding the consideration of active resources beyond "classes" I recall the fact that very frequently we use the SchedulableResources (threads, processes and so on) as targets of steps not only through allocation relationships or direct association, but also by using directly scenarios (activity diagrams or sequence charts). And a very graphical mean to express this allocation is by using swimlanes (partitions), activities, or lifelines instead of classes. [Schedulable resources are a kind of resources with isActive always true].
    This happens because the means schedulability analysis has to cope with complexity is by demanding the designer for depicting worst case scenarios, instead of only behaviors. I understand that we can force the modeler to always define new (utilitarian) objects or classes for this purpose in what we call the platform model (which is good from a methodological point of view), but there is a significant expressiveness in defining this relationships by directly locating the steps in these scenario based diagrams. Also, this easies the expression of dynamic creation/destruction of threads.
    I do not see why this extension would conflict with the limited view of active class that was originally in UML. I actually think that profiles are precisely to extend the semantics available through UML though keeping its original design intents working. Of course, as I mentioned, from a methodological point of view this restriction is not that bad and in practical terms (just by chance) the tools we have already made are currently not relying on these capabilities of MARTE, but I think this is an unnecessary limitation, and there might be many other practitioners that use them.

    >>Murray Woodside
    We use SchedulableResource this way all the time in performance analysis too. However putting isActive on the objects (the instances) works well... conceivably the same class could be passive in some instances and active in others (though I have never seen this).

    >>Bran Selic:
    Julio, If I understood you correctly, you want to be able to imply the notion of active objects without being forced to actually model the object itself. This is because for some purposes, such as schedulability analysis, it was not necessary to have the explicit object in the model – it saved time and effort. We used this method a lot in the original SPT profile. I think it is useful, but, unless it is properly documented, people will simply not know about it and will not take advantage of the capability – we learned this from the SPT experience.
    My suggestion then is to keep things as they are, but that you provide at least an example in the spec for how to use this capability. Without that, the issue may be brought up again.

    >>Sébastien Gerard:
    I agree with the proposal of Bran. Julio, can you provide this example?

    Summary:
    So the way of making its use consistent with UML will be let to the user with the assistance of an additional example that is here provided.
    The resolution is then to add an example of how to model platform active elements like schedulableResources without defining them as objects or classes, but doing it directly as elements of behavioral models. This example is inserted at the end of the SAM Chapter.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

The "Mb/s" baseUnit should be "Kb/s".

  • Legacy Issue Number: 15434
  • Status: closed  
  • Source: Softeam ( Emilie Houziaux)
  • Summary:

    In the DataTxRateUnitKind dimension, the "Mb/s" baseUnit should be "Kb/s" (and convFactor = 1024) or the convFactor should be 1048576 (and baseUnit = "b/s").

  • Reported: MARTE 1.0 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept proposal

    The issue refers to figures 8.6 (p.48) and D.3 (p.488). In these two figures, the “baseUnit” associated with “Mb/s” is “b/s”, while it should be “Kb/s”. The proposed resolution replaces “b/s” by “Kb/s” in the two figures.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

The DurationUnitKind doesn't exist any more

  • Legacy Issue Number: 15432
  • Status: closed  
  • Source: Softeam ( Emilie Houziaux)
  • Summary:

    The DurationUnitKind described in the D.2.10 NFP-Duration section, doesn't exist any more.

    "unit" should be a TimeUnitKind as described in the figure 8.6, page 48.

  • Reported: MARTE 1.0 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept changes

    Indeed, DurationUnitKind does not exist anymore. The proposition described in the summary is followed.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

GRM:Support for Time table driven schedules

  • Legacy Issue Number: 15310
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    Having the opaque expresion attribute "schedule" in the Scheduler in GRM lead to a very open way of expressing fixed schedules or non-traditional scheduling policies. This is the case of time triggered sets of tasks in particular, but also of any form of table driven schedule, like IMA platforms. Following a general approach but formalizing the way of expressing schedules as a set of labeled timed windows would make the exchange of information between strict time triggered platforms design intent and its corresponding analysis models easyer and in a standardized way.

    An alternative to study may be formalizing the attribute “schedule” of a scheduler to include at least the frame_cycle_time, and the list of “windows” or “time_slots” to be managed as schedulable resources. To do this the easiest way may be to make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler.

  • Reported: MARTE 1.0 — Sat, 26 Jun 2010 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Duplicate

    This is a duplicate of issue MARTE11 108 that has been resolved in MARTE 1.1

  • Updated: Wed, 19 Dec 2018 16:37 GMT

ImpliesConstraint of Allocate and Assign relationships

  • Legacy Issue Number: 15291
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to its definition, the impliesConstraint association of both Allocate and Assign stereotypes should be a composition and not a simple reference

  • Reported: MARTE 1.0 — Wed, 16 Jun 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept changes

    Make the changes in the allocation profile of MARTE according to the proposition done in the issue summary.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

MARTE, sterotype <>,

  • Legacy Issue Number: 15261
  • Status: closed  
  • Source: Sherpa Engineering ( Daniela Cancila)
  • Summary:

    problem:
    Informal matching between a safety element and an architectural element.

    analysis:
    (1) We could introduce a new stereotype from a scratch (e.g. by extending <<trace>>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models.

    (2) We could reuse <<assign>> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability.
    In this solution, stereotype <<assign>> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <<assign>> with a new stereotype with fixed values for both ''kind'' and ''nature''

    proposed solution (by Bran Selic):
    (a) provide additional enumeration literals for these two attributes of <<assign>> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <<assign>>, so that it can be used to model other types of "allocation" relationships

    project:
    IMOFIS project of the System@tic
    Paris R´egion Cluster. It is sponsored by the ”Safe, reliable and adapted transportation”
    program (PREDIT) of the “Agence Nationale pour la Recherche”.

    Impact on the Industrial Context:
    The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues.
    The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture.

  • Reported: MARTE 1.0 — Thu, 20 May 2010 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Closed no change

    What is requested here is to specialize <<assign>> such that its two attributes, "kind" and "nature", always have the same value. They would like to do this without defining a new stereotype. Of course, this is possible and does not require any change to MARTE, but it does require the addition of a constraint on <<assign>>, which, in turn, requires a new profile (albeit a trivial one, containing just that one constraint). Alternatively, they could include this constraint in their application model – although that would have to be done in every individual model.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

VSL, Section B.3.3.9. The following attributes are missing (see figure B.7):

  • Legacy Issue Number: 16162
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    VSL, Section B.3.3.9. The following attributes are missing (see figure B.7):

    baseType : VSL::DataTypes::DataType [1] Designates an ordered DataType.

    ..

    isMinOpen: Boolean [0..1] Defines if minValue is excluded in the bounded value space.

    isMaxOpen: Boolean [0..1] Defines if maxValue is excluded in the bounded value space.

  • Reported: MARTE 1.0 — Fri, 29 Apr 2011 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Closed no change

    Section B.3.3.9 refers to the VSL grammar rule for the production of interval specifications. There is no clause in this section where it is needed/possible to include such property description.
    Note also that, according to figure B.7, these properties belong to BoundedSubtype, and that they are appropriately described in section B.3.2.1.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

ClientServerFeature: possible ambiguity on provided/required status of signal reception

  • Legacy Issue Number: 16012
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    in the following sentence:
    ------------
    If kind is required it is expected to be a required operation or signal reception while if kind is provided, it is expected to be a provided operation or signal reception.
    ------------

    it would be more explicit to precise that signal receptions are respectively also "required" and "provided", e.g.:
    ---------------
    If kind is required it is expected to be a required operation or a required signal reception while if kind is provided, it is expected to be a provided operation or a provided signal reception.
    ---------------

  • Reported: MARTE 1.0 — Mon, 7 Feb 2011 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Update the paragraph in question according to the proposal of the issue summary.

    N/A

  • Updated: Wed, 19 Dec 2018 16:37 GMT

a verb is missed in last sentence of first §

  • Legacy Issue Number: 16010
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    in the sentence:
    -------------
    Hence, the idea to associate time structure with events, behaviors, and objects, or more
    generally instances of the concrete subtypes of the BehavioredClassifier metaclass.
    -------------

    it seems that a verb is missed... perhaps this could be reformulated as:
    ---------------
    Hence, the idea is to associate time structure with events, behaviors, and objects, or more
    generally instances of the concrete subtypes of the BehavioredClassifier metaclass.

  • Reported: MARTE 1.0 — Mon, 7 Feb 2011 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Update the paragraph in question according to the proposal of the issue summury.

    N/A

  • Updated: Wed, 19 Dec 2018 16:37 GMT

The semantics of the Reshape should be precised

  • Legacy Issue Number: 15727
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    The current specification is ambiguous and should be refined.

    The issue is the way the elements of the tiles are connected from one end to the other. This connection should be point-to-point.

  • Reported: MARTE 1.0 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Some text has to be added to the “Semantics” section of the Reshape concept page 534.

    Adding new text

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Constraint 6 on the tiler is just "Notation", this should be precised

  • Legacy Issue Number: 15660
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    What does this "Notation" means? Either remove it or precise it.

  • Reported: MARTE 1.0 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Editorial

    This is an edition error. Constraint 6 should be a section titled Notation and constraint 7 should be the contents of this section.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

ConcurrentAccessProtocolKind

  • Legacy Issue Number: 12403
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    "ConcurrentAccessProtocolKind" contains several enumeration literals, one of them is "Other." With this representation, it is possible to represent ONE implicit user define protocol acces but impossible to make the distinction between various protocols defined by the end user like for exemple (ex: .Interrupt_Masking, Maximum_Priority).

  • Reported: MARTE 1.0b1 — Tue, 22 Apr 2008 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    This kind of specific concept can be defined within a dedicated profile extended MARTE

    This kind of specific concept can be defined within a dedicated profile extended MARTE. You then have to specialize the stereotype owning the property typed as ConccurentAccessProtocolKind, define a new enumeration defining your own concurrent access protocol and then refine the property of interest for you within the new stereotype. As for example, you can define a new stereotype called «MySwMutualExclusionResource» specializing the MARTE stereotype «SwMutualExclusionResource» and then redefine the property mechanism by changing its type with the one new enumeration that will contain the literals that fit your needs.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

use the stereotype <> alone

  • Legacy Issue Number: 11706
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    ApplicationAllocationEnd and ExecutionPlatformAllocationEnd differentiate the client and the supplier of the allocation. In case where a model element is both the source of an allocation and the target of another allocation it would be practical to be able to use the stereotype <<allocated>> alone instead of applying the two stereotypes <<app_allocated,ep_allocated>>.

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    The property kind of the stereotype «Allocated» specifies the nature of the allocated element

    The property kind of the stereotype «Allocated» specifies the nature of the allocated element. The type of the property is the AllocationEndKind enumeration that contains the literal both that enables to specify that an allocated element plays both role in allocation specification, application and platform role.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

TIME model: name of referred section and name of section differ

  • Legacy Issue Number: 17341
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    problem:

    In section 9.2.4.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Clock constraint specifications are special value specifications described in Annex C (Clock Constraint Specification Language)". However, the reference should be to annex C.3 and the named of annex C.3 is "Clock Constraint Specification".

    proposed resolution:

    change annex C to annex C.3 in the text of chapter 9.2.4.2.
    rename the annex C.3 as "Clock Constraint Specification Language"

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept changes

    change annex C to annex C.3 in the text of chapter 9.2.4.2.
    rename the annex C.3 as "Clock Constraint Specification Language"

  • Updated: Wed, 19 Dec 2018 16:37 GMT

TIME model: reference to TimeStructureRelation Library does not exists

  • Legacy Issue Number: 17340
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    problem:

    In section 9.2.2.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Predefined time base relations are suggested in the TimeStructureRelation Library of MARTE. The semantics of these relations is given in OCL.". However, the TimeStructureRelation Library does not exist in the specification.

    proposed resolution:

    There exists a description of predefined time base relations in the annex C. We propose to modify the text as well as the example depicted figure 9.7 to conform with the existing predefined time base relations.

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Modify text

    There exists a description of predefined time base relations in the annex C. We propose to modify the text as well as the example depicted figure 9.7 to conform with the existing predefined time base relations.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

TIME model overview: consistency of bullet descriptions

  • Legacy Issue Number: 17339
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    problem:
    In section Overview of the time model chapter, there are three bullets to describe the time. In these bullet titles, the slash ('/') character has different meaning:

    • Causal/temporal --> it should be understood as causal vs temporal
    • Clocked/synchronous --> it should be understood as Clocked or synchronous
    • Physical/real-time --> it should be understood as Physical or real-time

    proposed resolution:

    the bullet should be renamed with:

    • Causal (untimed):
    • Synchronous (partially timed):
    • Physical (real-time):

    additionally, to keep consistency, the last sentence of the last bullet should be rephrased, for instance with :
    "Physical time models refine the partially timed models by adding reference(s) to one or more physical dimensions, for instance to derive the admissible speed of a reaction."

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Update the paragraph in question according to the proposed resolution.

    the bullet should be renamed with:

    • Causal (untimed):
    • Synchronous (partially timed):
    • Physical (real-time):
      additionally, to keep consistency, the last sentence of the last bullet should be rephrased, for instance with : "Physical time models refine the partially timed models by adding reference(s) to one or more physical dimensions, for instance to derive the admissible speed of a reaction."
  • Updated: Wed, 19 Dec 2018 16:37 GMT

MARTE Clocks

  • Key: MARTE12_-8
  • Legacy Issue Number: 16609
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In the time chapter, I was reading the following sentence in clause 9.3.1.1: “When the property "on" is not specified, it should be understood as being by default, a dense chronometric clock with no flaws that represent the physical time.”

    However, the lower bound of the multiplicity of the on role from TimedElement to Clock is one, meaning that one value at least has to be specified. May the aforementioned sentence should be repharsed, isn’t?

  • Reported: MARTE 1.0 — Sat, 15 Oct 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Update the paragraph in question according to the proposed resolution

    The goal here was to ease the creation of the model while always keeping an explicit clock serialized in the model when the designer does not specify it explicitly. We have to specify in the text that a link to the idealClk clock must be set by the modeling tool when the designer does not explicit it (i.e. as a default clock).

  • Updated: Wed, 19 Dec 2018 16:37 GMT

TIME model: examples should be more pedagogical

  • Legacy Issue Number: 17344
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    problem:

    In section 9.3.3 (Examples) from the time model, the examples describe some complex and pathological cases, which reflect the good expressiveness of the time model. These examples should perhaps be simplified to help the reader understanding classical/intended use of the time model in its design.

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    simplify

    simplify the example on chronometric to show a classical use of it.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

TIME model: wrong section name

  • Legacy Issue Number: 17342
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    problem:

    Section 9.2.4.5.2 is named "The timeEvent Package". It should be named "The TimedEvent Package"

    proposed resolution:

    rename section 9.2.4.5.2 as "The TimedEvent Package"

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept proposal

    rename section 9.2.4.5.2 as "The TimedEvent Package"

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Typos issues in GQAM

  • Key: MARTE12_-5
  • Legacy Issue Number: 18547
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Diagram shown in 15.7 contains a set of inconsistencies:

    • Multiplicity of GaWorkloadEvent::cause is 1 and not [0..1]
    • Change GaWorkloadEvent::timeEvent: timeEvent into “GaWorkloadEvent::timeEvent: TimeEvent”
    • Multiplicity of the GaScenario::cause property is [1..*]. This multiplicity shall be shown on the diagram.
    • Type of GaScenario::timing should be GaTimedObs instead of GaTimingOberver that does not exist anymore.
    • The association between GaWorkloadEvent and TimeEvent should be removed.

    p. 300, in the attributes section of the “15.3.2.2 GaAnalysisContext”, ref to B.3.3.12 should be B.3.3.13.

    p. 309, as denoted in the diagram shown in Figure 15.7, “effect:GaScenario [1]” should be listed in the attributes section and not in the list of associations.

  • Reported: MARTE 1.1 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Apply proposed changes

    Apply proposed changes

  • Updated: Wed, 19 Dec 2018 16:37 GMT

MARTE: VSL short form for NFP_Real subtypes

  • Legacy Issue Number: 18249
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are numerous examples in the MARTE spec that show the use of tuple value expressions of the form (v, u), where v is the value and u is the unit (e.g., (50, ms)) to specify the value of a subtype of NFP_Real (e.g., NFP_Duration, NFP_Weight, etc.). However, based on how tuple expressions work, this is not valid, since, without additional information, the parser cannot know which attributes are being assigned these two values. Note that subtypes of NFP_Real can have many attributes (e.g., NFP_Duration has 11 attributes) and most of them have at least two Real-type attributes. Based on that, in an expression such as (50, ms), it is not possible to determine which attribute is being assigned the value 50 (e.g., in case of NFP_Duration, it could be either the "value" attribute, the "precision" attribute, the "worst" attribute, or the "best" attribute).

    VSL does allow label-less expressions of this type, but, that can only work if the list of values follows the order in which the attributes appear (which, actually, is not quite clear from the spec), and if the use of the default or null literals is used for entries that are not assigned. For example, for an NFP duration of 50 milliseconds, the proper lable-less expression looks like it should be: (null, null, null,null, null, 50, ms, null, null, null, null), or, alternatively (-, -, -, -, -, 50, ms, -, -, -, -). Clearly, this is far too cumbersome for practical application.

    One possible solution is to have VSL recognize the special and most common by far case of subtypes of NFP_Real, allowing a short form in cases where only the value and unit need to be specified (leaving the other attribute values to default). This short form would, naturally, be the (v, u) form. That would make the common form currently used in the spec valid.

  • Reported: MARTE 1.0 — Tue, 6 Nov 2012 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Resolved

    The resolution follows the proposal described in the last paragraph of the issue summary. An additional item is added in subclause B.3.3.11 Tuples/Disambiguating rules, to mention this short form in the case where expected types are NFP Types. An additional item is also added to make more explicit the rules for positional tuples (which is mentioned in the issue description as well).

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified

  • Legacy Issue Number: 14915
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    UML introduce deployment concepts. MARTE introduces a notion of allocation that seem to encompass deployment-related notions (as stated in the specification). How these concepts relate to analysis attributes is left undefined in the specification at the moment. Depending on the examples one can have a look at, MARTE allocations and UML deployments seem to be used in a similar way (see Section 16.3.3 and Section 17.4). However, nothing is formally stated. Clarify whether MARTE allocations / UML deployment have the same semantics w.r.t. analysis, or not. And, if possible, make the connection with the related issue on host stereotype properties.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Closed no change

    There is already a short discussion on the relationship between MARTE allocation and UML deployment in the specification. The issuer wanted to go more by extending the Deployment metaclass. This seems to restrict a bit the usage of the allocation stereotype and poses compatibility problems with SysML.
    This issue needs more discussion to be addressed properly and may involve changes in the specification that are going outside the scope of a revision task force. It may be included in a future major revision of the standard.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Missing constraint between scheduler and scheduling parameters

  • Legacy Issue Number: 14610
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the GRM domain model (Figure 10.11) and GRM profile (Figure 10.16), there should be a constraint that enforce consistency between scheduling parameters and the related scheduler (e.g. a task brokered by an HPF scheduler cannot have anything else than a priority - integer - as a scheduling parameter).

  • Reported: MARTE 1.0 — Mon, 2 Nov 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Resolved

    Discussion:
    The nature of a scheduler is described by mean of its corresponding Scheduling Policy. It is this policy the one that has to be compatible with the scheduling parameters of the schedulable resources linked to the respective scheduler.

    This requires a brief comment in the description of the scheduling package and specific constraints in the description of the schedulable resource element in the explanation of the semantic of the domain model in appendix F and the description of the SchedulableResource stereotype.

    The same need for compatibility exist between the Scheduling Policy of a scheduler and the ProtectProtocolKind of the MutualExclussionProtocol of the MutualExclusionResources associated to the scheduler. Also between that ProtectProtocolKind and the corresponding ProtectionParameters of the MutualExclusionResources

    Summary:
    So the need for these details in the consistency of models will be pointed out in the description of the scheduling package and specific constraints will be inserted in the description of the schedulable resource element; both, in the explanation of the semantic of the domain model in appendix F and in the description of the SchedulableResource stereotype.
    Also the definition of MutualExclusionResources indicates this constraints but a precise consistency table needs to be provided.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

NfpConstraint stereotype: rename property mode to modes

  • Key: MARTE12_-3
  • Legacy Issue Number: 14428
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The property mode of the stereotype NfpCinstaint has a multiplicity [0..*]. To reflect that I propose to rename this latter mode to modes.

  • Reported: MARTE 1.0 — Mon, 21 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Closed No Change

    Although there are no rules for naming association ends, it seems that UML uses singular names for all association ends (independently of the role multiplicity). So, we should try to keep the same naming convention in MARTE.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Cannot precisely allocate an application to an execution platform described as a series of composite structures.

  • Legacy Issue Number: 13842
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Title: Cannot precisely allocate an application to an execution platform described as a series of composite structures. Description : Consider an execution platform : a rack composed of 3 boards, each boards has a general-purpose processor and an accelerator. The rack and the board are structured classes defined with composite structure diagrams. The pseudo-code below provides an informal description of the platform: Rack

    { board: Board [3] }

    Board

    { gpp: GPP accelerator: FPGA }

    GPP

    {...} FPGA {...}

    How to precisely address the accelerator on the second board of the rack and allocate application elements on it ? The current allocation mechanism allows one to allocate an application on gpp property of the Board class but does not express that the second board is specifically designated.

  • Reported: MARTE 1.0b2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Closed No Change

    In order to achieve this purpose, let’s create istancespecification of the Rack and the boards. Let’s call them respectively rack1, board1, board2 and board3 and define rack1.board[0] = board1, rack1.board[1] = board2 and rack1.board[2] = board3. You can also define more precisely the Board instance specifications creating instance specifications of the gpp and accelerator. Then you can address the precisely each created instance specification in the allocation description.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Introduce new chapter in section 6.4

  • Legacy Issue Number: 12223
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    It would be interested to introduce in the section 6.4 a chapter to explain the diferent design patterns adopted within the specification to use the UML extenssion mechanisms.

  • Reported: MARTE 1.0b1 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Closed; Out Of Scope — MARTE 1.2
  • Disposition Summary:

    Out of Scope

    Patterns used within MARTE to design its UML extensions is not specific to its domain but are indeed generic design pattern related to UML profiling and should be define in one other document than MARTE itself. The resolution of this issue is then considered as being out of the scope of the MARTE specification itself.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Runtimes may have multiple stacks

  • Legacy Issue Number: 11845
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Runtimes may have multiple stacks. How to reference a specific stack size (e.g., primary or secondary) in SRM? It seems to miss a concept.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    This is already possible

    This is already possible to describe multiple stacks because the multiplicty of the staskSizeElement attribute is unlimited (concurrentResource stereotype). It seems that there is a need to describe more precisely several stacks: primiary stack, secondary stack ... One solution leads to describe an explicit "Stack" stereotype. Such solution deeply modifies the SRM chapter.
    This kind of modification is out of the scope of revision task force and should be part of extension of MARTE and included in a request for proposal for a major new version of the specification.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

GRM:Support for Time table driven schedules

  • Legacy Issue Number: 15292
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    MARTE, formal/2009-11-02, GRM chapter, pag 96-97, enhancement

    GRM:Support for Time table driven schedules.

    Having the opaque expression attribute "schedule" in the Scheduler in GRM lead to a very open way of expressing fixed schedules or non-traditional scheduling policies. This is the case of time triggered sets of tasks in particular, but also of any form of table driven schedule. Following a general approach but formalizing the way of expressing schedules as a set of labeled timed windows would make the exchange of information between strict time triggered platforms design intent and its corresponding analysis models easier and in a standardized way.

    An alternative to study may be formalizing the attribute “schedule” of a scheduler to include at least the frame_cycle_time, and the list of “windows” or “time_slots” to be managed as schedulable resources. To do this the easiest way may be to make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler.

  • Reported: MARTE 1.0 — Sun, 27 Jun 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The current structure grants the designer the capacity of describing the schedule to use
    by means of an opaque expression, and the scheduling parameters for the table driven
    policy in the way of an open format string. In order to facilitate the description of more
    precise and standardized schedules, a concrete format for these types has been
    proposed.
    The necessary attributes are presented. For the scheduler the attribute “schedule” will
    be formalized to include at least the frame_cycle_time, and the list of “windows” or
    “time_slots” for the partitions, for doing this there are two alternatives (a) make them part
    of a list inside the schedule indexed by a key that match the scheduling parameters field
    of the schedulable resources that are attached to the scheduler, or (b) compose the list
    by considering the allocated schedulable resources with their corresponding
    schedulingParameters, changing the current type string used for the TableEntry field into
    the necessary time_slot data type tuple.
    Alternative (a) is easier to set into the standard and the models are easier to check for
    consistency, hence is the one proposed. It comprises the formalization of the opaque
    expression used for the attribute “schedule” into a structure like the one shown in the
    next figure:

  • Updated: Wed, 14 Oct 2015 04:55 GMT

stereotype GRM::SchedulableResource should have an attribute describing its activation parameters

  • Key: MARTE_-66
  • Legacy Issue Number: 13655
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    The stereotype GRM::SchedulableResource should have an attribute describing its activation parameters (arrival pattern and parameters). This is useful in multi-rate systems, where, in addition to the activations defined at application level (activation events triggering action/event chains), OS tasks/threads can be defined with a given activation rate. For instance, almost all automotive systems are multi-rate systems. Even if the functional application appears as a single rate system, multiplexing mechanisms both in the communication or in data sampling mechanisms can induce to more complicated timing behaviors, which are a characteristics of multi-rate systems.

  • Reported: MARTE 1.0b2 — Tue, 3 Mar 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The activation pattern is a characteristic of the application, not of the platform. In
    fact it is usually different in each execution scenario. The concept of task, as
    used in languages and formalisms is for all of them a way to create an
    application, not a description of the platform. A modeling element that may serve
    for this purpose would be much closer in meaning to an RTUnit than to a
    SchedulableReource. So the extension requested is not in the scope of GRM. A
    task is clearly a design modeling element and if not in HLAM it may probably fit in
    SRM.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

MARTE/section 7.2.1/ "No Metamodel root" bug

  • Key: MARTE_-65
  • Legacy Issue Number: 13086
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    The metamodel can not be executed/implemented since their is no root
    element in the metamodel. It would be useful to introduce the
    packageableElement, Model (A model owns * PackageableElements). This
    addition has several consequences on other parts of the metamodel in
    order for this latter to be used for instance to create MARTE model
    conforms to the MARTE metamodel.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Actually there is a root element it is “ModeElement”, and it has the “ownedElement”
    reflective relationship so all elements in MARTE may be (hopefully) derived from and
    contained in it. I suggest Close No Change.
    Disposition: Closed, no change

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Example in Figure 10.21 makes use of directed arrows

  • Key: MARTE_-64
  • Legacy Issue Number: 12411
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The example in Figure 10.21 makes use of directed arrows to represent connectors in a composite structure. Moreover, it seems that the element inside the composite structure look more like classes than parts.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The example is not a composite structure; the caption text of the figure may have
    mislead the reader. It shows just a class diagram with dependencies among
    them.
    Resolution:
    Closed the issue with no change to the specification

  • Updated: Wed, 11 Mar 2015 01:53 GMT

align the notation section of 11.3.2.7 to the profile diagram.

  • Key: MARTE_-63
  • Legacy Issue Number: 12286
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The notation section of 11.3.2.7 makes use of stereotypes that are inconsistent with the profile diagram. Proposed resolution: align the notation section of 11.3.2.7 to the profile diagram.

  • Reported: MARTE 1.0b1 — Wed, 19 Mar 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue was related to MARTE beta 1 and is no longer relevant to MARTE v1.
    Disposition: Closed, no change

  • Updated: Wed, 11 Mar 2015 01:53 GMT

associations between Instance and ModelElement (subclasses)

  • Key: MARTE_-62
  • Legacy Issue Number: 12234
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    On fig. 7.6 three association between Instance and ModelElement (subclasses) have properties subsetted "type", but the "type" property only appear between Instance and Classifier (not ModelElement) fig. 7.3.

  • Reported: MARTE 1.0b1 — Mon, 18 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    THIS IS A slightly OLD ISSUE, THE FIGURE NUMBERS HAD CHANGE SINCE
    LAST VERSIONS. AND THIS HAS BEEN ALREADY SOLVED BY SUBTYPING
    THE ROLE IN ONE OF THE LAST VERSIONS. SEE FIGURE 7.7 We can close with
    no change the issue.
    Disposition: Closed, no change

  • Updated: Wed, 11 Mar 2015 01:53 GMT

MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part

  • Key: MARTE_-61
  • Legacy Issue Number: 11856
  • Status: closed  
  • Source: ESEO ( Jerome Delatour)
  • Summary:

    A simplification of GRM should be envisaged.
    GRM defines too many detailled concepts (for instance the Scheduler which seems more
    appropriate in the SRM package), these concepts could be defined in
    SRM or HRM package or even in SAM package.

    The way to define different types of services need to be aligned between GRM, SRM
    and HRM.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    With respect to the status of the FTF, the resolution of this issue would need too
    much time to be resolved in an efficient and satisfying form. So, I (Sébastien
    Gérard from CEA LIST) propose to defer it.
    Disposition: Deferred This issue has been resolved by resolutions to issues 11411 and 11412. A brief
    modification is necessary in the introduction of GRM to comprise it as generic for
    also analysis and design. A brief text is to be added to the Introduction of GRM to emphasize its a role of
    foundation for the analysis packages (GQAM, SAM and PAM) and the DRM
    (SRM and HRM).

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Section: 10/3

  • Key: MARTE_-60
  • Legacy Issue Number: 11621
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The GRM::Resource stereotype (and its specializations in GRM, SRM, HRM, such as HRM::HwProcessor) extends the following UML metaclasses: Classifier, Property, InstanceSpecification, Lifeline, ConnectableElement. When modeling resources within a composite structure, one has the choice to : 1) apply the stereotype on a UML::Classifier, and then type the parts by this classifier 2) directly apply the stereotype on parts (UML::Property) 3) both 1) and 2) In the case of 3), the relationships between the stereotype attributes defined on the classifer and those defined on the parts need to be clarified. A possible answer would be to formulate the following: "a stereotype applied to an instance (part, instance specification, lifeline, connectable element) allows one to assign values that are instance-specific and which overrive the default values of the stereotype applied to the class".

  • Reported: MARTE 1.0b1 — Wed, 17 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

The concept of System in Annex A.2 maps to a SysML concept

  • Legacy Issue Number: 14901
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The concept of System in Annex A.2 maps to a concept not defined in the MARTE specification (a SysML concept). However the MARTE profile does not import the SysML profile.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    An AADL system represents an assembly of interacting application software,
    execution platform, and system components.
    The chosen mapping shall not only be semantically correct, but shall also have
    an intuitive name.
    MARTE doesn’t address such a generic aspect, and it would not make sense to
    add such a concept to MARTE.
    UML generic concept “StructuredClasses class” could be use, but this concept
    has already been used to represent AADL data. As mappings have always to be
    bijectiv, another representation has to be found.
    UML “subsystem” concept could be used to represent an “AADL system”, this
    mapping is semantically correct, but the name is confusing.
    The best solution is to use the SysML “block” concept: the mapping is
    semantically correct and the name is sufficiently different to avoid confusion.
    This solution needs to import the SysML profile. A prerequisite will be added in
    the introduction précising that the SysML profile needs to be importing when
    using MARTE to design AADL applications in order to fully address the MARTE
    to AADL mapping.

  • Updated: Sun, 8 Mar 2015 17:59 GMT

There should be a section to describe the different possible notations for the allocation

  • Key: MARTE_-59
  • Legacy Issue Number: 13821
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    There should be a section to describe the different possible notations for the allocation

  • Reported: MARTE 1.0b2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13126 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Typos in example Figures 17.15/16/17/27

  • Key: MARTE_-56
  • Legacy Issue Number: 13714
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    These example figures contain a few stereotypes and attributes that were defined in earlier drafts of the profile and need to be updated. These are similar to typos. Examples:

    (a) Fig 17.15 the stereotype paRequestEventStream has been replaced by gaWorkloadEvent, and attributes closedPopulation and closedExeternalDelay are replaced by a closed pattern,

    (b) respTime should be respT, probability should be prob, repetition shold be rep

    (c) In Figure 17.16 the contextValues attribute must be upgraded

    (d) In 17.17 the contextValues attribute must be upgraded, and gaReleaseStep is replaced by gaRelStep, gaAcquireStep by gaAcqStep, repetition by rep.

    (e) in 17.27 there are three instances of probability --> prob

  • Reported: MARTE 1.0b2 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    AnalysisContext changes are part of issue 13724.
    (a) Fig 17.15 the stereotype paRequestEventStream has been replaced by
    gaWorkloadEvent, and attributes closedPopulation and closedExeternalDelay
    are replaced by a closed pattern,
    (b) respTime should be respT, probability should be prob, repetition should be
    rep
    (c) In 17.17 gaReleaseStep is replaced by GaRelStep, gaAcquireStep by
    GaAcqStep, repetition by rep.
    (d) in Fig 17.24, PaProcess is replaced by PaRunTInstance
    (e) in Fig 17.26, remove $ signs on variable names
    (f) in 17.27 there are three instances of probability --> prob

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Marte: more complete definition of contextParams in GaAnalysisContext (ch 15)

  • Key: MARTE_-58
  • Legacy Issue Number: 13724
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    The attribute contextParams in the domain model (Fig 15.2) is a collection of VSL::Expression::Variable (Variable as defined in Sec B.3.3.12). However in the profile definition of Sec 15.3.2.2 it is just defined as a set of strings.

    To make it consistent with the domain model, and useful for defining parameters of contexts, the strings should be defined to conform to the concrete syntax for variable calls or declarations of Sec B.3.3.12.

    Three of the examples of Sec 17.4 use these attributes, in a form that is no longer in the document, and need to be updated (see Figs 17.16, 17.17, 17.21, 17.27)

  • Reported: MARTE 1.0b2 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    To make it consistent with the domain model, and useful for defining parameters
    of contexts, the strings should be defined to conform to the concrete syntax for
    variable calls or declarations of Sec B.3.3.12.
    Three of the examples of Sec 17.4 use these attributes, in a form that is no
    longer in the document, and need to be updated (see Figs 17.16, 17.17, 17.21,
    17.27)

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Marte: consistent capitalization of stereotypes in Sec 17.4

  • Key: MARTE_-57
  • Legacy Issue Number: 13723
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    The capitalization of stereotypes in the example in Sec 17.4 needs to be made consistent with the definitions in Sec 17.3. this afffects mostly figures, a few instances in the text also.

  • Reported: MARTE 1.0b2 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The correct prefix is Pa or Ga, instead of pa or ga.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In HRM, the structure of the subprofile is ill formed

  • Key: MARTE_-55
  • Legacy Issue Number: 13534
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In HRM, the structure of the subprofile is ill formed. The HwGeneral package should be direct sub package of the HRM profile and it shold be imported by both HwLogical and HwPhysical sub packages of HRM. And all sub packages of the HRM profile should be sub profiles in order to improve its scalability.

  • Reported: MARTE 1.0b2 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The profile architecture of the HRM profile has been updated to factorize the
    HwGeneral sub profile in order it can be shared by both HwLogical and
    HwPhysical subprofiles.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Missing attributes

  • Key: MARTE_-54
  • Legacy Issue Number: 13445
  • Status: closed  
  • Source: university of cantabria ( pablo peñil del campo)
  • Summary:

    In page 91 (GRM chapter) of MARTE profile (beta_2)a figure appear with the <<CommunicationMedia>> attributes. But in the corresponding annex those attributes don't appear (just elementSize appears). Those "disappeared" attributtes are included in <<CommunicationEndPoint>> attributes.

  • Reported: MARTE 1.0b2 — Thu, 5 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Move from section F.4.6 to F.4.7 the additional attributes stated in resolution to 11835.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)??

  • Key: MARTE_-53
  • Legacy Issue Number: 13424
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)??

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.16, namespace must be replaced by namespace ::= ['.' namespace]

  • Key: MARTE_-52
  • Legacy Issue Number: 13423
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.16, namespace must be replaced by (or removed because the rule already exists): namespace ::= <body-text> ['.' namespace]

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated.

  • Key: MARTE_-51
  • Legacy Issue Number: 13422
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.14, first rule, parentheses are not optional

  • Key: MARTE_-48
  • Legacy Issue Number: 13419
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.14, first rule, parentheses are not optional… (already solved in other Issue number!).

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Variable call expression and property call expression are ambiguous

  • Key: MARTE_-47
  • Legacy Issue Number: 13418
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    We should define a context for property call expression, or define some keywords for making difference.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration.

  • Key: MARTE_-46
  • Legacy Issue Number: 13417
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required.

  • Key: MARTE_-50
  • Legacy Issue Number: 13421
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.13, namespace must be replaced

  • Key: MARTE_-49
  • Legacy Issue Number: 13420
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.13, namespace must be replaced by: <namespace> ::= <body-text> ['.' <namespace>]

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid).

  • Key: MARTE_-43
  • Legacy Issue Number: 13414
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid).

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.7, the first rule allows defining bounds of different type, This should be forbidden

  • Key: MARTE_-42
  • Legacy Issue Number: 13413
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.7, the first rule allows defining bounds of different type. This should be forbidden. The first two rules must be changed by: <interval> ::= ('[' | ']') <interval-bounds> ('[' | ']') <interval-bounds> ::= <number-interval-bound> '..' <number-interval-bound> | <datetime-interval-bound> '..' < datetime -interval-bound> | <tuple-interval-bound> '..' <tuple-interval-bound> | <choiceinterval-bound> '..' <tuple-interval-bound> | <expression-interval-bound> '..' <tuple-interval-bound>

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.7, literal-interval-bound should be separated in two interval bounds

  • Key: MARTE_-41
  • Legacy Issue Number: 13412
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In B.3.3.7, literal-interval-bound should be separated in two interval bounds: number-interval-bound and a datetime-interval-bound.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr.

  • Key: MARTE_-45
  • Legacy Issue Number: 13416
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Properties of TupleType and ChoiceType should be constrained to be DataType only.

  • Key: MARTE_-44
  • Legacy Issue Number: 13415
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    Properties of TupleType and ChoiceType should be constrained to be DataType only.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Section B.3.3.3 is duplicated.

  • Key: MARTE_-39
  • Legacy Issue Number: 13410
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    Section B.3.3.3 is duplicated.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.12 (Variables, p 416), the text is not aligned with the grammar

  • Key: MARTE_-38
  • Legacy Issue Number: 13409
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    A variables begins by a "direction" and not by a "$" symbol. Yet, the direction is optional, and so a default value must be defined.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412

  • Key: MARTE_-37
  • Legacy Issue Number: 13408
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Since Issues 13408 to 13424 are all related to mistakes in the grammar of VSL
    (Annex B), we merge them all in this issue resolution. For convenience, we copy
    below the formulation of each issue.
    This resolution proposes to fix all these issues as proposed by the Issue source.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.4., the DateTimeLiteral rule can be optimized

  • Key: MARTE_-40
  • Legacy Issue Number: 13411
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In Section B.3.3.4., the DateTimeLiteral rule can be optimized by removing the first alternative and letting optional date-string in the third alternative.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

FlowPort stereotype

  • Key: MARTE_-36
  • Legacy Issue Number: 13407
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    Concerning the FlowPort stereotype, there are some differences between the definition given in SysML and the definition given in MARTE. The differences are: - isConjugated : In MARTE, the multiplicity of this property is [1], whereas in SysML it is [0..1] - direction : In MARTE, the multiplicity of this property is [0..1], whereas in SysML it is [1]. Moreover, a difference also appear concerning the FlowSpecification stereotype: - In MARTE, FlowSpecification has a direction:DirectionKind[0..1] property, whereas in SysML, this property does not exist. Is it just an alignment issue, or is there any fundamental reason motivating these differences?

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    see ptc/2009-05-12 pages 348 - 351

  • Updated: Sat, 7 Mar 2015 21:28 GMT

The notion of value is missing the NFP_Declaration domain model Description

  • Key: MARTE_-35
  • Legacy Issue Number: 13400
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The current NFP_Declaration package of the NFP domain model introduces the notion of NFP and NFPType. However, it is missing a relation between these concepts of non-functional property and the concepts of physical quantity and value (expressed in SysML by Value Property / Value Type). One can consider a non-functional property as a kind of physical quantity. These links need to be explicitly stated, which will foster a future alignment with SysML concepts. Proposed resolution: Introduce the meta-classes: ValuePropery and ValueType in NFP_Declaration package and create inheritance links from ValueProperty to NFP and ValueType to NFPType. No impact on the current UML profile.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Proceed as suggested in the issue summary:
    • Introduce two meta-classes ValuePropery and ValueType in the NFP_Declaration
    package,
    • Create an inheritance link from ValueProperty to NFP and ValueType to
    NFP_Type,
    • Document the meta-classes in Annex F.
    The introduction of the ValueProperty and ValueType metaclasses will provide
    intermediate definitions that bridge the notions of non-functional property (NFP)
    and more general definitions of value and quantity. It is also an opportunity to
    reference SysML notions of ValueProperty / ValueType as related concepts.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

ARINC 653 Annex of MARTE

  • Key: MARTE_-34
  • Legacy Issue Number: 13349
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    The ARINC 653 Annex of MARTE is not strictly compliant with the ARINC 653 resolution: Update the API with the ARINC 653 Ada API

  • Reported: MARTE 1.0b2 — Tue, 27 Jan 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    New ARINC 653 API model has been provided and complementary text to
    explain ARINC 653 Service API

  • Updated: Sat, 7 Mar 2015 21:28 GMT

The dependency between NFP and VSL is not necessary

  • Key: MARTE_-33
  • Legacy Issue Number: 13341
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Currently the domain view and the UML representation of NFP rely on VSL constructs which specialize UML ones (ValueSpecification, Datatype). This dependency is a limitation to the modularity of MARTE (e.g. one might be willing to use NFP with another expression language). Proposed resolution: 1) In the domain model, replace references to MARTE::VSL::ValueSpecification by UML::ValueSpecification (starting by page 35). 2) In the domain model, replace references to MARTE::VSL::TupleType by UML::DataType (starting by page 38) 3) In the UML representation, remove the generalization link between TupleType and NFPType (starting by page 38) 4) In the chapter overview, remove the dependency link between NFP and VSL

  • Reported: MARTE 1.0b2 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The dependency of Domain Models on the VSL Domain Model does not affect
    the modularity of MARTE. On contrast, having a cohesive integration of Value
    Specification concepts from VSL with the other chapters is a must regarding the
    comprehensibility of MARTE. The only design constraint in MARTE was to do
    VSL independent of other MARTE specific chapter, because we had in mind to
    use VSL together with other profiles (e.g., SysML). This level of dependency has
    been achieved as VSL doesn’t import other MARTE packages.
    Note that there are many MARTE chapters that reuse VSL concepts:
    CoreElements, Time, RSM, and having also NFP importing VSL is not a real
    problem.
    For these reasons, we propose to close this issue without change.
    Disposition: Closed No Change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines

  • Key: MARTE_-32
  • Legacy Issue Number: 13126
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    From my point of view using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines in its "Domain view", §11.2, p117. According to this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where applications and plateforms are considered to be independant. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62, unchanged in v2.2 beta 1) Then, I suggest to change the UML representation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. It's can be achieved, for instance, by the specialization of the Classifier metaclass, instead of the Dependency metaclass

  • Reported: MARTE 1.0b2 — Wed, 26 Nov 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Allocation is meant to be very general. Application elements are allocated to an
    execution platform (software or hardware), functionality is allocated to processes,
    processes are allocated to a virtual machine, and resources may be allocated to
    resource pools, just for some examples. What allocation is doing in these cases
    is imposing structure on a less structured system.
    For generality, alternative allocations should be possible. If only a single
    allocation is possible then the potential of MDE is thrown away. In particular,
    allocation does not always imply a dependency. Moreover, when a dependency
    is created, the client of this dependency is modified to refer to the dependency.
    This can be a problem when allocating read_only elements.
    The metaclasses Relationship or DirectedRelationship fit better. However,
    these metaclasses are abstract and there is currently no concrete specialization
    in UML that would not induced a specific semantics compatible with the broad
    acception of allocation intended in MARTE. Consequently, the issue should be solved in UML by introducing a new metaclass. It should be discussed with the
    SysML community given the relationship explicitly stated in the MARTE
    specification between the MARTE allocation and its SysML counterpart.
    However, to have an short term solution, we have decided to propose something
    that is not entirely satisfactory but would work with read_only elements, be
    usable in very general cases, require few tool adaptations and would have a
    minimal impact on SysML, with which we want to maintain compatibilities.
    This is done by adding the stereotype Assign that extends the metaclass
    Comment, while preserving the stereotype Allocate to maintain compatibility with
    the current SysML approach. The Assign stereotype is an alternative UML
    representation of the Allocation metaclass, defined in the domain model, but
    without the underlying semantics of the Abstraction metaclass. Note that the
    optional body property of the Comment meta-class can be used to provide the
    justification of the assignment

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In GCM, domain model and profile do not match in ways that are not fully documented

  • Key: MARTE_-31
  • Legacy Issue Number: 13125
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In GCM, domain model and profile does not match in ways that are not fully documented. Although this may be acceptable when domain concepts map directly to UML concepts (no stereotype assigned), or when some syntactic sugar are added at UML profile level. However, it is not clear why the attributes: "direction: DirectionKind" and "kind: BFeatureKind" appear in some domain entities (FlowProperty) and in others not (FlowSpecification, ServiceSpecification, ServiceFeature, SignalSpecificatio, SignalFeature), while in the Profile they are used in all these entities.

  • Reported: MARTE 1.0b2 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue is related to alignment problems between the UML view and the domain view
    of the GCM (as well as issues 12867 and 13124, which are set to duplicate/merge
    because they are treated here).
    Issues 11820 and 13407 are related to problems with the UML view of the GCM, and
    they have been treated before this issue 13125. So, the revised text of this resolution is
    made to be consistent with resolutions 11820 and 13407.
    However, note that the revised text proposed here does not result in a “one to one”
    alignment. Indeed, let's remain that the domain view is intended to describe the
    specification of the specific modeling language, whereas the UML view (the UML
    profile itself) is a real design model of the domain model. They are not to be considered
    at the level of abstraction, and then their concepts do not have to map one-per-one. The
    intend of the GCM domain model, and in fact of all other domain models denoted in the
    AMRTE specification, are proposed to depict what is essential for the understanding of
    the GCM, and its underlying causality model (described in section 12.2.2 of the revised
    text).

  • Updated: Sat, 7 Mar 2015 21:28 GMT

GCM Classes Description in Annex should be revised:

  • Key: MARTE_-30
  • Legacy Issue Number: 13124
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    GCM Classes Description in Annex should be revised: 1) BFeatureSpecification has not been included, although it exists in the Metamodel. 2) The "BfeatureAction" name is used in place of "BFeatureKind". 3) Descriptions of MessagePort attributes are not sufficiently detailed. While the Stereotype description section provides some key semantic description, it is not provided in Domain Class description. Particularly, this is the case for the attribute: "isConjugated". 4)SignalPort does not exist anymore in the domain model, but it is included in the Class Description.

  • Reported: MARTE 1.0b2 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13125 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/section 12.2/ "No assemblyConnectorEnd in the Metamodel" bug

  • Key: MARTE_-29
  • Legacy Issue Number: 13089
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    Assembly connector End can not be manipulated in the metamodel. Wheras
    it is important to have the relashionship between the Assembly connector
    end and the port and from the Assembly Connector to the Port.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The resolution to this issue implies to introduce a ConnectorEnd class in the domain model (cf.
    #1). To mimic the structure of the UML2 metamodel, the ConnectorEnd domain class must have
    a generalization relationship with the MultiplicityElement domain class. MultiplicityElement is only
    defined in the Marte::RSM::Shape (which is basically a uml MultiplicityElement with a Shape). So,
    issue 13089 hides other fundamental issues: MultiplicityElement should be defined in
    Marte::CoreElements::Foundations #2 (and extended through package merge in
    Marte::RSM::Shape #3. Note that in the foundations, Property should also have a generalization
    relationship with MultiplicityElement #4

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/annexe E/ "No MultiplicityElement owner in the metamodel" bug

  • Key: MARTE_-28
  • Legacy Issue Number: 13087
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    With the MARTE metamodel it can not be specified to which element a
    MultiplicityElement refers. In this context, the multiplicityElement can
    not be attached to any element and thus cannot be used.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    MultiplicityElement has been modified in the context of the issue 13089.
    Consequently, this issue becomes no more valid.
    Disposition: See issue 13089 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/RSM/repetition index port missing

  • Key: MARTE_-27
  • Legacy Issue Number: 13085
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    In the RSM chapter, the repetition index should be visible by a shaped
    component so that its behavior can depend on this index. A possible
    solution could be a tagged value referencing a port of this component.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/RSM/generalization of the reshape stereotype

  • Key: MARTE_-26
  • Legacy Issue Number: 13084
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    To be conform to the metamodel and extend the applicability of the
    reshape stereotype, it should be possible to apply it to other kinds or
    links than just allocations or connectors.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    It is not clear if that would be really useful. If some need appears in the future, reraise
    the issue.
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

inconsistencies in the HLAM subprofile

  • Key: MARTE_-25
  • Legacy Issue Number: 12954
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    Several inconsistencies in the HLAM subprofile: 1- In figure 3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. Later in section 13.3.2.8 is shown again as <<RtFeature>> 2- In section 13.3.2.8 the stereotype <<RtFeature>> is said to extend the UML Behavior element; however in section 3.10 this extension is not shown. 3- Figure 3.11 does not show all the attributes of the <<RtAction>> stereotype. 4- The use of the stereotype <<RtBehavior>> is not clear. An example in 13.4 would be of great help.

  • Reported: MARTE 1.0b2 — Mon, 13 Oct 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11838 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Figure 13.1 (pg 149)

  • Key: MARTE_-24
  • Legacy Issue Number: 12869
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Figure 13.1 (pg 149) the dependency of CoreElements is repeated twice. Revise the text: “the HLAM package of MARTE is depending of both GRM and CoreElements packages, but also on the CoreElements package” - figure 13.13 should be removed(since RTConnector has been eliminated) - The references to figures in the example seem wrong.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    One of the related dependencies in Figure 13.1 should be to the package
    MARTE::GeneralComponentModel. However, when referring to the HLAM
    element that depends on this package, we realized that the concrete domain
    model element from MARTE::GeneralComponentModel used in MARTE::HLAM,
    “ComponentService”, it doesn’t exist anymore (see Fig. 13.5, page 152,).
    Hence, this resolution proposes to remove one of the dependencies with
    MARTE::CoreElements in Figure 13.1, and remove all the references to the
    ComponentService domain model element in HLAM.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Section: Annex D

  • Key: MARTE_-23
  • Legacy Issue Number: 12868
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    D.2.2 (ArrivalPattern), it says sporadic: Aperiodic, should it be sporadic:Sporadic (pg 452). - In BurstPattern (D.2.6)minEventInterval is repeted twice. The difinitions in this class should be more explicit to better understand it. Shouldnt it be minEventInterval: NFP_Duration [0..1] the minimum interval between two occurrences OF a burst? it says within a burst. Isn't it what it is said by minInterarrival ?

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue points two mistakes and additionally requests for some description
    enhancements. This resolution proposes to revise the text as described below

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Figure12.4 is wrong

  • Key: MARTE_-22
  • Legacy Issue Number: 12867
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Editorial Issues: - Figure12.4 is wrong, association signal in the SignalSpecification should be of type SignalFeature instead of ServiceFeature. - In annex F there are many incomplete definitions, see F.6.16, F.6.18, F.6.19). F.6.15 and F.6.20 are not mapped, is this correct? - Pg 137 it should say Figure 12.7 (it says 12.17) - Pg 144 it should say Figure 12.15 (it says 12.5), in pg 145 the same for Figure 12.6

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13125 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Section: GQAM-SAM-PAM

  • Key: MARTE_-21
  • Legacy Issue Number: 12865
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    The attributes CommTxOvh and CommRcvOvh in a GQAM:ExecutionHost (F.10.8) limit comunication of a host to only one network/protocol. In fact the overhead due to communication maight be very dificultly expressed by simply a duration...

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 21:28 GMT

NFP_Type

  • Key: MARTE_-18
  • Legacy Issue Number: 12862
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    The priority of a FixedPriorityParameter to attach to a SchedulableResource must be of an NFP_Priority type in order to handle it from tools that deal with VSL and parametric descriptions. This is also the case of the priorityCeiling of a MutualExclusionResource. It is convenient to clarified or indicated how to specify the preemption level of the SchedulableResources by means of its scheduling parameters when the StackBasedProtocol is used. If the priority is used for that it should be stated, If an additional parameter is included, then its type should be also an NFP_Type

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    In order to handle them from tools that deal with VSL and parametric descriptions the
    most useful type for priority and ceiling is clearly NFP_Integer, it seems that the use of
    Integer instead has been just a typo, and it is easy to solve with no harmful implications.
    For simplicity on the one hand, and for the co-existence of both protocols in a combined
    EDF-FP platform on the other hand, it is convenient to use the Ceiling attribute to hold
    both, the priorityCeiling and the preemptionLevel of a mutualExclusionResource under
    the priorityCeiling and StackBased protection protocols respectively. Since both may be
    handled with an NFP_Integer type, the restriction already stated in the explanation of the
    ceiling attribute (section 10.3.2.9 page 104) is applicable also.
    This is the case for some other values using integer types in GRM, so a consistent
    modification of them is worth doing.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

concrete syntax

  • Key: MARTE_-17
  • Legacy Issue Number: 12861
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Section 9 proposes some stereotypes to identify clocks and clock constraints. Annex C proposes a non-normative language (CCSL) to describe clock constraints. Even though CCSL is non normative (to give more freedom to tool vendors for implementation), such a constraint language must have some specific characteristics. For instance, it MUST allows description of both synchronous and asynchronous constraints. Hence, the normative part (Section 9) should provide a mechanism to identify the nature (synchronous, asynchronous, mixted) of the constraint even if the concrete syntax remains non-normative and described in Annex C. This would give some kind of consistency between different implementations.

  • Reported: MARTE 1.0b2 — Thu, 25 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The resolution proposes to add three meta-attributes to the stereotype
    ClockConstraint to reflect the domain view (CoincidenceRelation and
    PrecedenceRelation described in Figure 9.5) and identify the nature of the
    constraint.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Figure 16.6: multiplicity

  • Key: MARTE_-20
  • Legacy Issue Number: 12864
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Figure 16.6: multiplicity for the host of a SchedulableResource shoudnt it be 1 - In the example (Figure 16.13), the SchedulableResources associated to SaCommHost, Shouldnt they be CommunicationChannels? - The constraints in 10.3.2.16 (SecondaryScheduler) should be also in its domin concept defined in annex F. - It is not clear the relationship between the clockOverhead of a SaExecutionHost and the TimingResources associated

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Figure 10.11, “The Scheduling Package” expresses that a
    SchedulableResource has at most one host. While a resource could be
    scheduled by two or hosts, management of such distributed scheduling is beyond
    the original intent. Figure 16.6 should be corrected to show the host role to be of
    multiplicity 0..1.

    • We agree that the schedulable entities allocated to the SaCommHost CAN Bus
      should be CommunicationChannels.
    • The SecondaryScheduler is described in F.4.33. The mentioned constraint
      should be added.
    • clockOverhead is only cited as an Attribute of an ExecutionHost and no
      explanation is provided. The purpose of the Attribute should be described.
  • Updated: Sat, 7 Mar 2015 21:28 GMT

definition of ResourceUsage (F.4.27) in annex F

  • Key: MARTE_-19
  • Legacy Issue Number: 12863
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Editorial Issues: - The definition of ResourceUsage (F.4.27) in annex F is apparently confused (copy/paste) with the one of UsageDemand. - The definition of timingRes in F.11.5 is not the correct one - Shouldnt it be SourceKind in Anex F. - In F.4.7 the new attributes of CommunicationMedia have been inserted in CommunicationEndpoint - F.10.3 the generalizations are missing.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Ok for items 1, 2, 4 and 5. Item 3 has no meaning. See following revised text.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

clarify the semantical difference between an UML "Port" and a MARTE "Messag

  • Key: MARTE_-16
  • Legacy Issue Number: 12802
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    In chapter "Generic Component Model", please clarify the semantical difference between an UML "Port" and a MARTE "MessagePort".

  • Reported: MARTE 1.0b2 — Wed, 3 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Clarification in chapter "General Component Model" needed

  • Key: MARTE_-15
  • Legacy Issue Number: 12801
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    In chapter "General Component Model", please clarify the semantical difference between an atomic flow port typed by a Signal and an atomic MessagePort typed by a signal

  • Reported: MARTE 1.0b2 — Wed, 3 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE aligment with SYSML 1.1

  • Key: MARTE_-14
  • Legacy Issue Number: 12799
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    MARTE aligment with SYSML 1.1 SysML has been evolved since the MARTE adoption. MARTE metamodel needs to be align with the SysML metamodel To solve it: check the SysML 1.1 metamodel and MARTE metamodel and align Metamodel / definition according to SysML evolutions

  • Reported: MARTE 1.0b2 — Tue, 2 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This proposal is too general. Moreover, let's notice that there are issues related
    this subject but focus on specific points (e.g., both issues 11871 and 11872) that
    have been resolved and that enable to align MARTE and SysML.
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

check UML 2.2 modifications impacts on MARTE Metamodel and definitions

  • Key: MARTE_-13
  • Legacy Issue Number: 12798
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Aligment of MARTE to UML 2.2 metamodel to solve it: check UML 2.2 modifications impacts on MARTE Metamodel and definitions

  • Reported: MARTE 1.0b2 — Tue, 2 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This is a too much general issue!
    However, I (Sébastien Gérard) am thinking that a priori everything is ok w.r.t. that
    alignment issue, i.e. every MARTE construct should be compatible with the
    UML2.2 metamodel.
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

What about a System Configuration concept having a set of OperationalModes?

  • Key: MARTE_-12
  • Legacy Issue Number: 12797
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    The operationalModes association end from rtUnit to rtBehavior has a multiplicity 0..1. This is not enough to model the OperationalMode as understood by fault-tolerance theory. An rtUnit should be capable to have many operationalModes. In addition, an OperationlMode would be need to be defined at system level too (not rtUnit level only). It seems that a separated stereotype (not rtBehavior as currently) would be necessary for OperationalMode. What about a System Configuration concept having a set of OperationalModes?

  • Reported: MARTE 1.0b2 — Thu, 28 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The concept of Mode (or Operational Mode) is central in embedded systems and
    in dependable embedded systems in particular. Having this concept only as an
    attribute of the RtUnit concept is indeed insufficient to model the behavioural and
    structural aspects of mode sensitive architectures. An operational mode can
    represent different things:

    • An operational system (or subsystem) state that is managed by reconfiguration
      mechanisms (e.g., fault-tolerance management middleware) according to fault
      conditions.
    • A state of system operation with a given level of QoS that can be handled by
      resource management infrastructures (e.g., middleware that assign resources at
      run time according to load demand, timing constraints, or resource usage).
    • A phase of a system operation e.g., starting, stopping, reconfiguring switchers,
      in a supervisory control system of an electric grid.
      We propose to adopt a number of minimum concepts to describe operational
      modes and their dynamics with UML state machines. Please notice that a UML
      state machine may be used “as is” to model operational modes and their
      dynamics. However, the need to unambiguously distinguish modal state
      machines, specifying the kind of above-mentioned macro-states, from other
      standard state machines, motivated us for explicitly describing these concepts in
      the MARTE specification. Furthermore, it seems necessary to characterize
      certain MARTE concepts with “modal” information. For instance, defining which entities are active in a given mode, specifying how entities behave in a mode
      transition, or determining what NFP values are valid in a given mode, all require
      means to refer to the entities proposed in this resolution.
      This resolution proposes to define this set of concepts related to operational
      modes in the “Core Elements” chapter. A number of updates are also proposed
      in other MARTE chapters to refer to the concepts added in “Core Elements”.
  • Updated: Sat, 7 Mar 2015 21:28 GMT

rteConnector concept

  • Key: MARTE_-11
  • Legacy Issue Number: 12796
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    Issue 11835 in the MARTE FTF 1 removed the rteConnector concept from the domain model of HLAM. However, the element (rteConnector) was not removed from the Profile (UML View) part.

  • Reported: MARTE 1.0b2 — Thu, 28 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This resolution proposes to remove Figure 13.13, page 156. The RteConnector
    stereotype doesn’t exist anymore.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Fig 15-7 shows that GaCommStep has the property

  • Key: MARTE_-10
  • Legacy Issue Number: 12780
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    Fig 15-7 shows that GaCommStep has the property "concurRes: SchedulableResource". However; it is not necessary, as far as its parent GaStep already has the same property

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This has already been resolved during the resolution of issue 12778 in a previous
    ballot (the attribute msgSize was also defined unnecessarily) .
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

ordered association "subUsages"

  • Key: MARTE_-9
  • Legacy Issue Number: 12779
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In page 107, ResourceUsage has an ordered association "subUsages", but Fig 10-18 doesn't reflect this feature (ordered). As far as I understand the semantics of the association, the isOrdered meta-attribute is not relevant here.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Add the

    {ordered}

    quality to the subUsages association depicted in Figure 10.18

  • Updated: Sat, 7 Mar 2015 21:28 GMT

property 'msgSize' in figure 15-7

  • Key: MARTE_-8
  • Legacy Issue Number: 12778
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In Fig 15-7, we notice that GaCommStep has the property 'msgSize'. However, this property already exist in its parent Stereotype 'ResourceUsage'. Hence, the property exists twice in GaCommStep. One of them should be removed.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    I t should be removed from CommStep. The property concurRes is also inherited
    from Step and can be removed from CommStep in fig 15.7

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE profile-library interdependency should be revised and enhanced

  • Key: MARTE_-7
  • Legacy Issue Number: 12777
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    MARTE profile-library interdependency should be revised and enhanced to ease implementation. Particularly, the MARTE primitive types packages should be used (imported) by the whole MARTE profile and MARTE Libraries. Currently, this aspect is not clear enough, and some parts use UML primitive types while others MARTE primitive types. In addition, establishing well-defined high level packages would help avoiding circular dependencies. For example, MARTE data types library use NFPs and VSL profiles, but MARTE defines NFPs profile in a high level package called Foundations, which has other internal packages that import the MARTE data types libraries. A better grouping criteria should remove interdependencies when implementing MARTE.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue requires an important restructuring of MARTE. We propose to defer it
    to the RTF
    Disposition: Deferred

  • Updated: Sat, 7 Mar 2015 21:28 GMT

HRM, fig 14-70, the stereotype HwMedia extends UML::Connector

  • Key: MARTE_-6
  • Legacy Issue Number: 12776
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    In HRM, fig 14-70, the stereotype HwMedia extends UML::Connector. This extension is not needed as long as its parent GRM::CommunicationMedia already extends UML::Connector.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Modifications should be done to delete this redundancy (see next proposition of revised text).

  • Updated: Sat, 7 Mar 2015 21:28 GMT

typos in section E.3.2

  • Key: MARTE_-5
  • Legacy Issue Number: 12588
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Typo issues: the links to pages are not good for example: defaultlink is not defined in page 414 (as mentionned) but in page 475 (figure E3). it is the same for all definitions (distribute, inter -repetition ...) in this annexe, please check all pages refered in the text

  • Reported: MARTE 1.0b2 — Fri, 25 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Check all cross references. This editing work has to be done after no page
    number can change or all the cross references have to be made active (preferred
    solution).

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Missing illustration for "Shape" and "reshape" stereotype

  • Key: MARTE_-4
  • Legacy Issue Number: 12585
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Missing illustration for "Shape" and "reshape" stereotype Need clarification inside the "Shape" and "Reshape" definition explanation

  • Reported: MARTE 1.0b2 — Wed, 23 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Add an example of these two stereotypes in action at the end of the chapter.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE Beta: 12.3.2.4 FlowBFeature issue # 2

  • Key: MARTE_-3
  • Legacy Issue Number: 12579
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    why is it called a “FlowBFeature” at all – what does it have to with Flows?

  • Reported: MARTE 1.0b2 — Thu, 17 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE Beta: 12.3.2.4 FlowBFeature issue # 1

  • Key: MARTE_-2
  • Legacy Issue Number: 12578
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    the description says: “A FlowBFeature specifies the nature of a BehavioralFeature” and it lists BehavioralFeature in the Extensions section, yet in figure 12.6 it is shown extending Property

  • Reported: MARTE 1.0b2 — Thu, 17 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Annex 3

  • Key: MARTE_-1
  • Legacy Issue Number: 12577
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    This annex is not complete. It needs to be finalized and updated according to the EAST-ADL2 language

  • Reported: MARTE 1.0b2 — Thu, 17 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This resolution provides a revised text that completes Annex 3.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

TimedElements::TimedObservation (fig. 9.18) does not exist

  • Key: MARTE-187
  • Legacy Issue Number: 12238
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    TimedElements::TimedObservation (fig. 9.18) does not exist, the correct element is Time::TimeRelatedEntities::TimedObservations::TimedObservation

  • Reported: MARTE 1.0b1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Substitution done.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Section: 13.3.1

  • Key: MARTE-186
  • Legacy Issue Number: 12221
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Figure 13.12 needs to be updated to show all properties owned by the <<RtAction>> in order to complete the diagram according to the definition of the stereotype itself.

  • Reported: MARTE 1.0b1 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The mentioned attributes of <<RTAction>> are missing in Figure 13.11 (and not
    13.12. This resolution proposes to fix Figure 13.11 with the right RtAction
    attributes, according to the Stereotype description.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

first sentence of sub-section 6.4.2

  • Key: MARTE-185
  • Legacy Issue Number: 11530
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    The first sentence of sub-section 6.4.2 says: "Each extensions proposed by MARTE have been conflated around one main concerns and detailed in separate chapters: chapter 7 to chapter 18 and Annex E." I wonder if you mean "...chapter 7 to chapter 17 and Annex F." since there isn't a chapter 18, and Annex F is cited on the next paragraph.

  • Reported: MARTE 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Yes, the text should refer to chapter 7 to chapter 17 and Annex F. see next proposed resolution.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

RequestEventStream changed by WorkloadEvent

  • Legacy Issue Number: 15377
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    The term RequestEventStream is still used in GQAM, and in Annexes F and H while the concept has been refurbished as WorkloadEvent and others. Make all of them consistent.

  • Reported: MARTE 1.0 — Tue, 20 Jul 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The change from RequestEventStream to WorkloadEvent needs to be completed.
    The sections where it appears still in the text are:
    annex H, some texts in GQAM and PAM and many sections in Annex F: 10.19, 10.14,
    10.21, 11.1, 12.1, 12.3, 12.4

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE Beta 3: Invalid stereotype label in figure 11.8

  • Legacy Issue Number: 15106
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 11.8 has an element called Memory inside an element named "p:Process[256]" that is labeled as 'app_allocated'. Unfortunately, there is no such stereotype defined in MARTE (this is probably a leftover from an earlier version)

  • Reported: MARTE 1.0 — Tue, 15 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace “app_allocated” by “allocated” as suggested. The kind “application”
    already has the information about the role (“app_”).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - Absence of rule for calling behaviors

  • Legacy Issue Number: 15100
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    VSL doest not provide a rule for expressing behavior calls (i.e., it only supports call of operations). Since Behaviors are first class citizen of UML2, there is no fundamental reason for preventing this kind of expressions. Integrating a rule for calling behaviors does not require much effort (cf. following proposed resolution).

    Proposed resolution:

    • Modify text of B2.4 p.431 (p.443 of the pdf)
      Between paragraph starting with “An Operation Call Expression…” and paragraph starting with “This metamodel does not define…”, insert the following paragraph:
      A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.
    • Modify figure B.4 p.432 (p.444 of the pdf) as follows:
      . Add a class BehaviorCallExpression, and a generalization relationship between this class and Expression
      . Add a composition relationship between BehaviorCallExpression and ValueSpecification, identical to the composition relationship between OperationCallExpression and ValueSpecification (this is to capture the arguments of the call)
      . On the diagram, add an abstract class Behavior, with a grey background like classes Property and Operation.
      . Add an association between BehaviorCallExpression and Behavior, identical to the association between PropertyCallExpression and Property, except that the name of the role should : definingBehavior
      . Add the following derived property to BehaviorCallExpression: /behavior:String
    • In section B.3.3.13:
      Replace:
      <expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr>
      <operation-call-expr> <conditional-expr>
      By:
      <expression> ::= <variable-call-expr>
      <variable-declaration> <property-callexpr>
      <operation-call-expr> <behavior-call-expr> <conditional-expr>
    • p.453 (p.465 of the pdf), insert the following section (and increment the number of remaining sections):

    // Beginning of section
    B.3.3.17 Behavior Call Expressions
    Behavior calls are particularly used in the MARTE context to call behaviors taking data type values as parameters.

    <behavior-call-expr> ::= <behavior-name> '('[ <argument-value> [','<argument-value>]* ]')’
    <behavior-name> ::= [<namespace> '.'] <body-text>
    <namespace> ::= <body-text>

    Expression typing
    • The <behavior-call-expr> production rule should be evaluated to the type of the UML::Behavior that is called.
    • The <argument-value> production rule must be evaluated to the corresponding to UML::Parameter's type of an existing UML::Parameter owned by the UML::Behavior.

    Abstract syntax mapping
    • The <behavior-call-expr> production rule maps to the BehaviorCallExpression domain element described in Annex F (Section F.13.XX).

    Disambiguating rules
    • <behavior-name> should correspond to an existing UML::Behavior name.
    //end of section

    • In annex F, insert a section F.13.1 as follows (and increment of remaining sections):

    // beginning of section
    F.13.1 BehaviorCallExpression (from Expressions)

    Generalizations
    • Expression (from Expressions) on page 560

    Associations
    • definingBehavior: Causality::CommonBehavior::Behavior [1]
    Called Behavior.
    • argument: VSL::ValueSpecification [*]

    {ordered}


    Arguments of the Operation Call.

    Attributes
    • /behavior: String [1]
    String with the qualified name of the called Behavior. This is a derived value obtained from the definingBehavior.

    Semantics
    A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.
    // end of section

  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The absence of rules for calling behaviors indeed introduces an artificial limitation to the
    applicability of VSL. Concretely, all the available behavior signatures are currently defined
    following the object-oriented paradigm, in the form of operations (e.g., String.concat(String)),
    belonging to data types of the standard MARTE libraries. These behavior signatures could
    alternatively be defined following a procedural style (e.g. concat(String,String)). Designers who
    are familiar with procedural languages would probably feel more comfortable with this approach.
    Since UML natively offers support for describing behavior signatures in the procedural style, VSL
    should not prevent the usage of this kind of behaviors, and a rule should be added to support call
    of behaviors. The following figure illustrates the differences between the two paradigms, from
    both the perspective of libraries definitions (left hand side of the figure) and the perspective of
    usage in VSL (right hand side of the figure).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B.3.3.15 - typos in rule in the context of Property Call Expression

  • Legacy Issue Number: 15099
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    In rule <namespace>, the element [‘.’ <namespace>] is useless and should be removed.

    Proposed resolution:

    • Replace:
      <namespace> ::= <body-text> ['.' <namespace>]
      By
      <namespace> ::= <body-text>
  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Domain concept (definingEvent) not implemented in the UML representation

  • Legacy Issue Number: 15116
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    The domain view of the Time Chapter provides clocks to achieve two goals. First, Clocks give an explicit time referential for various kinds of elements.
    Second, Clocks give an orthogonal mechanism to put temporal information on any events, whereas UML consider TimeEvent as a special case of events.

    In the domain view, the second position was made concrete by the attribute "definingEvent" that was denoting the event from which a clock was built (occurrences of the events, where the instants of the clock). All the stereotypes provided in the UML representation address the first objective. None address the second one.

    Suggested resolution, the stereotype "Clock" could extend the metaclass "Event" as well. That would allow clock constraints to constrain/specify the occurrences of events.

  • Reported: MARTE 1.0 — Wed, 3 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B.3.3.17 - In conditional expressions, should not be optional

  • Legacy Issue Number: 15098
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    In rule <conditional-expression>, <if-false-exp> should not be optional. Otherwise, it is not clear what is the result of a ConditionalExpression in the case where <condition-expr> evaluates to false, and there is no specified <if-false-exp>
    Proposed resolution:

    • Replace:
      <conditional-expression> ::= <condition-expr> '?' <if-true-expr> [':' <if-false-exp>]
      By
      <conditional-expression> ::= <condition-expr> '?' <if-true-expr> ':' <if-false-exp>
  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The proposed resolution, described in the summary, would indeed avoid ambiguities, and make
    the usage of operators ‘?’ ‘:’ more conventional.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B.3.3.11 and B.3.3.12 - Introducing optional keywords ‘Tuple’ and ‘Choice’

  • Legacy Issue Number: 15097
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    Adding an optional keyword ‘Tuple’ may improve readability of tuple expressions, since, depending on the context, an expression of the form ‘(‘ValueSpecification’)’ can resolve to a tuple value or a choice value. Of course, the context is enough to disambiguate the rule. The optional keyword ‘Tuple’ would only provide a mean for making the expressions more readable from a user standpoint (note that the ‘Tuple’ keyword is also used in OCL). For the same reason, an optional keyword ‘Choice’ could also be added in choice expressions.

  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This issue concerns two aspects of VSL: Introduction of optional keyword for
    clarifying the syntax, and alignment with OCL. These two points are interesting,
    but only focus on some very specific aspects on the relationship between VSL
    and OCL. It would not make sense to address this relationship by only focusing
    on the keyword Tuple. That’s why this issue must be closed without changes,
    and a new issue, more generally related to the clarification of the links between
    VSL and OCL (what parts are shared, how VSL is both a short-hand notation for
    some OCL statements / an extension of OCL) and the adjustments that may be
    needed by the VSL syntax should be raised.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B3.3.9 - Typos in rule

  • Legacy Issue Number: 15096
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    There are some typos and mistakes in the rule <interval-bounds>, concerning the following alternatives:

    <choiceinterval-bound> '..' <tuple-interval-bound>
    <expression-interval-bound> '..' <tuple-interval-bound>

    Proposed resolution:

    • Replace:
      <choiceinterval-bound> '..' <tuple-interval-bound>
      by
      <choice-interval-bound> '..' <choice-interval-bound>
    • Replace:
      <expression-interval-bound> '..' <tuple-interval-bound>
      by
      <expression-interval-bound> '..' <expression-interval-bound>
  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Follow the proposed resolution

  • Updated: Fri, 6 Mar 2015 23:15 GMT

GCM behavioral representation

  • Legacy Issue Number: 15081
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Adrian Noguero)
  • Summary:

    The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams.

    For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases.

  • Reported: MARTE 1.0 — Tue, 23 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue addresses two different problems. The first one regarding receptions in
    Activity diagrams and the second one regarding invocations in state machine
    diagrams.
    The first part of the issue can be closed, since it is possible to model this kind of
    receptions using UML AcceptEventActions; which can be associated with a
    GCMTrigger. Example 3, on Figure 12.23, illustrates this.
    The second part of the issue; however it is not currently covered by MARTE or
    UML. The proposed resolution is to add a new stereotype,
    GCMInvocatingBehavior, which models the invocations taking place inside a
    behavior without having to look at its internals (particularly interesting in the case
    of OpaqueBehaviors). This stereotype will allow specifying communications in
    the scope of a single component and independently from other components (in
    opposition with Interactions, which specify communications between different
    components, with a system wide scope).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE Issue: Overloaded relationship Scenario to Step in Analysis

  • Key: MARTE11-99
  • Legacy Issue Number: 15073
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    In the analysis subprofiles a step has two relationships to scenarios:

    1 Containment... a step is always contained in a scenario
    2 Refinement: a step may be optionally be refined by a lower-level scenario

    The GQAM chapter defines one association behavior/steps which is defined
    as containment from the scenario point of view, and as refinement from
    the step point of view. This is navigable and usable, but formally
    incorrect.

    Suggested resolution: To be formally correct it requires two associations.
    One defines a collection of steps as the steps of the scenario, the other
    defines a scenario as a refinement of a step.

    Suggestion:

    Containment: Scenario has association steps, Step has association scenario

    Refinement: Scenario has association parentStep, Step has association
    childScenario

    Alternatively we could explain the overloading in the text and leave the
    profile as it is.

    Needs discussion.

  • Reported: MARTE 1.0 — Sat, 20 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    To be formally correct it requires two associations. One defines a collection of
    steps as the steps of the scenario, the other defines a scenario as a refinement
    of a step. Suggestion:
    Containment: Scenario has association steps, Step has association scenario
    Refinement: Scenario has association parentStep, Step has association
    childScenario
    These changes are needed both in the domain model sec 15.2 and the profile
    sec 15.3, and in Appendix F.10 for the encoding of the domain model
    Also, some changes in sec. F.10.3 to synchronize it with sec 15.2 were
    transferred from issue 14435,
    • association Actions renamed steps (consistent with Fig 15.3)
    • association usedResources dropped (not in Fig. 15.3)
    • association inputStream renamed cause (consistent with fig 15.3)
    • association connectors added (consistent with Fig 15.3)
    • attribute priority dropped (it occurs on Step)(consistent with chapter 15) (A) Figure 15.3:
    • add association parentStep - childScenario
    • rename association behavior - steps to scenario - steps
    (B) Section 15.2, Text p 290 para 5:
    Before:
    Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step
    can be optional (with a probability less than one of being executed), or repeated (with a
    repetition count). It can be refined as another BehaviorScenario (its “behavior”
    association). The “isAtomic” property specifies atomicity of execution (default is false).
    Revised Text (the one new sentence is in red)
    Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step
    can be optional (with a probability less than one of being executed), or repeated (with a
    repetition count). A BehaviorScenario is a collection of Steps, but also a Step can also be
    the parent of a refinement as a more detailed BehaviorScenario (its childScenario). The
    “isAtomic” property specifies atomicity of execution (default is false).
    (C) Fig 15.7 (the profile) also needs to be updated for the second association
    between Step and Scenario:
    • add association parentStep - childScenario
    • modify association behavior - steps to scenario - steps
    (D) Appendix F.10.3 for BehaviorScenario
    The five changes transferred from issue 14435 are included, plus the association
    change between Step and BehaviorScenario. For clarity the new text is in red.
    Original text: Associations
    • root: Step [0..1] Root Step to begin the BehaviorScenario.
    • Actions: Step [0..1] Set of Steps making up the BehaviorScenario.
    • inputStream: RequestEventStream [1..*] RequestEventStream that initiates it.
    • usedResources: Resource [0..*]

    {ordered}

    Set of resources used by the scenario UML
    Profile for MARTE, V1.0
    Attributes
    • hostDemand: NFP_Duration [0..1] CPU demand in time units.
    • hostDemandOps: NFP_Real [0..1] CPU demand in operations.
    • priority: NFP_Integer [0..1]
    • respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation.
    • interOccTime: NFP_Duration [0..1] Interval between successive initiations of an
    operation.
    • throughput: NFP_Rate [0..1] Frequency of initiations of an operation.
    • utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times
    delay). For a resource, the fraction of time each unit is busy, times the number of units.
    • utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this
    operation.
    Revised text:
    Associations
    • root: Step [0..1] Root Step to begin the BehaviorScenario.
    • steps: Step [0..1] Set of Steps making up the BehaviorScenario.
    • cause: RequestEventStream [1..*] RequestEventStream that initiates it.
    • parentStep: Step [0..1] Step of which this BehaviorScenario is a refinement (nested
    behavior)
    • connectors: PrecedenceRelation [*] The set of precedence relationships between the
    steps of the scenario
    Attributes
    • hostDemand: NFP_Duration [0..1] CPU demand in time units.
    • hostDemandOps: NFP_Real [0..1] CPU demand in operations.
    • respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation.
    • interOccTime: NFP_Duration [0..1] Interval between successive initiations of an
    operation.
    • throughput: NFP_Rate [0..1] Frequency of initiations of an operation.
    • utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times
    delay). For a resource, the fraction of time each unit is busy, times the number of units.
    • utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this
    operation.
    (E) Section F10.17 for Step
    Add the new association between Step and BehaviorScenario Old text:
    Associations
    • outputRel: PrecedenceRelation [*] Successor relation.
    • inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation.
    Attributes
    • isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further.
    • blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step.
    • repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or
    loop.
    • probability: NFP_Real [0..1] Probability of the step to be executed (useful for
    conditional execution).
    • priority: NFP_Interval [0..1] Step priority.
    Revised text:
    Associations
    • outputRel: PrecedenceRelation [*] Successor relation.
    • inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation.
    • childScenario: Scenario [0..1] An optional refinement of the behavior of this Step
    Attributes
    • isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further.
    • blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step.
    • repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or
    loop.
    • probability: NFP_Real [0..1] Probability of the step to be executed (useful for
    conditional execution).
    • priority: NFP_Interval [0..1] Step priority.
    (F) Sec 15.3.2.12, giving the UML definition of GaScenario
    Old text:
    Associations
    • steps: Step [1..*]
    The set of steps that make up the Scenario.
    New text:
    Associations
    • steps: GaStep [1..*]
    The set of steps that make up the Scenario.
    • parentStep: GaStep [1..*]
    A GaStep, of which this scenario is a refinement.
    (G) Sec 15.3.2.13, giving the UML definition of GaStep
    Old text: Associations
    • behavior: GaScenario [0..1]
    A GaScenario that refines a composite Step.
    New text:
    Associations
    • scenario: GaScenario [0..1]
    The GaScenario that that contains this Step.
    • childScenario: GaScenario [0..1]
    A GaScenario that refines this Step, making it a composite Step.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsitencies in MARTE::GCM

  • Key: MARTE11-98
  • Legacy Issue Number: 15057
  • Status: closed  
  • Source: CEA, LIST, Laboratory of model driven engineering for embedded systems, Point Courrier 94, Gif-sur-Yvette, 91191, France ; ( Florian Noyrit)
  • Summary:

    In the context of our work for the ADAMS project (http://www.adams-project.org/) we try to align MARTE and AUTOSAR with specific focus on MARTE::GCM and AR::SWC. To do so, we produced the domain models in UML. Unfortunately, we found the following inconsistencies, unclarities or typography issues in the MARTE specifications:

    • Issue1:
      AssemblyConnector (F.6.1) in annex F is not used in the domain of MARTE.
      -Resolution1:
      Remove F.6.1 and F6.13 subsections.
    • Issue2:
      SendFlowAction (F6.13) in annex F is not used in the domain of MARTE.
      -Resolution2:
      Remove F6.13 subsection.
    • Issue3:
      In Figure 12.2 (The bulk of the MARTE GenericComponentModel package), BehavioredClassifer qualified name is wrong.
      -Resolution3:
      Marte::CoreElements::Foundations::BehavioredClassifier should become MARTE::CoreElements::Causality::CommonBehavior::BehavioredClassifier
    • Issue4:
      In second paragraph of subsubsection 12.2.1 (The GenericComponentModel Package), "AssemblyConnector" is not appropriate
      -Resolution4:
      … "An interaction port defines an explicit interaction point through which components may be connected (linked) through an AssemblyConnector, and through which they can communicate via message passing."… should be changed to : "An interaction port defines an explicit interaction point through which components may be connected (linked) through an assembly connector, and through which they can communicate via message passing."…
    • Issue5:
      BFeatureKind (F.6.3) shouldn't be used anymore and it is replaced by ClientServerKind
      -Resolution5:
      Remove F.6.3. In subsection ClientServerPort (F.6.8) the type for "kind" attribute should be ClientServerKind.
    • Issue6:
      DirectionKind (F.6.12 ) shouldn't be used anymore and it is replaced by FlowDirectionKind
      -Resolution6:
      Remove F.6.12. In subsection FlowPort (F.6.15) and FlowProperty (F.6.16) the type for "direction" attribute should be FlowDirectionKind. Update Index.
    • Issue7:
      Mutliplicity and defalut value of "direction" attribute in FlowPort (F.6.15) should be respectively [1] and "= inout" in annex F
      -Resolution7:
      In F.6.15, [0..1] multiplicity for direction should be changed to [1] and default value set to "= inout"
    • Issue8:
      Default value of "direction" attribute in FlowProperty (F.6.16) should be "= inout" in annex F
      -Resolution8:
      In F.6.15, default value for direction should be set to "= inout"
    • Issue9:
      Multiplicity specification association of FlowPort (F.6.15) should be [0..*]. Furthermore this association is not represented in Figure 12.3
      -Resolution9:
      In F.6.15, multiplicity for specification should be changed to [0..*], name should be updated to "specifications" and Figure 12.3 should be updated consequently.
    • Issue10:
      In annex F, Attributes paragraph title for InvocationAction (F.6.19) should actually be "Associations"
      -Resolution10:
      In F.6.19, change paragraph title to "Associations" and add a "Attributes" pragraph title with "None" as body.
    • Issue11:
      In annex F, generalization to ClientServerFeature is missing for Operation (F.6.21)
      -Resolution11:
      In F.6.21, add ClientServerFeature to Generalizations paragraph
    • Issue12:
      In annex F, association to Flowproperty is missing for SendDataAction (F.6.22)
      -Resolution12:
      In F.6.22, add " + targetProperty: FlowProperty [0..1]" to Associations paragraph
    • Issue13:
      In annex F, Associations paragraph title (the one containing kind attribute) for ClientServerFeauture (F.6.6) should actually be "Attributes"
      -Resolution13:
      In F6.6 change paragraph title to "Attributes"
    • Issue14:
      In Figure 12.3 and Figure 12.4, default values are not represented
      -Resolution14:
      To clarify the specification, default values should be represented too (i.e. "=false" for isAtomic and "=inout" for direction
    • Issue15:
      SendSignalAction introduced in Figure 12.5 is not mentioned in annex F
      -Resolution15:
      Add annex F the concept with generalization to InvocationAction and change BoradcastSignalAction (F.6.4) generalization to SendSignalAction
    • Issue16:
      In annex F, multiplicity for onPort association of InvocationAction (F.6.19) and the multiplicity represented in Figure 12.5 are inconsistent : [1] and [0..1] respectively.
      -Resolution16:
      Should be set to [1] for both.
    • Issue17:
      ClientServerSpeification concept should be added to align with what is done for FlowPort
      -Resolution17:
      In annex F Add ClientServerSpecification concept in annex F. It has " + ownedFeatures: ClientServerFeature [*]" association. Add an association " + specifications: ClientServerSpecification [0..*]" to ClientServerPort (F.6.8)
    • Issue18:
      In annex F, isAtomic attribute of ClientServerPort (F.6.8) should be defined as derived
      -Resolution18:
      In F.6.8, add a "/" in front of isAtomic attribut of ClientServerPort
    • Issue19:
      Constraints on direction attribute for FlowPort
      -Resolution19:
      Add this constraint in Annex F to FlowPort (F.6.15) : If the FlowPort is not atomic then if direction attribute of all the FlowProperty of all its FlowSpecification are set to in (respectively out) then direction is in (respectively out) otherwise direction is inout.
      If the FlowPort is atomic then direction attribute must be set by designer.
    • Issue20:
      Constraints on kind attribute for ClientServerPort
      -Resolution20:
      Add this constraint in Annex F to ClientServerPort (F.6.8) : If the ClientServer is not atomic then if kind attribute of all the ClientServerFeature of all its ClientServerSpecification are set to provided (respectively required) then direction is provided (respectively required) otherwise kind is proreq.
      If the ClientServerPort is atomic then kind attribute must be set by designer.
    • Issue21:
      In annex F.6.7, required enum literal paragraph of ClientServerKind is inconsistent
      -Resolution21:
      … "The behavioral feature is provided by the port of the owning entity."… should changed to "The behavioral feature is required by the port of the owning entity."
  • Reported: MARTE 1.0 — Mon, 15 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This issue actually consists of sub-issues, which concerns minor synchronization problems
    between diagrams of the domain model, and associated descriptions in Annex F. For each subissue,
    the submitter has proposed resolutions. All the resolution (as the described in the section
    “summary” above) are reproduced in the section “revised text” below, with complementary
    information when needed.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Timing observer naming

  • Key: MARTE11-97
  • Legacy Issue Number: 15048
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    The GQAM chapter defines the stereotype GaTimedObs in both domain and
    profile figures, however there are inconsistencies elsewhere

    ... GQAM sec 15.3.2.12 refers to GaTimingObserver

    ... SAM chapter refers to it as GaTimingObserver, in the domain figure
    16.5
    ... and also just before Fig 16.8
    ... and as TimingObs, in the profile figure 16.8

    ...PA chapter refers to it as GaTimingObserver in profile Fig 17.7

    These are due to a last minute effort to shorten the names. THey all need
    to be standardized on GaTimedObs.

  • Reported: MARTE 1.0 — Thu, 11 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The domain term in chapters 15 16 17 and appendix F should be
    TimedObserver, the profile term in chapters 15 16 17 should be TimedObs

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE AADL Annexe

  • Key: MARTE11-96
  • Legacy Issue Number: 15039
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Precise component type and implementation relationship.
    "Component realization" concept seems more inline with the AADL semantics than "UML realization" concept.

  • Reported: MARTE 1.0 — Fri, 5 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Disposition: See issue 14871 for disposition

  • Updated: Fri, 6 Mar 2015 23:15 GMT

13.3 UML Representation

  • Key: MARTE11-95
  • Legacy Issue Number: 15036
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    CallConcurrencyKind is an Enumeration but is not marked as such on the Diagram

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue actually refers to figure 13.8. Indeed, the keyword “enumeration” is missing on
    CallConcurrencyKind. The proposed resolution consists in adding the missing keyword.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

• polling: PollingParameters [0..1]

  • Key: MARTE11-94
  • Legacy Issue Number: 15035
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    but is called D.4.6 PoolingParameters (PollingParameters definition does not exist in the spec)

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    It is indeed a typo: change PoolingParameters into PollingParameters for the
    label of section D4.6.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Diagram shows {ordered usedResouces}, it should be {ordered usedResources}.

  • Key: MARTE11-93
  • Legacy Issue Number: 15034
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    Diagram shows

    {ordered usedResouces}

    , it should be

    {ordered usedResources}

    .

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    New figure 10.18.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

<> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)

  • Key: MARTE11-92
  • Legacy Issue Number: 15033
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    <<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand

  • Key: MARTE11-90
  • Legacy Issue Number: 14917
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    GQAM::BehaviorScenario specializes GRM::ResourceUsage. It seems that GRM::UsageDemand generalizes GQAM::WorkloadEvent. If so, make explicit this generalization relationship and consider the WorkloadEvent.timeEvent, WorkloadEvent.effect and BehaviorScenario.cause as redefined attributes

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This is actuially a very good observation. It does not seem dangerous. A
    resolution with it is provided.
    Note for the editor: Please observe that this resolution must be edited in after
    issue 14906, since this add the “redefined” constraint.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Figure 8.5 UML profile diagram for NFPs modeling

  • Key: MARTE11-91
  • Legacy Issue Number: 15032
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    Figure 8.5 UML profile diagram for NFPs modeling

    StereoType "Unit" has a Tag of convOffset but the xmi import has named it offsetFactor

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The right name is convOffset. The xmi must be fixed..

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Align notions of duration in NFP, Time and GQAM

  • Key: MARTE11-86
  • Legacy Issue Number: 14912
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The Time profile is suposed to provide a fundational timing model for MARTE. Time stereotypes are specialized in several of profiles, such as GRM and GQAM. However, while time-related notions in the analysis profiles are typed by NFP_Duration, the Time::TimedProcesssing.duration stereotype attribute is typed by a ValueSpecification. This type inconsitency makes between general and specialized concepts creates usability issues. Indepently of that, note that the TimedProcessing meta-class and stereotype attribute are not consistently typed, as the (normative) TimedProcessing.duration meta-class attribute is typed by the (non-normative) CVS::DurationValueSpecification.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Disposition: See issue 14903 for disposition

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Clarify the additional semantics brought by the GRM::TimingResource stereotype

  • Key: MARTE11-85
  • Legacy Issue Number: 14911
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    GRM::TimingResource inherits from Resource and is then specialized into ClockResource and TimerResource but it does not add any new property. A clarification of the additional semantics of this intermediate stereotype would be needed

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This is already explained in its definition in page 93.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

The Step.host attribute is redundant,

  • Key: MARTE11-88
  • Legacy Issue Number: 14914
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The Step.host attribute is redundant, given that a schedulable resource need to be related to a processor (execution host) for the analysis model to be complete and practically usable. Three alternatives for this stereotype attribute may be discussed: a) remove it, b) make it derived, c) keep it as a duplicate shortcut information. On-going discussion with Dorina and Murray on this topic

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The host relationship is very important when we need to model an abstract
    application without an explicit Task Model. The Step should be rich enough to
    model a piece of code subject to scheduling. For this reason a step has a Host, a
    Priority (among others). This kind of assumptions is necessary for early
    scheduling analysis. We propose then to close with no change this resolution.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand

  • Key: MARTE11-87
  • Legacy Issue Number: 14913
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand, and harmonize their use across analysis chapters of the specification. On-going discussion with Dorina and Murray on this topic.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Clarified, using a reference to the definitions in Table 15.1. Some of the attributes
    like execTime occur in the Table but are not used in the domain model, this is
    also clarified

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Typo in Figure 10.13: multiplicity of event property

  • Key: MARTE11-89
  • Legacy Issue Number: 14916
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:
    • symbol in front of the event property in Figure 10.13, which multiplicity is 0..1
  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Separate the * from the +event role label, and locate them correctly in figure
    10.13.
    The figure here shown is the very same as the resolution for issue 14908.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -).

  • Key: MARTE11-84
  • Legacy Issue Number: 14910
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such "(end - start) < (value=10.0, unit=ms)" (where start and stop are TimeObservation

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue addresses the absence of operations for the datatype
    NFP_CommonType (and its children types such as NFP_Duration) capturing
    predefined operators applying on these types. One of the consequences of this
    absence is that it is not possible to manipulate values of these in datatypes in
    VSL infix expressions (such as “"(end - start) < (value=10.0, unit=ms)", which
    would imply that operator ‘<’ is available for NFP_Duration).
    As suggested by the issue description, one possible solution would be to modify
    the existing MARTE libraries, by adding required operations to
    NFP_CommonType or its children datatypes. The main drawback of this
    approach is that, each time a user identifies a need for an operator which is not
    supported by a datatype from the MARTE libraries, the library needs to be
    modified, by adding the corresponding operation to the datatype. This solution is
    not flexible.
    The idea of the resolution described in the section “revised text” is to provide
    users with a flexible mechanism for stating that a given predefined operator can
    be used on a particular type (in the context of infix VSL expressions). The core
    idea behind this resolution is to rely on the new features introduced in the
    resolution to issue 15100. The resolution to this issue introduces additional
    syntactic rules to VSL for expressing behavior calls (i.e.,
    BehaviorCallExpression). As described in the resolution to this issue, defining
    behavior signatures following a procedural style (i.e., capturing signatures by
    behaviors instead of operations on DataTypes) can help to limit the coupling
    between type definitions and behavior signature definitions (since signatures are
    no longer captured as operations of data types). Relying on Behaviors instead of Operations for capturing new operators (e.g., adding predefined operators for
    NFP_CommonType) would therefore avoid modifications of existing libraries.
    In order to capture the fact that a given behavior actually represents an operator,
    a new stereotype, « Operator », is introduced in this resolution. Some text is also
    provided regarding how this information can be automatically exploited by a VSL
    parser, regarding type inference and scoping.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Typo in Figure 10.13: enery property

  • Key: MARTE11-81
  • Legacy Issue Number: 14907
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    ResouceUsageAmount has a 'enery' property. Rename into 'energy'

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource

  • Key: MARTE11-83
  • Legacy Issue Number: 14909
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource. SchedulableResource limits the domain of possible analysis that are possible with GQAM

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

ResourceUsage.requiredAmount aggregation kind should be composite

  • Key: MARTE11-82
  • Legacy Issue Number: 14908
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    ResourceUsage.requiredAmount aggregation kind should be composite

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Add the diamond in ResourceUsage.requiredAmount depicted in figure 10.13.
    Here it is to be solved also the typo reported in Issue 14916

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsistency between the Time domain model and related profile

  • Key: MARTE11-77
  • Legacy Issue Number: 14903
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the domain model, TimeProcessing.duration is a simple association, typed by CVS::DurationValueSpecification while in the profile the association is a composition, typed by ValueSpecification. Inconsistency should be corrected

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    In the domain view, the intent was to refer to a value (a duration value) and a
    value exists independently of its specification and therefore cannot be owned. In
    the UML representation, in practice, we use a specification to denote the value
    and there is no reason for the specification not to be owned by another element.
    The resolution proposes to keep the association in the domain view but refer to
    the metaclass DurationValue instead of CVS::DurationValueSpecification. This
    partly addresses also the issue 14912, stating that
    CVS::DurationValueSpecification being non normative should not be used in a
    normative part. The composition with a ValueSpecification is maintained in the
    profile. This is consistent with the different roles played by a value and one of its
    possible specifications.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsistent definition of CommunicationChannel properties

  • Key: MARTE11-76
  • Legacy Issue Number: 14902
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Annex F defines a CommunicationChannel.msgSize property while the meta-model and the profile defines a packetSize property. Note that the term 'packet' may not generic enough for the concept of CommunicationChannel

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    For consistency, change the attributes of a CommunicationChannel in Annex F
    section F.10.4, and the GaCommChannel stereotype description in section
    15.3.2.3 so that they appear as packetSize and utilization, like in Fig 15.5.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

SAM Workload Figure defines a new property for GQAM::WorkloadBehavior

  • Key: MARTE11-79
  • Legacy Issue Number: 14905
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Figure 16.3 located in the SAM chapter defines a new property (typed by EndToEndFlow) for a meta-class WorkloadBehavior defined in GQAM. Either move EndToEndFlow to GQAM or create a class that specializes WorkloadBehavior and introduce this new property. Additionally, the 'workload' property name can be renamed into 'flow' to avoid creating confusion.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    To avoid this new association for WorkloadBehavior, this resolution proposes to remove the
    association itself. It is not really needed since WorkloadBehavior already has the composite
    association with the two concepts that are part of an EndToEndFlow (WorkloadEvent and
    BehaviorScenario).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

TimedElement.on default value should refer to the ideal clock

  • Key: MARTE11-78
  • Legacy Issue Number: 14904
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    TimedElement.on default value should refer to the ideal clock, by the mean of a default property (e.g. instance value)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The intent was actually to do so. When attribute "on" is not used, then it implicitly
    refers to idealClk. However, "idealClk" is defined in "TimeLibrary", which actually
    applies the "Time" profile. So what is requested in the issue would actually create
    a cyclic dependency.
    The resolution proposes to add a sentence to make the intent clear as suggested
    by the issue.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Figure 16.3 inconsistent with Figure 15.3

  • Key: MARTE11-80
  • Legacy Issue Number: 14906
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Figure 15.3 defines a cause-effect association between WorkloadEvent and WorkloadBehavior, while Figure 16.3 defines an inputSteam-effect association

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Change “inputStream” by “cause” in the association between WorkloadEvent and
    WorkloadBehavior in Figure 16.3. This implies changing also the description of
    the concept in Annex F section F10.3.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

SecondaryScheduler should be an association of the Scheduler instead of a specialized class

  • Key: MARTE11-74
  • Legacy Issue Number: 14897
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    For the sake of simplicity, SecondaryScheduler should be an association of the Scheduler instead of a specialized class. Making this concept relative would provide means to support more than two-level schedulers. Requires changes in the meta-model and the profile

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This simplification is not possible since the mechanisms to share the capacity
    that will be rendered by the primary scheduler to the secondary in order to be
    brokered by the secondary needs to be expressed, and this is done by the
    utilization of the intermediate schedulable resource.
    Simpler models may be made at user model level, so that the association
    between them can be stereotyped as Schedulable resource, but that is not
    feasible at the profile or domain view level.
    Resolution:
    Closed the issue with no change to the specification.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Update the GCM ClientServerPort to take into account evolutions in UML 2.3

  • Key: MARTE11-73
  • Legacy Issue Number: 14896
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Update the GCM ClientServerPort to take into account evolutions in UML 2.3 (introduction of conjugated port)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue refers to the introduction in UML 2.3 of the property “isConjugated” on the metaclass
    Port. It means that the property “isConjugated” is no longer needed on the stereotype
    “ClientServerPort” from MARTE since ClientServerPort extends Port.
    The revised text describes required modifications to the MARTE specification. Note that, even
    though the issue does not mention it, FlowPort are also concerned by this evolution of UML ports.
    The “revised text” section also describes modifications required by the stereotype FlowPort.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Remove the TimedObservation stereotype

  • Key: MARTE11-72
  • Legacy Issue Number: 14895
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    TimedObservation is an abstract stereotype that extends TimedElement without adding new features. It is sublassed by the concrete TimedDurationObservation and TimedInstantObservation. Given that it cannot be directly used, and for the sake of smplicity, removing the stereotype may be considered

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Stereotype TimedObservation was created for consistency with the UML
    Specification and considering that TimeExpression would refer to
    TimedObservation directly without deciding on the actual specialization.
    The stereotype can be removed with no harm. TimeExpression will refer to
    (untimed) Observation instead. Even though the semantics is weakened, there is
    no actual impact since the association between TimeExpression and Observation
    is not actually serialized by any tool.
    Though, it should be noted that TimedObservation cannot be removed from the
    Domain View since it is actually used by DurationPredicate and TimePredicate.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

AssigmentKind/AssignmentNature are redundant with AllocationKind/AllocationNature

  • Key: MARTE11-71
  • Legacy Issue Number: 14894
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Notions of kind and nature are shared between allocation and assignment. Related enumerations AssignmentKind and AssignmentNature describe the same concepts and are redundant. Proposed resolution: remove assignment enumerations and relate the Assign stereotype attributes to AllocationKind and AllocationNature

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Disposition: See issue 14841 for disposition

  • Updated: Fri, 6 Mar 2015 23:15 GMT

PortGroup concept used in Annex A.2 is not defined in the MARTE profile

  • Key: MARTE11-75
  • Legacy Issue Number: 14900
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    PortGroup concept used in Annex A.2 is not defined in the MARTE profile

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Port Group concept has been removed in AADL v2 and a more generic concept
    (feature group) has been introduced. The mapping towards MARTE is defined in
    issue 14866.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Different multiplicities in the GQAM meta-model and profile

  • Key: MARTE11-70
  • Legacy Issue Number: 14892
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the GQAM domain model, the multiplicity of the AnalysisContext.workloadBehavior is 1. In the profile, the multiplicity of the stereotype attribute is *. Proposed resolution: align on the profile and make it *.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Make it * in Fig 15.2 and Sec F10.2. Also there is a dangling phrase in Sec F10.2

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform

  • Key: MARTE11-69
  • Legacy Issue Number: 14891
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    AnalysisContext is the root of the GQAM model. In the first paragraph of the domain model, it is mentioned that an analysis context contains two parts: workload behavior and resource platform. AnalysisContext should specify composition relationships with WorkloadBehavior and ResourcePlatform (Figure 15.2)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary: {…This issue misreads the text, which is: “The top-level GQAM package shown in Figure 15.2, is organized around the concept of AnalysisContext, which represents the root of the domain model. It contains two parts that address different concerns: “It” refers to the top-level package, not to AnalysisContext. The relationship to WorkloadBehavior and ResourcesPlatform is consistently an association, in chapters 15 16 17. AnalysisContext is the root of a tree of associations. I suggest this be closed with no change. To convert the relationship to a composition would be a major rewrite of all three chapters, with no benefit to the profile. }

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL software concept upgrades

  • Key: MARTE11-68
  • Legacy Issue Number: 14874
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The provide a full MARTE AADL alignment, upgrade platform concepts with AADL 1) virtual bus 2) virtual processor concepts

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Renumber section 2.4.4 in 2.4.6 Device
    Add section 2.4.2 Virtual Processor
    A virtual processor represents a logical resource that is capable of scheduling and
    executing threads and other virtual processors bound to them. It will be represented as a
    MARTE “swSchedulingResource” AND “ProcessingResource” stereotyped UML
    Classifier
    Add section 2.4.4 Virtual Bus
    A virtual bus component represents logical bus abstraction such as a virtual channel or
    communication protocol. It will be represented at resource level as a MARTE
    “CommunicationMedia” stereotyped UML connection or classifier allocated to the
    physical HWBus.
    • If the communication media represents a bus, and the clock is the bus speed, "element size" would be the width of the bus, in bits.
    • If the communication media represents a layering of protocols, "element size"
    would be the frame size of the uppermost protocol.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL software concept upgrades

  • Key: MARTE11-67
  • Legacy Issue Number: 14873
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The provide a full MARTE AADL alignment, upgrade software concepts with AADL 1) abstract component, 2) prototype, 3) threadgroup, 4)subprogram group concepts

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    In AADL v2, the concepts of abstract component, prototype, thread group and
    subprogram group have been added and have be taken into account by MARTE
    to ensure a full AADL v2/MARTE alignment.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL component implmentation modeling

  • Key: MARTE11-65
  • Legacy Issue Number: 14871
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Upgrade AADL component declaration relationship to a AADL component implementation (UML Realization -> UML Component Realization)

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    An AADL component type specifies the external interface of a component that its
    implementations satisfy. It contains declarations that represent features of a
    component and property associations. An AADL component implementation
    represents the realization of a component in terms of subcomponents, their
    connections, flow sequences, properties, component modes and mode
    transitions. UML 2 “Realization” semantics makes references to a specialized
    abstraction relationship between two sets of model elements, one representing a
    specification and the other representing an implementation of the latter. The UML
    2 “ComponentRealization” concepts refine the “Realization” concepts, reducing
    the subset of linked elements to UML Components and Classifiers. This concepts
    suits better the the AADL component type/implementation relationship.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL connectors modeling

  • Key: MARTE11-64
  • Legacy Issue Number: 14870
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Same issue as 14864
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Annexe introduction

  • Key: MARTE11-63
  • Legacy Issue Number: 14868
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    AADL v2 has be voted.
    Upgrade introduction texte to position MARTE according the new version of the AADL standard

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace first sentence with

    AADL is a RTES design and analysis language and standard referenced at the
    SAE (standard number XXX). Version 2 has been voted in XXX. This section
    presents the correspondence between MARTE 1.0 and AADL 2.0 concepts, with
    the aim to clarify which subset of MARTE concepts shall be used to explicit
    AADL concepts. The MARTE profile has be adopted as the UML profile for
    AADL, so this section presents the MARTE2AADL concepts correspondence.
    The section is not a methodology to design AADL applications in UML. “

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL summeray table upgrade

  • Key: MARTE11-66
  • Legacy Issue Number: 14872
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Upgrade MARTE AADL summery table upgrade according resolved issues

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    see pages 59 - 62 of ptc/2010-08-30 for resolutoion

  • Updated: Fri, 6 Mar 2015 23:15 GMT

DATA : MARTE AADL mapping

  • Key: MARTE11-62
  • Legacy Issue Number: 14867
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Two ways of modeling Data existe in AADL: the one using the AADL Data annexe modeling features, the other one relying on a pure structural view.
    The first solution is currently addressed by the MARTE AADL annexe.
    The annexe has to be upgraded to take into account the second way of doing.

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace section A.2.3.4 with
    There are two ways of modeling AADL components, the first one addressing a
    pure architectural design, the second one, based on the Data Annex [SAE
    AS5506 A, Annex Document B: Data Modeling] , will be more dedicated to data
    modeling.
    AADL data component are used to represents different concepts
    • Data component classifier (type and implementation) staying for “data type
    in the source text”. This source text data type can be modeled by a data
    component type declaration with relevant properties without providing
    internal details that will be specified in a data component implementation.
    • Data subcomponents staying for “static data in the source text”. Data
    subcomponents are instances of data classifiers.
    According data classifier features and subcomponent features, the data
    component can represent:
    • A simple type (not necessary primitive) • A structured type (when sub component declared)
    • A class (when subcomponent present and provide subprograms declared)
    • A shared resource (if data access connection specified)
    AADL Primitive Types
    Each AADL primitive type from the AADL data_types packages (i.e. aadlboolean,
    aadlinteger, aadlreal, aadlstring) will have an UML/MARTE primitive type
    equivalent, defined in MARTE Model Library for Primitive Types (Annexe D from
    MARTE).
    These primitive types are commonly used in properties specification. Do
    represent them in an architectural view, the data annex based representation
    style must imperatively be followed. <<< see pages 51 - 53 of ptc/2010-08-30 for images>>>

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Feature group

  • Key: MARTE11-61
  • Legacy Issue Number: 14866
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The whole AADL features group concepts can't be represented in MARTE

    Precise the mapping perimeter and semantics of "inverse of"

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Feature Group is a new aadl v2 concept.
    An AADL feature is part of a component type definition that specifies how that
    component interfaces with other components of the system. Features represent
    ports, subprogram and subprogram group accesses, parameters, and data and
    bus accesses.
    Feature group represents groups of component features, features group can
    contain feature group, and can be use anywhere features can be used. Inside a
    component, each feature can be connected individually, outside a component a
    feature groups can be connected as a single unit.
    A feature group type can be declared to be the inverse of another feature group
    type, which specifies that the feature types will remain the same but that the
    “direction” will be the opposite: so service provided/ required qualifier, flow
    direction, the parameter passing mode will be automatically deduced.
    In UML concept, the notion of port group, as group of ports, doesn’t exist. We
    use a symmetrical solution, meaning the possibility to refine and compose
    interfaces typing ports as alternative to physical connection point assembly.
    The MARTE AADL mapping perimeter will be restricted to data access and
    subprogram access.
    In order to provide a homogeneous representation for designers, align with data
    access and subprogram access, feature group will be represented as an UML
    interface composed by at least two attributes (representing more than one data
    access) or two subprogram access (representing more than one subprogram
    access). By default, the interface is provided.
    UML delegation/assembly connection represents AADL feature group access. In Threads and Processes subcomponents, constituting the system
    subcomponents, internal ports will be typed by interfaces representing the
    FeatureGroup subtypes, like unitary or composed data/subprogram access

  • Updated: Fri, 6 Mar 2015 23:15 GMT

FLOW : MARTE and AADL alignment

  • Key: MARTE11-60
  • Legacy Issue Number: 14865
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The AADL flow path implementation semantics is not in line with MARTE mapping proposition.
    The AADL flow path declaration and implementation mapping need to be rethink

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    AADL flow semantics has been introduced to specify information transmission
    (data/event) over connection and subcomponent, covering the whole component
    and subcomponent hierarchy. This aspect is complementary to the structural
    one.
    Declaration flow paths links flow sources to flow sinks of components in a black
    boxes approach.
    Implementation flow paths specify the way this information is convey over
    connections and flow paths.
    End-to-end flows represent a logical flow of data and control from a source to a
    destination through the system instance, meaning a sequence of threads that
    process and possibly transform the data. The corresponding end-to-end flow
    instance is determined by expanding the flow specifications through their flow
    implementations.
    As UML/MARTE concepts makes a full distinction between logical and structural
    aspects, and while AADL manipulates them jointly, different and not full satisfying
    solutions can be provided to represent AADL flows and end-to-end-flows.
    • UML sequence diagrams, using message exchanges between instances
    and associated ports
    • UML activity diagrams, more focusing on actions and their associated
    control flow. Flow path declaration representation will stay unmodified, using the UML
    “InformationFlow” concept.
    Flow path implementation will be represented in a sequence diagram, using UML
    “GeneralOrdering” elements to keep order preservation between messages
    received and sent over the ports, UML “Messages” will be used to represent
    communication between instances. The Name of the GeneralOrdering element
    will make reference to the FlowPath declaration; the name of the message will
    make reference to the connection conveying it.
    To provide a representative distinction and to avoid code generation ambiguity
    between end-to-end flow and flow implementation representations, both
    represented as sequence diagrams, the first one will be stereotyped “end-to-end
    flow”, the second one, will have the suffix: Flowname_flow_impl.
    AADL flow sinks and flow sources can’t be represented in UML/MARTE.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE AADL annexe

  • Key: MARTE11-59
  • Legacy Issue Number: 14864
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Implied NFP constraint on stereotypes Assign and Allocate

  • Key: MARTE11-58
  • Legacy Issue Number: 14842
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Both stereotypes Assign and Allocate have a properties called impliedConstraint. Do we need this additional attribute because indeed a NfpConstraint being a extension of the UML constraint can be apply on any elements.
    Or if we need, could these properties be derived?

  • Reported: MARTE 1.0 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The intent is to emphasize that allocations and assignments always come at
    price and the costs should be made explicit by some NFP constraints. These
    NFP constraints will then guide the architecture exploration, for instance. Of
    course, constraints can be applied to anything but having an explicit association
    is useful for traceability purpose.
    If you allocation one element to two execution platforms, the costs may be
    different and you need to know which constraint is imposed by which allocation.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Nature and Kind of Allocation and Assignment

  • Key: MARTE11-57
  • Legacy Issue Number: 14841
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Both Allocation and Assigne stereotype use their onw enumerations for defining their nature and kind. For simplification, they should use the same enumerations.

  • Reported: MARTE 1.0 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace AssignmentNature by AllocationNature and remove the definition of
    AssignmentNature.
    Replace AssignmentKind by AllocationKind and remove the definition of
    AssignmentKind

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Example of RtFeature update required

  • Key: MARTE11-56
  • Legacy Issue Number: 14821
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    All examples related to RtFeature in section 13.4.1 are out of date with respect to the definition of RtFeature stereotype that is in Beta 3 associated to a RtSpecification. They have to be updated accordingly.

  • Reported: MARTE 1.0 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue actually refers to figures 13.14, 13.15, 13.16, 13.17, 13.18, 13.19 and 13.20. Most of
    the resolution consists in adding stereotype « rtSpecification » to comments associated with
    «rtfeatures». See details in the revised text.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

GQAM::RequestedService metaclass has no definition

  • Key: MARTE11-55
  • Legacy Issue Number: 14808
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    GQAM::RequestedService metaclass has no definition in Annex F.

  • Reported: MARTE 1.0 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    A subsection must be inserted after F.10.13 with the definition. Also, Fig 15.3 is
    missing the attributes of Step which define the requests, and these should be
    added.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Meta class BehaviorScenario not synchronized with its representation

  • Key: MARTE11-54
  • Legacy Issue Number: 14435
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The description of the Meta class BehaviorScenario is not synchronized with its representation in diagramm shown in FIgure 15.3. As for example, associations called steps in the diagram and called Actions in section F.10.13 (idem issue with assoc labelled inputstream in the section F.10.3 and called cause in diagram 15.3).

  • Reported: MARTE 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

NFP_Constraint metaclass syncho with its underlying stereotype

  • Key: MARTE11-53
  • Legacy Issue Number: 14427
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The stereotype NFPConstraint owns a property to denotes in which modes the constaint is attached. The metaclass NFP_Constraint defined in the domain model of MARTE should be updated to reflect that property.

  • Reported: MARTE 1.0 — Mon, 21 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The domain model already showed the Nfp_Constraint’s relationship to a Mode (Fig. 8.3)
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE domain model: defintion of Trigger

  • Key: MARTE11-52
  • Legacy Issue Number: 14348
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The defintnion of the Trigger concept says: "A Trigger specifies the event and conditions that may trigger a behavior execution.". However, there is nothing in its features (associations or attributes) that will support the concept of condition mentioned in the defintion of Trigger.

  • Reported: MARTE 1.0 — Thu, 3 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This is a conceptual entity, there is no stereotype associated. The semantically closer
    element that have a stereotype is the …. GQAM::GaWorkloadEvent plus its
    GaWorkloadGenerator. They do have the necessary attributes. I suggest Close No
    Change.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Semantics description of TimedObserver

  • Key: MARTE11-51
  • Legacy Issue Number: 14221
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The description of the semantics of TimedObserver in section F10.18 has to be aligned with its description denoted in the diagram shown in figure 15.4. TimedObserver can refer to several start and end events.

  • Reported: MARTE 1.0 — Wed, 26 Aug 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    {Fig 15.4 shows multiplicity * for both start and end events. Sec F10.18 shows
    multiplicity 0..1 for both... this should be changed to *. Since there may be
    several pairs of events, the associations must be ordered to express the
    correspondence. Since the is also an attribute laxity for each pair, it must also be
    multiple and ordered.
    Also there is confusion in the naming of the associations: startObs and endObs
    in the text in F10.18 and of Ch 15 for domain and UML, and startEvent and
    endEvent in the formal definition of F10.18 and in Fig. 15.4, and in the profile
    definition (sec 15.3.2.14). One or the other should be used consistently. Since
    startEvent/endEvent is rather generic, and indeed is also used in the Core
    domain model in another sense, it is preferred to standardize on startObs and
    endObs.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Base unit errors in Figure D.3

  • Key: MARTE-184
  • Legacy Issue Number: 12408
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Base unit errors in Figure D.3 The base unit for "KHz", "MHz", "GHz" and "rpm" is "W" while it is expected to be "Hz". The base unit for "mm" is "bits" while it is expected to be "m". The base unit for "um2" is "bits" while it is expected to be "mm2".

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MARTE 1.0b2
  • Disposition Summary:

    This issue is a duplicate of issue #11338.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

SendFlowAction and FlowSendAction

  • Key: MARTE-183
  • Legacy Issue Number: 12401
  • Status: closed  
  • Source: European Software Institute ( Josetxo Vicedo)
  • Summary:

    Two different terms, SendFlowAction and FlowSendAction, are being used for describing the invocation action related to send a data flow to connected components. Example: see figure 11.5 and 11.6 on pages 120 and 121

  • Reported: MARTE 1.0b1 — Fri, 18 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MARTE 1.0b2
  • Disposition Summary:

    duplicate of issue # 11664, closed issue

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Movement of some stereotypes and attributes from PA to GA

  • Key: MARTE-182
  • Legacy Issue Number: 11811
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    Some stereotypes were introduced in PA because they were identified by these authors as being useful... but they might be equally useful to someone in other analyses.

    An example is the <<noSync>> stereotype on a branch of a par, to say explicitly that this branch does not synchronize at the end of the par. This provides forks that do not join... a performance optimization in some cases.

  • Reported: MARTE 1.0b1 — Sun, 9 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

MARTE PAM Parameters for behaviour demanded by a Step

  • Key: MARTE-181
  • Legacy Issue Number: 11810
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    A PaStep can make a demand for a behaviour, much like a macro, to be included in the Step. An example of the use of this, is to include a complex handshake protocol for exchanging a message between objects on different nodes.

    The profile has

    behaviourDemands: list of Scenarios to be included
    behaviourCount: corresponding list of number of invocations during the step

    It also should support parameters to the Scenario, such as the message size. This requires a way of binding a value in the invocation to a value in the Scenario.

    Possible resolution:

    Add behaviorParm : a corresponding list of tuples. Each element of a tuple could be expressed as (variable=value), with the variable name corresponding to the variable used in the Scenario

    More complex and powerful resolution: Let the context variables decdlared for a Scenario be implicitly regarded as an ordered list of arguments, when the Scenario is invoked. The tuple could then give just the values for the list. A NUL value could be used to mean, do not override the value given within the Scenario.

    The same considerations apply to PAM::externalOpDemands. A similar concern applies to GQAM::servDemands, but the resolution may have to be different as Operations already have arguments and the defining scenario is attached indirectly.

    A broader version of this issue is parameterizing behaviours in general: it seems to be incomplete in MARTE.

  • Reported: MARTE 1.0b1 — Sun, 9 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

MARTE-AADL Issue 5

  • Key: MARTE-98
  • Legacy Issue Number: 11852
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • 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).

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex A: AADL-like models with MARTE

  • Key: MARTE-94
  • Legacy Issue Number: 11848
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    INTRODUCTION (to the following eigth issues) The section “AADL-like models with MARTE” in annex A: “Guidance example for use of MARTE” contains a mapping of UML concepts and stereotypes from MARTE and SysML to AADL metaclasses. The mapping is, in principle, a partial subset that was specified under the following considerations: 1. A UML native concept is used when it is considered expressive enough to represent an AADL concept (e.g., AADL Modes maps to UML State Machines). 2. Else, a MARTE concept is adopted (e.g., MARTE hwBus & hwDevice represents AADL Bus and Device). 3. If neither UML nor MARTE extensions have the corresponding AADL concept, SysML extensions are used (e.g., SysML Block represents AADL System). 4. Otherwise, new stereotypes are proposed in this annex (e.g., subprogram & port-group stereotypes to represents the corresponding AADL concepts). 5. Properties defined in the Predeclared Property Set of the AADL spec. are annotated in a UML Note stereotyped as “properties”. This section also provides some examples illustrating the use of UML (+MARTE+SysML) in order to specify AADL models. Some issues rise from this approach: [MARTE-AADL Issue 1] One general question is the scope of this annex. Either it will keep its “guidance” nature, providing a subset of mapping cases only, or it will provide a more formal mapping covering all AADL concepts and properties. Following a meeting with Peter Feiler (a core AADL author), the goal is to provide a full UML profile for AADL. If the approach turns towards the second option (full support), a more careful exploration of AADL concepts should be done. This means that this annex should guarantee that all the AADL metaclasses are mapped and that, at least, the predeclared AADL property set is supported. The SAE AADL committee supports a full UML profile of AADL. The committee would prefer to have it defined in the context of MARTE rather than a separate UML profile. A draft of a UML profile for AADL exclusively defined in terms of UML exists. This document can be harvested for the MARTE-based profile definition for AADL, e.g., for stereo type names and graphical symbol definitions

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In agreement with Peter Feiler from the SAE, MARTE will provide a full support to the AADL language, meaning that all AADL concepts and properties will be supported by MARTE. Annex A provides "guidelines" explaining and illustrating the use of MARTE for modeling and analysis of AADL applications.
    AADL-MARTE Concept alignment will be addressed by this issue; AADL pre-declared property set alignment will be addressed by issue #11582 and property language alignment with issue #11583.
    A proposed way of using MARTE with different abstraction levels is proposed in issue #11851, differencing design, software platform allocation, and hardware platform allocation phases and concepts. In addition to these refinement processes, analysis views providing specific and reusable analysis information are provided.
    The following table proposes a mapping between AADL and MARTE concepts, without introducing new MARTE concepts (stereotypes) in the annex.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of the Clock stereotype

  • Key: MARTE-93
  • Legacy Issue Number: 11847
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the description of the Clock stereotype, UML::InstanceSpecification should appear as an extension and not a generalization

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In the proposed way

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 4

  • Key: MARTE-97
  • Legacy Issue Number: 11851
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    MARTE is a profile with multiple abstraction levels. For instance, the concept of “Schedulable Resource” appears in the GRM as a high-level abstraction concept (SchedulableResource stereotype), in SRM as an RTOS API specific concept (swSchedulableResource stereotype). Also, some concepts used in GRM are refined with new attributes in the analysis chapters. The choice of MARTE stereotypes to model AADL concepts should be formalized with a set of rules, specifyingwhen to use GRM, SRM, GQAM, SAM stereotypes. This is not an easy task! This also depends on the required AADL Properties to attach in models. Managing the set of properties is indeed not easy. In AADL we have the property set mechanism through which we can introduce new properties that can be associated with existing AADL concepts. As such they enhance the semantics of those concepts and may introduce new concepts. For example, at the SEI we have defined a set of security related properties and associated them with components (system, process, thread, …), ports, and connections. In doing so we represent security related concepts of subjects, object, roles. To us these properties act as annotations to the base architecture model, and their mapping into a analysis-specific model (meta model for security models) understands the mapping of core AADL concepts into analysis-domain concepts. In some cases the existing core architecture concepts are not sufficient; then new concepts can be introduced through the annex mechanism. For example, the error model annex allows users to introduce additional concepts such as “error events” (faults), which exist as separate entities and are associated with core AADL entities. They themselves can have properties as defined through property sets. MARTE, by doing the same in the context of a meta model, e.g., through GQAM, SAM etc., have an explicit way of identifying these analysis specific concepts by name. At the same time when I have an architecture model and want to associate specific analysis interests, I would have to identify the collection of stereo types, some representing the base architecture model, and some the analysis specific abstractions and annotations to bee attached. When I look at the predeclared properties in the AADL standard, they deal with more than one analysis area. We are attempting to subcategorize them. If you have good insight on how to do some of this better, we are looking for input on doing this better on the AADL side as well.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    See issue 11850 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 3

  • Key: MARTE-96
  • Legacy Issue Number: 11850
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    [MARTE-AADL Issue 3] The set of new stereotypes provided in the AADL annex of MARTE (e.g., port group, subprogram, data type) seems to show that MARTE (and UML) does not support some AADL concepts. However: a) AADL Subprogram clearly maps to an UML Operation. More refined Operations can be modelled by “Requested Service” (GQAM chapter, p.263). b) AADL Data concept clearly maps to MARTE MutualExclusionResource (GRM chapter) or SharedResource (SAM chapter). The latter includes additional stereotype attributes useful for schedulability analysis. It may be a combination of both. This brings up the question of what the overlap and difference is between MutualExclusionResource and SharedResource. One represents the mechanism to achieve mutual exclusion, while the second is the entity that may require mutual exclusion in the context of concurrent access.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Summary table, most component and associated features representation and property
    table have been upgraded and aligned: a) on MARTE issues for ports, b) data
    representation, c) data and bus access representations, d) new reference on flow and
    mode sections. Non MARTE stereotypes have been removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex A: AADL-like models with MARTE -- issue 2

  • Key: MARTE-95
  • Legacy Issue Number: 11849
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The use of UML native concepts for some of the AADL constructs should be revised from a pragmatic viewpoint. For instance: a) The use of pure state machines to model AADL operational modes is sometimes insufficient. In the examples provided in MARTE (p.376; ptc/07-08-04), the relationship between a system configuration (modelled by a Collaboration) and a State specifying a Mode, is reflected by the “Name”. I.e., there is no an explicit association between both. It seems that providing a “Mode” stereotype in MARTE, with an appropriate relationship with other modelling elements could be very useful. This would facilitate model extraction/transformation when different kinds of state machines exist in a UML model. The relation between The AADL concepts of “mode transition” and “mode transition trigger” and UML state machines elements should be clarified. b) AADL Flows and EndToEndFlows are modelled by UML Activity diagrams. However, there is already the EndToEndFlow concept in MARTE (SAM chapter), which encloses the same semantics, and furthermore, provides a set of attributes (stereotype properties) that match with the AADL ones (e.g., end-to-end deadline, end to end time). The use of MARTE EndToEndFlows should be evaluated

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    see ptc/2009-05-12 pages 89 - 94

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Enhance the concept of Observer in GQAM

  • Key: MARTE-92
  • Legacy Issue Number: 11846
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: Enhance the concept of Observer in GQAM. Details: The concept of observer is definitely useful although limited to timing and latency. There should be a way to support (at least) throughput and capacity observers. Maybe a more generic mechanism would be useful here?

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    After significant discussion it was agreed in a telecon that the existing stereotype has the desired generality. The necessary extensions should be applied to the existing observer by users, as they need them, rather than trying to define something that will satisfy all needs. All that is needed is to describe this process of extension, and to rename the TimingObserver to TimedObserver, signifying an observation over an interval of time.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to model the size of code occupied in ROM?

  • Key: MARTE-91
  • Legacy Issue Number: 11844
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    How to model the size of code occupied in ROM? There seems to be a missing concept here.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 7

  • Key: MARTE-100
  • Legacy Issue Number: 11854
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Examples provided in the AADL annex of MARTE should be enriched: a) An example on how to model the AADL dispatch protocol with MARTE is missing. b) An example on how to model AADL flows with MARTE is missing c) An example on how to model AADL event-data port with queues and data ports without queues with MARTE is missing. If we go with doing a “real” profile for AADL, then we should probably have two part to that annex, one is the specification of the stereo types making up the AADL concepts (incl. their AADL labels and graphical symbol representation in addition to the UML-based box representation), the second a modelling guide to illustrate the use (like the examples mentioned above). We (the SEI) could work with you on additional examples to show.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    a) An example on how to model the AADL dispatch protocol with MARTE
    is missing.
    Two ways of representing dispatch protocol are possible, depending on
    the abstraction layer and end-user choice.
    A first representation allows mixing application elements and
    resources by attaching a Dispatch protocol attribute and applying the
    stereotype "SwSchedulableResource". For instance, a new property (named
    "dispatch_type") and stereotyped "rtf" can be created in the user model
    view. This dispatch property covers the different AADL dispatch
    protocols: periodic, sporadic, aperiodic, timed, hybrid, background.
    A second representation is to define a model library for AADL threads.
    One class can be defined for each dispatch protocol and the classes are
    used to type parts of a structured classifier. Subprograms can then be
    represented as actions within an Activity and are allocated to the
    parts of the structured classifier, which represent the software
    execution platform.
    b) An example on how to model AADL flows with MARTE is missing
    Flow path in component declaration and implementation have been
    modified. A Flow specification declaration indicates that information
    logically flows from one of the incoming ports, parameters, or port
    groups of a component to one of its outgoing ports, parameters, or port
    group flows.
    Component implementations must provide a flow implementation for each
    flow specification. A flow implementation declaration identifies the flow through its subcomponents. Flow sinks and flow sources are
    implicit, and deduced from flow path implementations. Flow path on
    parameters will not be processed in this version.
    Flow specifications are represented by "UML InformationFlows", which
    represents an abstraction of the communication of an information item
    from its sources to its targets.
    End to end flows are represented by interactions or activities.
    c) An example on how to model AADL event-data port with queues and
    data ports without queues with MARTE is missing
    Resolved in issue 11850, with data, event and data-event port
    semantic clarification and in end-to-end flow definition
    (activity diagram representation)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 6

  • Key: MARTE-99
  • Legacy Issue Number: 11853
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    MARTE provides a language for expressions (VSL), including mathematical, logical, and time expressions. AADL also provides the ability to specify expressions. A detailed mapping should be provided in order to transform VSL expressions into AADL expressions. AADL is more limited in terms of expressions. We tried to not grow the property expressions into a full constraint language but offer the constraint language through the annex mechanism (construct). In this case we may define an AADL annex that covers the constraint expression capabilities of VSL in MARTE. Also in MARTE properties carry meta information about the property values as attributes. At this time in AADL we do not support a general attribute mechanism on properties (properties on properties – although it turns out the meta model of AADL has that in). Here we need to make some decisions on the AADL side. Input on what we should do better on the AADL side is welcome

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    AADL expression language and VSL language are not based on the same
    construction mechanism. These language alignments implies de definition of new
    features on the AADL side, action is not a priority at the moment in the AADL
    communauty.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add short rationale in section 10.3

  • Key: MARTE-107
  • Legacy Issue Number: 11862
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In introduction of section 10.3, a short rationale should be given to explain which meta-classes are extended (in relation with section 7.3 on classifiers and instances).

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add a paragraph after the one in the introduction of section 10.3 explaining the application of the rule in section 7.3 to the extended metaclasses.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explanation in section 7.3 hard to read

  • Key: MARTE-106
  • Legacy Issue Number: 11861
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Section 7.3 is very important to understand how to use of MARTE stereotypes in the following chapter. However, the explanation given here is hard to read. I would suggest rephrasing this specific paragraph.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Rephrase the paragraph conveniently.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In section 2.4.2, the list of extension units and table 7.2 are redundant

  • Key: MARTE-105
  • Legacy Issue Number: 11860
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In section 2.4.2, the list of extension units and the table 7.2 are redundant. I would suggest removing the list of extension units

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    I agree on the redundancy, but I propose to keep the table instead of the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 2.1, I would suggest using the profile names

  • Key: MARTE-104
  • Legacy Issue Number: 11859
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In Table 2.1, I would suggest using the profile names (e.g. Alloc)in the acronym column instead of defining new ones (e.g. ALM). That would may facilitate reading the document.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Agree on the suggestion, see proposed resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 2.1

  • Key: MARTE-103
  • Legacy Issue Number: 11858
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In Table 2.1, I would suggest sorting the extensions units according to the table of content of this document.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Agree on the suggestion, see proposed resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explain 'business management perspective"

  • Key: MARTE-102
  • Legacy Issue Number: 11857
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    I would suggest explaining what is the "business management perspective".

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Strike the phrase "Business Management Perspective" Change it by "system perspective"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 8

  • Key: MARTE-101
  • Legacy Issue Number: 11855
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Modeling the AADL dequeue protocol AllItems seems impossible with UML (and therefore MARTE) because the selection of a behavior on an object node in UML takes only one token at once making it impossible to dequeue/read all the tokens from a queue. The OneItem, AllItems and in V2 also MultipleItems values try to abstractly specify three types of queue processing. It defines what happens to the queue content in terms of making it available to the application and having removed from system buffers. OneItem indicates that one element is removed from the system queue of the port. AllItems means all are removed. MultipleItems means that a detailed behaviour model describes (via the NextValue method how (many) are removed from the system queue.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11854 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support for Views or sets of profile annotations

  • Key: MARTE-128
  • Legacy Issue Number: 11883
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    Schedulability analysis models are built for each real-time situation of interest, and due to the number of different modes of operation of the system or to the number of different worst case equivalent models used to analyze those situations for which there would be no analitical techniques available, the amount of SA models to be annotated over the same UML base model is significant. The profile mechanism in UML provides a way to apply and de-apply a profile to a UML model, but it does not allow to have different colections or groups of stereotype instances (annotations) in a common frame so that they can be store and retrive in the repository, treated as views or "profile applications" of the same profile. In the case of SAM this will be done with the purpose of having different RT Situations, but the same will be valid for a large number of modelling purposes: the phase in the development process, level of detail, different analysis tool or technique to use, or just to assist the modelling processing paradigm. This may be solved in an ad-hoc manner by tools, but a standard (hence interchangable among tools) mechanism is desireble. The NFP types in MARTE may include an additional tag (property) to tie them together, but this tagging should be extensible to any stereotype

  • Reported: MARTE 1.0b1 — Sat, 22 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This issue is duplicated of Issue 11764. Both propose a mechanism to annotate
    multiple value annotations for different situations in a model.
    Disposition: Duplicated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Delay and Offset in SAM

  • Key: MARTE-127
  • Legacy Issue Number: 11882
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    The name-definition of the attribute DelayTime leads to confusion, but if it remains, the profile require a mechanism to express the voluntary relinquish of the CPU during a time. This is what is normally called a delay, this is implemented with primitives like sleep, clock_nanosleep in POSIX, mdelay in linux, delay in ADA, etc. The usage of constraints/observers in this case is not desirable, since these are analysis models not specifications, and contraints will be used for verification against analysis results. A special kind of step that includes offsets and delays is suggested fdor inclusion, even at GQAM level.

  • Reported: MARTE 1.0b1 — Sat, 22 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Be explicit and conformant with existing practice: replace the attribute SaStep::delayTime with three new attributes, SaStep::nonpreemptionBlocking, SaStep::selfSuspensionBlocking, and SaStep::numberSelfSuspensions.
    If an additional specialization of GaStep is needed-and arguably it is-then that SHALL be addressed in a new and separate issue allocated to GQAM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5

  • Key: MARTE-130
  • Legacy Issue Number: 11885
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    a) Inconsistent definition of dataType ArrivalPattern as follows:

    • on page 263, Fig.15.3 and on page 288, Fig.16.3 the definition contains 7 values (the last two are “open” and “close”)
    • on page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5, the same definition contains only 6 values ("open" is missing and should be added).
      Example of use of different arrival patterns: “open” in Fig.17.17 and “closed” in 17.22.
  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There was a mistake in Figures 15.7 (GQAM) and Fig. D.5 (Annex D). The OpenPattern was not included in the list of Arrival Patterns. These two figures will be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consistency between RTEMoCC, SAM, and SRM

  • Key: MARTE-129
  • Legacy Issue Number: 11884
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    As a complement to the explanation of the semantics of RTUnit and PPUnit in RTEMoCC it would be very useful to have a mapping to its corresponding SAM models, and if possible also to its platform independent implementation using SRM, this may be added in an annex specifically dedicated to semantic consistency among these chapters in MARTE.

  • Reported: MARTE 1.0b1 — Sat, 22 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This aspect is definitively out of the scope of the MARTE specification. It
    concerns methodological definitions. Since these model elements represent
    different levels of abstraction (HLAM, SAM, RSM), their mapping is complex and
    can derive in several choices.
    This could be covered by a further work providing some guidelines to help
    methodologists in defining their specific mappings, according to different models
    of computation, development phases, etc. However, this is out of the scope of
    MARTE standard document.
    We propose to close this issue with no change.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing attribute in figure

  • Key: MARTE-133
  • Legacy Issue Number: 11888
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    d) Missing attribute in figure. On Page 333, the second paragraph says:
    “The cycleInit Action has a hostDemand. Since it is not shown in a swimlane, its process (SchedulableResource) is given directly on the Step stereotype by the attribute "concur" (which determines its deployment and thus its host processor).”
    However, Fig 17.17 to which this text refers does not show any attribute “concur”.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add the attribute, which is called concurRes not concur.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

attribute “resMult” of Resource appears under its old name

  • Key: MARTE-132
  • Legacy Issue Number: 11887
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    The attribute “resMult” (resource multiplicity) of Resource appears under its old name “maxRI” in the following figures: 17.14, 17.16, 17.17, 17.24

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Replace the name in the affected Figures.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

use of stereotype names in UML model examples is inconsistent

  • Key: MARTE-131
  • Legacy Issue Number: 11886
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    b) The first letter of a stereotype applied to a UML model element should be lower-case or upper-case (e.g., <<gaScenario>> or <<GaScenario>>) ? The use of stereotype names in UML model examples is inconsistent in different chapters: starting with lower-case in chapters 8, 9, 11, 12, 13, 14, 16, etc. and with upper case in chapters 10 (Figures 10.20 to 10.22), 17.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    By convention, when a stereotype is applied to a model element, the first letter of the stereotype name must be lower-case. In the examples mentioned in the summary of the issue, the first letter of stereotype names must be set to lower-case.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RTF stereotype

  • Key: MARTE-138
  • Legacy Issue Number: 12185
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The RTF stereotype should also extend the Behavior Meta-class

  • Reported: MARTE 1.0b1 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect cross-reference to Figure numbers

  • Key: MARTE-137
  • Legacy Issue Number: 11892
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:
    • Page 325: “In Figure 17.8, the blockingTime ...” - should refer to Figure 17.9.
    • Page 326 the first paragraph: “In Figure 17.9 a simple sequence is annotated”- should refer to Figure 17.10
    • P331 “Figure 17.15 and Figure 17.16” - should refer to figures 17.16 and 17.17”
  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM

  • Key: MARTE-126
  • Legacy Issue Number: 11881
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In HRM, it misses some explanation on how to model mono-port and multi-port memories.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    For modeling such construction, we do not think it requires additional concepts within
    MARTE::HRM. It can be solve using a composite structure with two ports, an in flow port and one
    out flow port for example and modeling a specifying behavior describing the user purpose. So we
    decided to close with no change this issue.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM::HwMemory

  • Key: MARTE-125
  • Legacy Issue Number: 11880
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In HRM::HwMemory, I would suggest adding a throughput attribute (typed by a NFP_DataTxRate) to specificy the notion of throughput in a memory.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    A throughput:NFP_DataTxRate attribute is added to the HwMemory, in both domain view and uml representation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos:

  • Key: MARTE-134
  • Legacy Issue Number: 11889
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:
    • Page 265, the first paragraph: “between the two between”
    • Page 280, the second line from the bottom: “sorrespond”
    • Page 311, the first paragraph: “ypical performance”
    • Page 315, in the middle: “PProcesses”
    • Page 325, in the middle: “avalilable”
  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Corrections are described in the revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect cross-reference to chapter number on Page 309, third paragraph

  • Key: MARTE-136
  • Legacy Issue Number: 11891
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    g) Incorrect cross-reference to chapter number on Page 309, third paragraph:
    “The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 17.”
    GQAM is in chapter 15.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary: {Replace 17 by 15}
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unfinished sentence on Page 313, the sixth paragraph

  • Key: MARTE-135
  • Legacy Issue Number: 11890
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    “Within a scenario these are lumped together as”

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Remove the partial sentence.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM::HwMemory stereotype

  • Key: MARTE-124
  • Legacy Issue Number: 11879
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the HRM::HwMemory stereotype, I would suggest removing the Timing datatype and directly pushing the attributes in the HwMemory stereotype, for the sake of usability

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    cf. resolution of issue 11521.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the GCM chapter should define a causality model for flows

  • Key: MARTE-86
  • Legacy Issue Number: 11839
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: the GCM chapter should define a causality model for flows. Details: the GCM chapter introduces the notion of flow port as a structural feature of a structured class. However, the specification does not states what happens when a flow comes into / get out of a flow port. There should be a reference to behaviors owned by this structured class. Proposed resolution: enhance the GCM chapter.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This issue concerns the semantics of FlowPorts and indeed its underlying causality model.
    Indeed, the issue 11840 is also clearly related to this issue. Issue 11840 summary is following:
    “Subject: Support for flows in activities. Details: The current specification provides a limited
    support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction
    stereotype. However, there is no way to indicate the pins used to define the data to send. At the
    same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It
    seems that activity parameters are an interesing alternative to specify incoming and outgoing
    flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the
    FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through
    activity parameters (maybe a stereotype would need to be defined here).” Both issues are treated
    in this document."
    As stated by Conrad Bock in [Conrad Bock: “UML 2 Activity and Action Models Part 4: Object
    Nodes”, Journal of Object Technology, vol.3, no.1, pp.27-41], there are traditionally two ways for
    considering dataflow communications:

    • a “pull” semantics with the following characteristics:
      o Passive: the arrival of data in the data store does not trigger behaviors per se. It
      is indeed additional actions, for example time-triggered actions, that when
      needed pull the data from the data store. o Non-depleting: the use of data in the store does not remove it from the store
    • a “push” form of data flow and storage, with the following characteristics:
      o Active: the arrival of data in the data store triggers execution of some behavior.
      o Depleting: the data arriving on the port is not store locally. Data is indeed
      conveyed to the triggered behavior.
      The objective of this resolution is to enable GCM's users to address both forms of data flow. For
      that purpose, we are making the following proposal:
    • Data sending:
      o The «SendFlowAction» stereotype is removed (NOTE: in this case, one resolves
      in the same time the issue 12286. This latter was then set to Duplicate/Merged
      and refer this resolution). Indeed, the standard UML SendObjectAction is already
      well suited to express a data emission. The execution of a SendObjectAction
      results in the emission of a message encapsulating the sent object (which can be
      an instance of any classifier). Note that, SendObjectAction inherits from
      InvocationAction and as defined in the composite structure package, this action
      already enables to specify a target port for the action (see, UML2 spec., section
      9.3.9 on p. 182).
      o In addition to specify the flowProperty on which a SendObjectAction is applied (or
      more generally to specify the feature of a non-atomic FlowPort or
      ClientServerPort on which an InvocationAction is applied), one introduces the
      «GCMInvocationAction» stereotype which extends InvocationAction (from
      InvocationActions). In this case, the stereotyped invocation action targets a nonatomic
      flow FlowPort or a featureBased ClientServerPort (i.e. a ClientServerPort
      which have been specified using a ClientServerSpecification. Cf resolution 11820
      for a precise definition of these concepts), and one of its features. For example, if
      a non-atomic output flowport has two flow properties (i.e. it is typed by a
      FlowSpecification with two out flow properties), the ‘onPort’ property of
      SendObjectAction enables to specify that this flow port is used as a target of the
      send. In addition, the ‘onFeature’ property of «GCMInvocationAction» enables to
      specify which of the two flow properties the target of the send is.
    • Data reception events: Once we have dealt with data sending, it is also required to be able to deal with
      data receipt. For that purpose, we introduce the «DataEvent» stereotype. This
      latter extends the UML's AnyReceiveEvent metaclass. This metaclass is the
      most generic kind of concrete MessageEvent. DataEvents are raised when data
      (which have been sent as a consequence of a SendObjectAction) are received
      on a behavioral FlowPort. In the case of a non-behavioral FlowPort, data are
      propagated along associated delegation connectors, and no event is raised at all
      (just as for standard UML Ports). DataEvents raised as a consequence of data
      receptions on behavioral ports are then stored in the event pool of the owning
      object just like any other kind of UML events would be. It implies that the UML
      semantic variation points related to event management also applies to
      «DataEvent» (and typically concerning the way events are ordered in and
      extracted from the event pool). This is however fully in line with the philosophy of
      the GCM which aims to be as generic as possible. Particular semantic
      interpretation on the way DataEvent are dispatched and consumed would thus
      require a specialization of the GCM, such as the one proposed in the HLAM subprofile
      of MARTE. The definition of «DataEvent» mimics the definition of the UML
      SignalEvent metaclass, in the sense that it is possible to attach a classifier to the
      event in order to characterize it (just as it is possible to attach a Signal to a
      SignalEvent). More precisely, the classifier that can be attached to the event
      must be a classifier that can be used to type flow ports or flow properties (i.e.,
      DataType and Class). In order to avoid confusion with SignalEvent, a constraint
      imposes that the classifier associated with the DataEvent cannot be a Signal.
      DataEvents can then be exploited by triggers of transitions within a
      StateMachine, or by triggers of AcceptEventActions within an Activity. Hence, it is
      possible to specify reactions to reception of data of a particular type (i.e., data
      which are typed by a classifier compatible with the classifier associated with the
      DataEvent). Note that such triggers can natively be related to particular ports i.e.,
      the ports from which the DataEvent have been raised.
      o UML Triggers can natively be related to a particular port. Additionally, in MARTE,
      we introduce the possibility to specify more precisely the origin of a trigger. The
      «GCMTrigger» stereotype is defined for that purpose. It extends the UML Trigger
      metaclass and it owns a property that enables to specify which feature of the
      FlowSpecification of a FlowPort or ClientServerSpecification of a
      ClientServerPort (cf. resolution 11820 for details on ClientServerPort) is the
      origin of the trigger. It is thus possible to specify reactions that are, for example,
      related to the occurrence of a given DataEvent on a non-atomic FlowPort, and for a particular FlowProperty. Of course this advanced mechanism is mainly
      interesting for non-atomic port, because in other cases, there are no possible
      ambiguities.
      The concepts denoted below were defined to support the “push” semantic of MARTE's ports
      (including flow and client-server ports), and they are well aligned with the standard event model.
      The “active” characteristic of the «push» semantics is covered because the reception of a data on
      a behavioral FlowPort raises a DataEvent, which can be used as a trigger in a behavior. The
      “depleting” characteristics of the "push" semantics is covered because, according to the standard
      UML semantics, once an event has been consumed by a behavior, it is no longer available in the
      event pool to trigger other behaviors.
      Concerning the “pull” semantics of MARTE's FlowPorts, no particular extensions are required. A
      simple modeling pattern (suggested by SysML and Conrad Bock’s article, respectively for the
      usage of delegation connectors and the usage of properties for persistent data storage and nondepleting
      data use) is indeed sufficient as explained next.
      According to the UML 2 superstructure, a non-behavioral port should have delegation connectors,
      so that incoming requests can be propagated along these connectors to parts of the composite
      structure owning the port (in other case as said previously and as it is defined in the UML2
      specification, messages are lost). Then there are two possibilities for the parts connected to the
      ports: either they delegate also the requests to some of their parts, or they deal directly with the
      request triggering the execution of one of their behaviors. This case fits also with the MARTE's
      client-server port and it is thus reasonable to have a similar mechanism for MARTE's flow ports.
      At the end of the delegation chain, a non-behavioral input atomic flow port should have at least
      one delegation connector targeting a part which is type-compatible with the port (if there is no
      delegation connector, the data is simply lost). When a data is received on such a port and then
      delegated through the connector, no DataEvent is raised (which is in line with the “passive”
      aspect of the “pull” form of data flow). In this case, the semantics says that the data is written in
      the part targeted by the delegation connector, replacing any existing value. The data stored on
      the targeted properti can then be used when needed by the behavior of the component, typically
      via a ReadStructuralFeatureAction (which has no depleting effect on the value of the property).
      For more complex storage policies, we propose to introduce the « DataPool » stereotype. Two
      default storage and selection policies are defined: LIFO and FIFO. « DataPool » can also be
      associated with user-defined policies, via its ‘insertion’ and ‘selection’ properties. These
      properties explicitly reference UML Behaviors, respectively describing how a data is to be
      inserted in the property, and how a set of data is to be selected from the property. When a data is
      received on a FlowPort with a delegation connector targeting a property stereotyped with
      «DataPool», the semantics says that the data is inserted in the pool following the description provided by ‘insertion’ behavior (Concerning the usage of the ‘selection’ behavior, see the
      following description concerning the usage of connectors between properties and behavior
      parameters).
      This rule can be extended for non-atomic flow ports, where each flow property should be
      associated with a delegation connector (by convention, when one of the flow properties is not
      associated with a delegation connector, the FlowPort should be behavioral, and data received on
      this FlowPort and related to this FlowProperty will raise a DataEvent).
      Finally, issue 11840 proposes the possibility of an explicit “binding” between flow ports of a
      component and parameters of the component behaviors. This additional proposition is an
      alternative solution to the mechanisms described below. Moreover, let's notice that SysML is
      relying on this mechanism, but SysML is lacking two points: firstly, SysML does not define indeed
      clearly how that works (i.e., either by name matching between ports and parameters, or
      (probably) by using a BindingConnector), and secondly SysML does define also it’s the clear
      meaning of this mechanism. Hence, we provide next a clear semantics for this mechanism
      aligned (i.e., compatible) with the “pull” and “push” semantics we have considered until now:
    • “pull” semantics: A standard UML connector is expressed between a property (which
      used to be the target of a delegation connector, but does not need to be) of the
      component and an IN or INOUT parameter of a behavior or operation (which would
      typically belong to the owner of the port, but does not need to be). It means that the
      values passed to the parameters of the behavior (or operation) when the behavior is
      called are actually the values of the connected properties. The connectors just prevent
      from the usage of an explicit ReadStructuralFeatureAction to get the value associated
      with the properties. Note that this usage of connectors is compatible with the abstract
      syntax of UML, since both Property and Parameter are ConnectableElements. In the
      case where the connected property is stereotyped with « DataPool », its ‘selection’
      Behavior is used to compute the values to be selected (from the property) and to be
      passed to the parameter.
    • “push” semantics: Connectors are directly expressed between input non-behavioral flow
      ports (respectively the output flow ports) and input parameters (respectively the output
      flow ports) of the classifierBehavior Activity of the composite structure owning the ports.
      The idea is that each incoming data received on a flow port will be propagated to a
      parameter of the classifier behavior. The data associated with the input message will be
      handled as a token on an ActivityParameterNode corresponding to the parameter. The
      token will then enter the chain of computation described by the set of object flows and
      actions of the activity (with respect to the token propagation semantics of UML activities). At the end of the computation chain, tokens will be propagated to
      ActivityParameterNodes corresponding to output parameters of the Activity. If a
      delegation connector is modeled between such a parameter and an output flow port of
      the composite structure, a message containing the produced data will be emitted through
      the flow port (just as if SendObjectAction with this value would have been applied on the
      flow port). The standard semantics of UML activities implies that tokens related to
      required input parameters must be available for the called activity to start, and that token
      corresponding to output parameters will be made available on corresponding output pins
      once the activity is finished. Note that if one wants the activity modeling the classifierbehavior
      to be able to accept inputs (on its input parameters) and produce outputs (on its
      output parameters) while it is executing, input and output parameters of the activity
      should typically be specified as streaming parameters. Examples are provided in the
      revised text.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Giving an attribute a variable name and an expression value

  • Key: MARTE-75
  • Legacy Issue Number: 11822
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    I am not clear of the status of this, but it seems that to use the profile flexibly one needs to be able to assign a variable name to an NFP, and also a value. Then the variable name can be used to change the value in studies, in a traceable way. The value can be an expression too.

    A possible resolution would be to allow expressions to read as variable = expression.

  • Reported: MARTE 1.0b1 — Wed, 19 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Resolution:

    This is already supported by VSL: A 'variable declaration' expression can have assigned an "initialExpression". Concretely, the following syntax has been adopted in VSL (page 402):

    <variable-declaration> ::= <variable-direction> '$' <variable-name> [<type-name>] ['=' <init-expression>]

    This means that you can have NFP values such as (extended notation):

    myLatency = (value= 5.0, expr= $var1=var2+var3/3, unit=ms) or the short notation:
    myLatency = (5.0, $var1=var2+var3/3, ms)

    Hence, this issue is close with no change.

    Revised Text:
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ports in GCM

  • Key: MARTE-74
  • Legacy Issue Number: 11820
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    This issue is about ports in GCM. In UML if a port is typed with an interface, this interface is automatically considered as provided by the port (see port description section 9.3.11 in UML Superstructure). In GCM it is possible to type a MessagePort with an interface (BFeatureSpecification). Moreover if a MessagePort direction is specified to be "required", and if the port is typed with a BFeatureSpecification interface, this interface contents are considered to be provided by the port according to UML. This results in a confusing specification: a MessagePort specifying a required interface provides that interface at the same time.

  • Reported: MARTE 1.0b1 — Wed, 19 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Using message ports may create redundancy and inconsistency with the UML composite
    structures, as mentioned in the summary of this issue. Indeed, BFeatureSpecification can own
    FlowBFeatures, where some of the features may have their ‘’kind’’ set to ‘’provided’’, and some
    others set to ‘’required’’. According to UML interface derivation rules, this may lead to ambiguous
    cases where a BFeatureSpecifcation (used to type a message port) is considered to be provided
    by the port, even if some of the behavioral features of the BFeatureSpecification actually
    represent ‘’required’’ features. A similar problem appears when a message port, with direction set
    to Required, is typed by an interface (i.e. the default rule in UML is that this interface is supposed
    to be provided by the port). [Note: More generally, the issue described here also concerns
    non-atomic flow ports, i.e. flow ports that are typed by a FlowSpecification. According to
    UML interface derivation rule, the FlowSpecification used to type the port would also be
    considered as a provided interface.].
    The proposed resolution for issue 11820 is designed according to the following guidelines:
    • it provides a mechanism for specifying provided and required interfaces of standard UML
    ports, in a way that is more intuitive and direct that the standard UML mechanism (which
    relies on derivation rules based on the port type, and which is particularly tedious for defining
    interfaces required by a port. Indeed, it technically implies to define a Classifier with a « use » relationship that targets the set of Interfaces to be required). It was indeed the original
    motivation for the ClientServerPort stereotype.
    • it should avoid conflicts with default UML rules concerning interface derivation, based on port
    type.
    The general idea behind the proposal is that ClientServerPorts can be used in different ways. The
    current solution explicitly identifies two usages (c.f. definition of /isAtomic = true or false) whereas
    in the resolution we identify three potential usages according to designer intent:
    • atomic usage: the designer wants to directly associate a signal with the port (i.e. the port is
    typed by the signal), specifying that the component owning the port is either able to send (i.e.
    ClientServerPort::kind = required) or receive (i.e. ClientServerPort::kind = provided) the signal
    via this port.
    • interface-based usage: the designer wants to directly provide and/or require standard UML
    interfaces on a port.
    • feature-based usage: the designer wants to associate a ClientServerSpecificaion (i.e. a
    consistent set of behavioral features, some of which may be provided or required) with the
    port.
    Additionally, issues 12802 (difference UML Port and MessagePorts) and 12801 (semantic
    difference between an atomic FlowPort typed by a signal and a MessagePort typed by a signal)
    have been stated as duplicate/merge with this issue. We provide a resolution for these issues in
    the revised text of the GCM chapter, described in this document. For issue 12802: Some text is
    added to explain that ClientServerPort (formerly MessagePort) is just a kind of syntactic sugar for
    UML Ports. Concerning issue 12801: we explain that FlowPorts and ClientServerPorts are almost
    semantically equivalent when signals are used to characterize their potential interactions (i.e.
    atomic FlowPort typed by a signal S, atomic ClientServerPort typed a signal S, or non-atomic
    ClientServerPort exposing a Reception for a signal S).
    Additionally, issue 12579 (that has been stated as duplicate/merge with this issue) concerns the
    renaming of elements (i.e. FlowBFeature) that are involved in the definition of MessagePort itself.
    We start this ‘’merged resolution’’ with the resolution of issue 12579.
    The primary reason of this name was to have a name constructed in a similar way than to the one
    of the FlowPorperty but dedicated to BehavioralFeature. I (Me, Sébastien Gérard, the original
    author of that concept) agree that this name is may be not the best one…
    Moreover as similar concepts exist in AUTOSAR, a very important standard for automotive
    domain and with which it is expected that MARTE will have strong relationships in near future, I
    propose to do following renamings:
    • FlowBFeature => ClientServerBFeature • BFeatureSpecification => ClientServerSpecification
    • MessagePort => ClientServerPort
    PS: I propose not only to rename FlowBFeature, but also the other concepts related to
    MessagePort, for global consistency of the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What are semantics of real-time features on provided/required interfaces?

  • Key: MARTE-85
  • Legacy Issue Number: 11838
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:
  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This resolution proposes general clarifications on the usage of the stereotype
    «RtFeature» (including its usage and underlying semantics in the context of
    provided/required interfaces).
    The stereotype «RtFeature» can be applied to multiple elements Additionnaly, issue 12954 also requires some clarifications. These clarifications
    require modifications to figures that are modified in this resolution. We therefore
    propose to resolve problems identified in issue 12954 in this document, and we
    state resolution to issue 12954 as duplicate/merge with this resolution 11838.
    More specifically, issue 12954 has identified the following problems: 1- In figure
    3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. : In the proposed
    modification of figure 3.10, this inconsistency is removed. 2- In section 13.3.2.8
    the stereotype «RtFeature» is said to extend the UML Behavior element;
    however in section 3.10 this extension is not shown. : In the proposed resolution,
    «RtFeature» does not apply anymore to behavior. 3- Figure 3.11 does not show
    all the attributes of the «RtAction» stereotype. The new version of figure 3.11
    proposed in this resolution includes all the attributes. 4- The use of the
    stereotype «RtBehavior» is not clear. An example in 13.4 would be of great help.
    This stereotype has been deleted. Its attributes are indeed only characterizations
    of the event pool of an active object. Its attributes have been added to
    «RtFeature», and prefixed with ‘sr’ (for Schedulable Resource).
    (InvocationAction, BehavioralFeature, Message, Signal). In order to clarify to
    meaning of these multiple extensions, some text is added in the section
    describing the stereotype «RtFeature» to explain that: the most basic element on
    which «RtFeature» can be applied is InvocationAction, and that any other places
    where this stereotype is applied enables to specify a kind of default value in the
    case where the stereotype «RtFeature» has not been applied on a particular
    InvocationAction.
    Additionnaly, the title of this issue suggests that real-time features could be
    contextual to the usage of interfaces (for example, one may want to specify that a
    real-time feature concerns an operation of an interface that is provided on a
    given port). Therefore, we propose the following modifications:
    The stereotype «RtFeature» is modified so that it now also extends the Port
    metaclass. The stereotype «RtSpecification» is introduced, and it extends the
    Comment metaclass.
    All the attributes of «RtFeature» are removed from «RtFeature», and they are
    added to «RtSpecification».
    An «RtFeature» can now own multiple «RtSpecification», and it is possible to
    specify the behavioral feature that is concerned by this «RtSpecification». For
    example, a port can be stereotyped with «RtFeature». It can then own multiple
    «RtSpecification», where each of these «RtSpecification» may concern a
    behavioral feature of a provided or required interface of this port.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

chapter 11 (GCM) should be moved in the Part II of the specification

  • Key: MARTE-84
  • Legacy Issue Number: 11837
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: chapter 11 (GCM) should be moved in the Part II of the specification. Details: The argument to push GCM in Part I of MARTE was that it was used BOTH for modeling and analysis. After having read the whole document, I do not see any dependency from the GQAM to GCM therefore I suggest pushing back GCM in Part II of MARTE (the design part) to make the MARTE foundations thiner. Proposed resolution: move chapter 11 in Part II and update the chapter number accordingly.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed according to the proposed resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Find a better name of the RTEMoCC profile

  • Key: MARTE-83
  • Legacy Issue Number: 11836
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: Find a better name of the RTEMoCC profile. This acronym is long and does not sound pretty fancy. I would suggest looking for a better alternative.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Replace RTEMoCC with "High-level Application Modeling" and use the acronym of "HLAM"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RTEConnector should be removed from RTEMoCC

  • Key: MARTE-82
  • Legacy Issue Number: 11835
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: RTEConnector should be removed from RTEMoCC The chapter 13 defines a model of computation for active objects and passive objects. It precisely defines the metaclasses involved in this model of computation, building upon the MARTE foundation packages (e.g. GRM). Additionally, chapter 13 introduces the concept of RteConnector, which is basically a specialization of a UML connector with additional NFP. While the definition of active/passive object provide useful features for RTES design. The concept of real-time connector is more discutable. This concept overlaps with GRM::CommunicationMedia. It seems that all that relates to NFP characterics of a communications between entities should be defined in GRM::CommunicationMedia (latency, jitter, bandwith) As a beneficial side effect, removing RTEConnector whould remove the depdendency from RTEMoCC to GCM, which is not usued anywhere else. Proposed resolution: remove RTEConnector metaclass and stereotype and push the related attributes (bandwith, blockT, packetT, transMode) into GRM (e.g., in CommunicationMedia).

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Remove RTEMoCC::RteConnector and refactor GRM::CommunicationsMedia to gain the attributes of the deleted RteConnector, and update the elements that use similar attributes in the rest of the spec so that they become consistent, that is at least in HwMedia.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure E.10 (p 468):

  • Key: MARTE-81
  • Legacy Issue Number: 11834
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    the fitting of the toTiler should be 0,0.

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Change the fitting as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to model the size the heap size of an Ada runtime with SRM?

  • Key: MARTE-90
  • Legacy Issue Number: 11843
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    How to model the size the heap size of an Ada runtime with SRM?

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    An attribute must be added to the MARTE::SRM::SW_Concurrency::swConcurrentResource.
    heapSizeElements: UML::Kernel::Classes::TypedElement [0..*]

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HwMedia.bandwidth attribute may need to be generalized in GRM ancestor clas

  • Key: MARTE-89
  • Legacy Issue Number: 11842
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: HwMedia.bandwidth attribute may need to be generalized in a GRM ancestor class. Details: According to another issue, the RTEConnector.bandwidth attribute could be pushed from RTEMoCC::RTEConnector to GRM. If so, it would make sense to factorize the HwMedia.bandwith with a common ancestor (the concept of "bandwith" being SW/HW agnostic). Proposed resolution: remove the bandwidth attribute from HwMedia and push it into a GRM ancestor class.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The proposed resolution shall be followed and inserted in the resolution of issue 11835.

    The bandwidth attribute should be removed from HwMedia and placed in CommunicationMedia in GRM with a more general explanation. This solution unfortunately may impact terminology in future GQAM variations, where different names are used for the same concepts. Now the conflict is not present since there is not direct inheritance. Considering that issue 11835 is in the same ballot all changes should be consistently indicated to vote for them in that issue. Hence this is now in the scope of Issue 11835.

    Revised Text:
    See issue 11835, where explanation of attribute GRM:: CommunicationMedia should include a text like :

    bandwidth: NFP_DataTxRate [0..1]
    the capacity of the communication element when applicable

    Disposition: Duplicated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tiler stereotype (pp 465,466

  • Key: MARTE-79
  • Legacy Issue Number: 11832
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    a default value should be specified for the various attributes as it is done for the TilerSpecification data type; the type of the tiler attribute should be TilerSpecification

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add various default values in the descriptions of the stereotypes as in the TilerSpecification and modify the type of the tiler attribute to TilerSpecification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Shaped stereotype (pp 464,465):

  • Key: MARTE-78
  • Legacy Issue Number: 11831
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    a notation to refer to a particular element of a shaped collection by index should be added. Proposal: use ElementName[index].

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proposal: use ElementName[index].

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to model the amount of memory occupied by an OS resource

  • Key: MARTE-88
  • Legacy Issue Number: 11841
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: How to model the amount of memory occupied by an OS resource (eg. File, buffer, blackboard, ARINC ports). Details: We would need to know the memory used by OS objects (buffer, sem, blackboard…). This maybe needs further discussion but why not introducing a memorySizeElements attribute on SwResource? It might be also applicable on a GRM::Resource ?

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support for flows in activities

  • Key: MARTE-87
  • Legacy Issue Number: 11840
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: Support for flows in activities. Details: The current specification provides a limited support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction stereotype. However, there is no way to indicate the pins used to define the data to send. At the same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It seems that activity parameters are an interesing alternative to specify incoming and outgoing flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through activity parameters (maybe a stereotype would need to be defined here).

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    See issue 11839 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reshape stereotype (pp 463,464)

  • Key: MARTE-77
  • Legacy Issue Number: 11830
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    the default topology of a link connecting two shaped elements should be specified. Proposal: use a direct element-wise topology when the shapes of both ends are identical, undefined otherwise

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proposal: use a direct element-wise topology when the shapes of both ends are identical, undefined otherwise.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure E.6 (p 460)

  • Key: MARTE-76
  • Legacy Issue Number: 11829
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    the two composition links from the Reshape stereotype to the Tiler Stereotype should be removed

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Replace figure E.6 by removing the two composition links from Reshape to Tiler.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

E.4 Examples (pp 467,468):

  • Key: MARTE-80
  • Legacy Issue Number: 11833
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    put square brackets around the shapes on the diagrams

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Correct all the diagrams of the examples to add the required brackets.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex A3

  • Key: MARTE-159
  • Legacy Issue Number: 12297
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    This section needs to be completed.

  • Reported: MARTE 1.0b1 — Wed, 19 Mar 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    See issue 12577 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimingObserver in GQAM should be renamed to TimedObserver

  • Key: MARTE-158
  • Legacy Issue Number: 12283
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    s discussed in the telecon today, the TimingObserver in GQAM should be renamed to TimedObserver, and the text should show that it can collect any measure, including time intyervals but also energy memory etc, over an interval bounded by two events.

    This is a separate issue from 11775 which suggests moving this concept to the Time chapter.

  • Reported: MARTE 1.0b1 — Tue, 18 Mar 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary: {The TimedObserver may be extended to return any statistical measure on any NFP over the interval from the startEvent to the EndEvent}
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify a maximum number of period for periodic real-time constraints

  • Key: MARTE-161
  • Legacy Issue Number: 12402
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    It would be nice to be able to specify a maximum number of period for periodic real-time constraints. Proposed modification: add a property named max of type Integer (multiplicity 0..1) in PeriodicPattern tupleType on page 437.

  • Reported: MARTE 1.0b1 — Mon, 21 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add a new parameter for the periodic arrival pattern indicating the number of occurrences. This parameter is optional: multiplicity 0..1. So, it doesn't need to be specified in the graphical view.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-GQAM) Kinds of delay in a Step

  • Key: MARTE-160
  • Legacy Issue Number: 12371
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    Generated, based on extensive discussion, to deal with the issue raised in 11882, whose resolution is only for SAM.

    There are two kinds of delay in a step
    ... self-initiated delays like sleeping or thinking or some latency included in the step,
    ... blocked delay waiting for an event initiated by some other thread of behaviour

    The latter is represented by the domain concept Step.blockingTime, which is the profile property gaStep.blockT.

    The former is not represented. It should be added.

    Proposed resolution:

    1. In GQAM, add the domain property Step.selfDelayTime:NFP_Duration and the profile property gaStep.selfDelayT:NFP_Duration.

    Add text to the domain model to explain selfDelayTime

    Add the definition of selfDelayT to the UML representation.

    2. In PAM examples, many Steps have internal delay represented as a value of blockT, all of these should be changed to selfDelayT.

  • Reported: MARTE 1.0b1 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    1. In GQAM, add the domain property Step.selfDelay:NFP_Duration and the profile property gaStep.selfDelay:NFP_Duration.

    Add text to the domain model to explain selfDelayTime

    Add the definition of selfDelay to the UML representation.

    2. In PAM examples, many Steps have internal delay represented as a value of blockT, all of these should be changed to selfDelay.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE name prefixes

  • Key: MARTE-155
  • Legacy Issue Number: 12249
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    There is no consistent convention followed in the beta document for naming of stereotypes and their attributes, and this has been pointed out in other issues. Some chapters use a prefix for the chapter, such as Pa or pa for performance analysis, Grm or grm for General Resource Model, etc. MOst do not.

    From the point of view of precision, fully qualified names are sufficient, but from the point of view of usability, the prefixes are very helpful, especially as MARTE is such a big profile and realtime is a cross-cutting concern. THat is (unlike sysml) the profile does not redefine UML or restrict it to the domain of realtime, but adds realtime info to a functional design. MARTE may be used with other profiles, possibly several at once.

    The usability issues are to identify the realtime stereotypes and attributes, and also to avoid cluttering the namespace. A stereotype attribute may become a property of an object and its name might conflict with a functional property. Users might avoid MARTE just to avoid the risk of this happening.

    Issue: Consistency in prefixes is desirable, either all stereotypes with prefix, or none. Usability is affected. Realtime concerns are pervasive and crosscutting in software, so flooding of the namespace could be a problem, including conflict with other profiles and with functional property names.

    Proposed resolution:
    Apply two or three prefixes to all stereotypes and attributes:

    mm for MARTE Modeling
    ma for MARTE Analysis
    possibly mc for MARTE Core.

    Where a stereotype is specialized from another one, a third letter could be used.

    Alternative proposal:
    Apply prefixes only to the analysis chapters, because these are more likely to be used outside the embedded system domain (e.g. for enterprise system QoS) and thus to be used with other stereotypes. For instance to specify requirements on delay.

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In order to decide when we need to prefix the name of element, we propose to
    apply the following algorithm as much as possible:

    • When we define a stereotype which name may conflict with the UML2
      metaclass the stereotype is extending. In this case, we prefix with the
      name of the sub-profile wherein the stereotype is defined.
    • When we define a stereotype generalizing an already defined stereotype
      of MARTE. In this case, we should use the name of the profile wherein the
      stereotype is defined to prefix this latter.
    • Finally, we should not use "_" between the prefix and the name of the
      prefix. This rule should apply also for the name of the concepts of the
      domain model. However, there is an exception to this rule: we will not
      rename the predefined NFP type (the one define in the MARTE library
      such as NFP-Real) because they are used all along the specification and
      the change will need too much work w.r.t. to the global interest to do it.
      Let's note that, we consider that that as an editorial issue and we will not provide
      the complete revised text for the resolution because it would be too big. The
      editor of the specification (Sebastien Gerard) will do the required modifications
      directly in the specification when integrating all other resolutions voted within this
      FTF2
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clock stereotype needs to extend UML::Property

  • Key: MARTE-167
  • Legacy Issue Number: 12414
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The Clock stereotype would need to extend UML::Property along with UML::InstanceSpecification, in order to make use of clocks in composite structures and interactions. This way, the Time chapter would be compliant with the "instance/classifier" pattern defined for resources.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Property is added as a base class for Clock

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BFeatureSpecification constraint

  • Key: MARTE-166
  • Legacy Issue Number: 12413
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In section 11.3.2.2, the constraint [1] is not applicate to BFeatureSpecification (it applies to FlowSpecification, defined in another section of the chapter). Proposed resolution: revise or delete the constraint.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This issue actually refers to section 12.3.2.2 (11.3.2.2 refers to the numbering of an older
    version). This resolution does apply to FlowSpecification and not to ClientServerSpecification.
    The constraint has then to be moved. A new constraint is added ClientServerSpecification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type NFP_Weight does not exist

  • Key: MARTE-164
  • Legacy Issue Number: 12410
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    HwComponent stereotype has a property named "weight" typed by "NFP_Weight". The type NFP_Weight does not exist in the document.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This NFP type was missing in the MARTE library.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConstraintKind not documented

  • Key: MARTE-163
  • Legacy Issue Number: 12409
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The enumeration ConstraintKind defined in Figure 8.5 is not document in section 8.3.2

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The description of the Enumeration ConstraintKind is missing

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE needs naming conventions for stereotype names and tag values.

  • Key: MARTE-169
  • Legacy Issue Number: 12416
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    MARTE needs naming conventions for stereotype names and tag values. As discussed during the FTF meeting in DC, we need to define chapter-wide naming conventions for stereotype names and tag values. Consequently, we need to apply these conventions to the whole document.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    See issue 12249 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the nature of DRM

  • Key: MARTE-168
  • Legacy Issue Number: 12415
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    What is the nature of DRM in the MARTE specification? Details: There is no DRM profile in the description of the architecture of MARTE (Figure 6.4). On the other hand, looking at the first Figure (14.1) of Chapter 14, one can see a DRM package that includes the HRM and SRM packages. That may create confusion on the nature of DRM. We would need to clarify this at the begining of Chapter 14, or update Figure 14.1

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Delete the figure 14.1 and consequently modify the introduction of the chapter
    14. See revised text in the next section that intents to clarify this point.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no link between GRM::SchedulableResource and SRM::SwSchedulableResource

  • Key: MARTE-157
  • Legacy Issue Number: 12282
  • Status: closed  
  • Source: THALES ( Eric Maes)
  • Summary:

    There is no link between GRM::SchedulableResource and SRM::SwSchedulableResource ! When modeling, much of SwSchedulableResource elements are also ScedulableResource elements and then, attributes such as host (GRM::SchedulableResource) and scheduler (SRM::SwSchedulableResource) are redundant. SRM::SwSchedulableResource should derive from GRM::SchedulableResource.

  • Reported: MARTE 1.0b1 — Mon, 17 Mar 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This is a duplicated issue, explained in Issue 11411.
    Revised Text:
    See resolution of Issues 11411, and 11856.
    Disposition: Duplicated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2.7

  • Key: MARTE-156
  • Legacy Issue Number: 12264
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The stereotype FlowSendAction enable to define an action for sending a data via port. The given textual syntax defined for the label of the action does support that feature. However, the stereotype itself (for the abstract syntax point of view) does not have any property to model that point. Resolution => add an attribute to the stereotype: viaPort: Port [0..1]

  • Reported: MARTE 1.0b1 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11839 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dispatch protocols

  • Key: MARTE-162
  • Legacy Issue Number: 12404
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Most common dispatch protocols can be modelized by the ArrivalPattern like (sporadic, aperiodcc,periodic, burst, irregular) ? The possibility to introduce other one is missing (exemple "Background).

  • Reported: MARTE 1.0b1 — Tue, 22 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There is a misunderstanding here. “Background” is not an arrival pattern. The
    term background is related to task scheduling aspects. In MARTE, periodic
    server scheduling parameters are modeled with a set of parameters including
    background priority.
    In MARTE, we compiled all the arrival patterns used in real-time and embedded
    systems, including, periodic, aperiodic, sporadic, bursty, but also more general
    arrivals like irregular patterns for arbitrary distances between event occurrences,
    probability distributions, and other used in performance evaluation such as open
    and closed patterns. Additional patterns can be defined by extending the libraries
    of arrival patterns (Figure D.5)
    We propose to close this issue with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"proreq" / "reqpro" literals do not exist in Beta 1

  • Key: MARTE-165
  • Legacy Issue Number: 12412
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    "proreq" / "reqpro" literals do not exist anymore in Beta 1. Details: The example in Figure 11.7 refers to a "reqpro" literal that does not exist anymore. In section 11.3.2.4, the constraint [3] refers to a "proreq" literal that does not exist anymore. Proposed resolution: remove references to these literals.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SAM: General

  • Key: MARTE-70
  • Legacy Issue Number: 11780
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    SAM: General] Time-triggered system modelling are supported in some way by the TimeTableDriven scheduling policy (fig 10-19). However, it is not clear how to specify a table (format) and where (e.g. Scheduler stereotype, schedule: OpaqueExpression attribute?). Some examples for time-triggered system modelling should be provided in MARTE.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Schedulers of the other variants of SchedPolicyKind use configuration parameters which are expressed in the SchedulableResource::SchedParameters attributes. To be consistent, when modeling TimeTableDriven scheduling, the SchedParameters stereotype SHALL include a tag definition SchedParameters::tableEntry of type OpaqueExpression which SHALL store the information necessary to schedule the SchedulableResource according to the algorithm of the Scheduler's time-triggered, table-based scheduling.

    The algorithm of the time-triggered, table-based scheduler SHALL be expressed within the Scheduler::schedule's OpaqueExpression.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM, GQAM, SAM: DomainModel & Profile

  • Key: MARTE-69
  • Legacy Issue Number: 11779
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GRM, GQAM, SAM: DomainModel & Profile] A number of non-functional properties for scheduling analysis are specified by a worst-case and a best-case duration value. The MARTE library for NFP types defines a NFP_BoundedDuration data type. This type could be used to type ‘bounded’ durations in SAM. For instance: endToEndTime (fig. 16-7), execTime (fig. 10-18), latency (fig. 15-8), contextSwitchTime, ISRswithTime (fig. 16-9).

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This two attributes may be not sufficient, it is better to have all the statistical qualifiers over multiple values of NFP_Duration supported. To minimize editorial impact and a deep revision of side effects, the additional attributes provided in NFP_BoundedDuration will be added to NFP_Duration. With the variation that "min" will be represented as "best" and "max" as "worst", this keeps the dual dimension in the utilization of multiple values and the specification of variability in the context in which the value is used. This implies minimal changes to NFP_Duration, eliminating NFP_BoundedDuration, and change the only reference to it (in RealTimeFeature) to NFP_Duration.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NFP: value syntax

  • Key: MARTE-71
  • Legacy Issue Number: 11781
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [NFP: value syntax] It may be useful to have a shorter (graphical) notation for NFP types including the value and unit slots only, e.g., ‘(55, kHz)’, or still ’55 kHz’, instead of the notation ‘(55, -, kHz, max, -, est, -)’ with all the qualifiers. This will enhance the graphical models readability. While this feature may be only a tool-specific mechanism, which could propose a graphical view (short notation) of the repository notation (full notation), it would be useful to standardize this notation in the MARTE spec.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We include this syntax (value-unit) only as a tool-specific feature to show NFP values in graphical models. This means that the syntax defined in VSL is still valid for NFP values (tuple notation). The reason is that the model repository needs to keep all the required NFP value information (value, unit, plus other qualifiers).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1 MARTE spelling missing in the introduction

  • Key: MARTE-73
  • Legacy Issue Number: 11818
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    MARTE spelling missing in the introduction possible resolution: introduce the term MARTE in the introduction of the document MARTE: Modeling and Analysis of Real-Time and Embededd systems

  • Reported: MARTE 1.0b1 — Thu, 13 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Can be added as a subtitle on the cover page.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: HRM

  • Key: MARTE-72
  • Legacy Issue Number: 11817
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Some stereotype in the HRM profile do not have icons. And the icons proposed in the specification need to be improved to clarify the understanding of the model. possible solution: change icons on HRM and add icons on stereotype do not have yet

  • Reported: MARTE 1.0b1 — Thu, 13 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    I (Sébastien Gérard) have asked to the source of the issue what kind of
    improvement he was requiring or if he had some better proposition of
    iconographical representation, and he answered he had no proposals of
    improvement. I decided then without more feedback on graphical improvement to
    close with no change this issue.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.3.1

  • Key: MARTE-140
  • Legacy Issue Number: 12196
  • Status: closed  
  • Source: THALES ( Eric Maes)
  • Summary:

    Proposition to extend the probability distributions functions list with (used in AnyLogic) : - geometric (double p) The Geometric distribution is a discrete distribution bounded at 0 and unbounded on the high side. It is a special case of the Negative Binomial distribution. In particular, it is the direct discrete analog for the continuous Exponential distribution. The Geometric distribution has no history dependence, its probability at any value being independent of a shift along the axis. - laplace (double phi, double beta) The Laplace distribution, sometimes called the double exponential distribution, is an unbounded continuous distribution that has a very sharp central peak, located at theta. The distribution scales with phi. - chi squared (double nu, double min) The Chi Squared is a continuous distribution bounded on the lower side. Note that the Chi Squared distribution is a subset of the Gamma distribution with beta=2 and alpha=nµ/2. Like the Gamma distribution, it has three distinct regions. For nµ=2, the Chi Squared distribution reduces to the Exponential distribution, starting at a finite value at minimum x and decreasing monotonically thereafter. For nµ<2, the Chi Squared distribution tends to infinity at minimum x and decreases monotonically for increasing x. For nµ>2, the Chi Squared distribution is 0 at minimum x, peaks at a value that depends on nµ, decreasing monotonically thereafter. - rayleigh (double sigma) The Rayleigh distribution is a continuous distribution bounded on the lower side. It is a special case of the Weibull distribution with alpha =2 and beta/sqrt(2) =sigma. Because of the fixed shape parameter, the Rayleigh distribution does not change shape although it can be scaled. - weibull (double alpha, double beta, double min) The Weibull distribution is a continuous distribution bounded on the lower side. Because it provides one of the limiting distributions for extreme values, it is also referred to as the Frechet distribution and the Weibull-Gnedenko distribution. - logistic (double beta, double alpha) The Logistic distribution is an unbounded continuous distribution which is symmetrical about its mean [and shift parameter], alpha. The shape of the Logistic distribution is very much like the Normal distribution, except that the Logistic distribution has broader tails. - pareto (doubla alpha, double min) The Pareto distribution is a continuous distribution bounded on the lower side. It has a finite value at the minimum x and decreases monotonically for increasing x. A Pareto random variable is the exponential of an Exponential random variable, and possesses many of the same characteristics. - triangular (double min, double max, double mode) The Triangular distribution is often used when no or little data is available; it is rarely an accurate representation of a data set. However, it is employed as the functional form of regions for fuzzy logic due to its ease of use. - cauchy (doubla lambda, double theta) The Cauchy distribution is an unbounded continuous distribution that has a sharp central peak but significantly broad tails. The tails are much heavier than the tails of the Normal distribution. - beta (double p, double q, double min, double max) The Beta distribution is a continuous distribution that has both upper and lower finite bounds. Because many real situations can be bounded in this way, the Beta distribution can be used empirically to estimate the actual distribution before much data is available. Even when data is available, the Beta distribution should fit most data in a reasonable fashion, although it may not be the best fit. The Uniform distribution is a special case of the Beta distribution with p, q = 1. - lognormal (double mu, double sigma, double min) The Lognormal distribution is a continuous distribution bounded on the lower side. It is always 0 at minimum x, rising to a peak that depends on both mu and sigma, then decreasing monotonically for increasing x. - erlang (double beta, int m, double min) The Erlang distribution is a continuous distribution bounded on the lower side. It is a special case of the Gamma distribution where the parameter, m, is restricted to a positive integer. As such, the Erlang distribution has no region where F tends to infinity at the minimum value of x [m<1], but does have a special case at m=1, where it reduces to the Exponential distribution. - negativeBinomial (double p, double n) The Negative Binomial distribution is a discrete distribution bounded on the low side at 0 and unbounded on the high side. The Negative Binomial distribution reduces to the Geometric Distribution for k = 1. The Negative Binomial distribution gives the total number of trials, x, to get k events (failures...), each with the constant probability, p, of occurring. - logarithmic (double beta) The Logarithmic distribution is a discrete distribution bounded by [1,...]. Theta is related to the sample size and the mean. - hypergeometric (int ss, int dn, int ps) The Hypergeometric distribution is a discrete distribution bounded by [0,s]. It describes the number of defects, x, in a sample of size s from a population of size N which has m total defects. The ratio of m/N = p is sometimes used rather than m to describe the probability of a defect. Note that defects may be interpreted as successes, in which case x is the number of failures until (s-x) successes. The sample is taken without replacement.

  • Reported: MARTE 1.0b1 — Thu, 24 Jan 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We need to be sure that the new distributions functions are really necessary in
    MARTE. Note that we do not attempt in MARTE to define all the existing
    distribution functions but the required in common practice.
    After evaluating some performance analysis and simulation tools, we consider
    that the following one are highly decided, and propose to include them in the
    MARTE library. geometric (real p). The Geometric distribution is a discrete distribution
    bounded at 0 and unbounded on the high side.

    • triangular (real min, real max, real mode). The Triangular distribution is
      often used when no or little data is available; it is rarely an accurate
      representation of a data set.
    • logarithmic (real theta). The Logarithmic distribution is a discrete
      distribution bounded by [1,...]. Theta is related to the sample size and the
      mean.
      Further distribution functions can be added at library level.
      Issue Dependency Warning: Note that this issue affects Issue 12561, which
      clarifies the mechanism to specify probability distribution expressions. Issue
      12561 depends on this issue, but the reverse case is not true.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

stereotype attribute "GaExecHost.throughput" that is not documented

  • Key: MARTE-139
  • Legacy Issue Number: 12194
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In GQAM, the profile diagram (Figure 15.6) defines a stereotype attribute "GaExecHost.throughput" that is not documented in section 15.3.2 or introduced in the domain model (Figure 15.5)

  • Reported: MARTE 1.0b1 — Wed, 23 Jan 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add to Domain model and document it. Add to Fig 15.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section Allocation: Wrong direction of the allocation

  • Key: MARTE-142
  • Legacy Issue Number: 12214
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Wrong direction of the allocation: The MARTE allocation mechanism is directly inspired from SysML. SysML has chosen a convention contrary to UML and draws the arrow from the suppliers (usually a target) to the clients (usually a source). So as to be compatible MARTE has followed SysML with that convention. Now, the SysML RTF is considering that this triggers too many problems with tool vendors and thus considers using the same convention than UML. An alignment between SysML and MARTE is required as much as possible and MARTE FTF should then think through this issue and adopt the same convention than UML.

  • Reported: MARTE 1.0b1 — Thu, 7 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The only text that was wrong has been removed in the resolution for issue 11770. The new text in this resolution assumed that sources are referred as clients and targets are referred as suppliers.
    This resolution has no impact on any other section since the wrong "direction" was only in the vocabulary used (clients vs. suppliers) and the graphical notation was already correct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

using $ in naming variables

  • Key: MARTE-141
  • Legacy Issue Number: 12209
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    This editing issue affects many chapters.

    In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name.

    Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning.
    Examples are found in NFP (Fig 8.9) and many other chapters.

    These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement.

    In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples

  • Reported: MARTE 1.0b1 — Mon, 4 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call' expression, we use only the name. We really need to make difference between both because VSL parsers need to distinguish them.

    a) Arguments to use 'let' as keyword in variable declarations:

    The use of '$' is not 'conventional' to declare variables. Other keywords like 'let [variable-name]' would be more appropriate. It is recommended to use 'let ' for variable declaration because having a keyword for declaration is the more natural choice in most of languages.

    b) Arguments to use '$' as part of the variable name in variable call expressions:

    The absence of the symbol '$' in variable call expressions ("variable use") would make hard to make the distinction with other 'names' in VSL expressions, such as enumeration literals or PropertyCallExpression. The goal of this symbol in the former SPT profile was to identify easily a variable within an expression. With the current notation, the latter is not possible.
    .
    c) Arguments against a modification of variable notation

    Some reasons would suggest avoiding such a modification:

    • VSL has an essential difference with other conventional languages: VSL is intended to be used in 'properties values', where compact annotations should be privileged. Also, its use in Constraints tries to mark a difference with OCL, and it's that annotations should be shorter and easier to understand. Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language.
    • The UML Time Observation notation works exactly like VSL variables. A symbol ('@' for time observation and '&' for duration observation) is used for declarations, and only the name (without the symbol) for expressions. Time observations could be considered as a sort of variables, but with a more specific semantics. So, having the notation of both VSL variables and Time Expression aligned is important for comprehensibility of Profile users.

    -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that the variables will be easily identified in a model, because they will include the '$' symbol.

    • VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions.

    d) Conclusions

    The argument for using 'let' is more to follow conventional languages, and not pragmatic concerns. Also, the argument that the current mechanism confuses comprehensibility between variable declaration and variable call expression is not sustainable. VSL variable notation works exactly as UML TimeObservation works, and there were not reported any issue related to confusing language users.

    For these reasons, we suggest to close this issue with no change.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow".

  • Key: MARTE-146
  • Legacy Issue Number: 12232
  • Status: closed  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow". While this issue is specific to the cited text, it SHOULD be applied throughout the specification whereever attributes are so named. The rationale for the change is that the substitution of numerals such as "1", "2", and "4" for the non-numeric concepts expressed by the truncated words "a", "to", and "for", respectively, lead to needless cognitive dissonance. CamelCase is acceptable but there is no longer any need for variable names which use substitutions and truncations to satisfy machine or language constraints.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the suggested modification.
    The only place where a numeral is used as substitute of words is in the stereotype "SaEnd2EndFlow" and in two of their attributes.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

expressing requirements

  • Key: MARTE-145
  • Legacy Issue Number: 12231
  • Status: closed  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    When expressing requirements that implementations of the MARTE Profile MUST satisfy, the specification SHALL use Requirements Engineering statements which are de facto best current practices. For example, the phrase in the fourth paragraph, of 16.3.1, reads: BEGINQUOTE An "SaEnd2EndFlow" will make reference implicitly to one ore [sic] more GQAM "GaWorkloadEvent" and to one "GaScenario" commonly by means of a containment relationship (owned elements) or allocation stereotypes. ENDQUOTE This is expressing a Business (or Domain) Rule (as expressed in Figure 16.3) which implementations of the Profile must enforce. However, the sentence is too passive and is not sufficiently imperative to communicate this requirement. The recommendation is to replace such ambiguous and passive phrasing with the de facto standard SHOULD, MUST, SHALL phrasing now employed in RFCs and in Requirements Specifications. For example, replace the wording above with: BEGINQUOTE Every implementation of the MARTE Profile SHALL enforce that each 'SaEndToEndFlow' MUST refer to one or more GQAM_Workload::WorkloadEvent(s) and MUST refer to one and one only GQAM_Workload::BehaviorScenario. These references SHALL be achieved directly via Composition or indirectly via the <<allocation>> association. ENDQUOTE While this issue is written specifically for the cited text, the recommendation SHOULD be applied throughout the entire specification whereever the specification is expressing how the Profile MUST be implemented. There is no need for this formalism in the sections of the specification that provide rationale and explanation--that is, within the Domain Modeling sections. The rationales for this formalism are: it greatly reduces ambiguity, profiles are more than collections of individual decorations, domain rules "cut across" sets of domain elements, and a subset of tools extant can enforce such domain rules if those rules are known, expressed, and consistent.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimingResource of GRM

  • Key: MARTE-144
  • Legacy Issue Number: 12225
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    My concern is about the TimingResource of GRM. In the domain model (10.2.2, p.89-90 and figure 10.7), TimingResource both refers to a Clock (since it is a Resource) and specializes ChronometricClock. The specialization is not suitable since a TimingResource is not a clock (with the meaning given in the Time profile) but merely refers to a Clock. To make a TimingResource specific to chronometric clocks, it is largely sufficient to refine the association to a Clock by an association to a ChronometricClock. In the UML representation (Figure 10.15) and in 10.3.2.20 I would simply remove the specialization to ClockType. The reference to a Chronometric Clock (idealClock in this precise case) is already implicit by the use of the NFP_Duration type. If you really want to insist on the use of chronometric clock only, a comment in the text should do it.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We propose to remove the specialization from TimingResource to
    ChronometricClock in the domain view. In the UML representation, we remove
    the specialization from ClockType. This latter specialization is very problematic
    since Resource extends several metaclasses (Property, InstanceSpecification,
    Classifier, Lifeline, Connectableelement) and ClockType only extend Class.
    The specializations are not required since a TimingResource being a resource
    can already access to information of Clocks (including if required,
    ChronometricClocks).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3 and 17.3

  • Key: MARTE-143
  • Legacy Issue Number: 12220
  • Status: closed  
  • Source: THALES ( Eric Maes)
  • Summary:

    Inconsistencies concerning the <<GaStep>> prob stereotype attribute multiplicity: - In figure 15.7 "UML extensions for GQAM stereotypes related to behavior", p 271, it is [0..1], - In <<GaStep>> profile element description (§15.3.2.13), p280, it is [0..*], - In figure 17.7 "Profile diagram of performance extensions for workload, behavior and time observations", p 318, it is [0..1], - In <<PaStep>> profile element description (§17.3.2.15), p323, it is [0..1]. As a consequence, in PAPYRUS, it is [0..1] and in RSA, it is [0..*].

  • Reported: MARTE 1.0b1 — Wed, 13 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    [0..1] is correct, so it is changed in sec 15.3.2.13 where it is written [*]. Other
    attributes in that section:
    ... blockT
    ...selfDelay
    ...rep
    are also written [*] when they should be [0..1], and these are changed also. They
    are correct in Annex F.10.17.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Correct the inconsistency between the diagram and the text

  • Key: MARTE-147
  • Legacy Issue Number: 12233
  • Status: closed  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    Sentence 1, paragraph 2, on page 295 begins: BEGINQUOTE "GaTimingObserver" specializes "NfpConstraint", and the latter extends UML Constraints... ENDQUOTE However, Figure 16.8, page 295, expresses that GQAM::GaTimingObs [sic] extends not specializes MARTE::NFPs::NfpConstraint. Several recommendations follow: 1. Correct the inconsistency between the diagram and the text. I suspect that the text should say "extends" rather than "specializes". 2. Consistently name the element GQAM::GaTimingObserver. 3. In text which refers to elements, always use a qualified name-it need not be fully qualified when there is a common parent scope in effect for the context of the text-and never use quoted "nicknames" or, worse, arbitrary alternate, similar names. 4. Replace the cited paragraph entirely with a paragraph which describes the Schedulability Analysis Module's profile and which isn't suspiciously similar to a cut-n-paste from the related GQAM material. 5. If Timing Observers move to a more common subprofile outside of GQAM, then refactor this section appropriately.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Revise figures and text according to the following considerations (each
    numbered point is related to the corresponding numbered item above):
    1. Update figures with the Specialization relationship instead of the Extension
    relationship between NfpConstraint and GaTimedObserver. This has to be done
    in both Chapters GQAM and SAM, and in both sections Domain View and UML Representation View. Also, in Figure 16.5, the association ends startObs and
    endObs are not valid anymore. In the FTF1, they have changed by startEvent
    and endEvent respectively.
    2. GQAM::GaTimingObserver is an old name that was changed in FTF1 by the
    name GQAM::GaTimedObserver. This has to be updated in all figures and text
    throughout Chapter SAM.
    3. Edit all incorrect aliases for GQAM::GaTimedObserver appropriately. Never
    use quoted "nicknames". The affected section is only Section 16.3.1.
    4. The cited paragraph doesn’t exist elsewhere in the MARTE specification.
    5. Timed Observers have not been moved to a more common sub-profile. So, no
    additional modifications are required.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B (VSL)

  • Key: MARTE-154
  • Legacy Issue Number: 12248
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    There are the following mistakes in the VSL grammar: obsCallExpression (section B.3.3), instead of obs-call-expression value_specification (section B.3.3.10), instead of value-specification

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Fix these typos:

    -Rename obsCallExpression (section B.3.3), by obs-call-expression

    -Rename value_specification (section B.3.3.10), by value-specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 288: change explanation

  • Key: MARTE-153
  • Legacy Issue Number: 12247
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    When explaining the semantics of the stereotype atributes 'EndToEndDeadline' and 'EndToEndTime' of an EndToEndFlow (page 289), it is clarified that these measures apply "only one input end-to-end stimuli exist". However, an end-to-end flow can have several execution end points (e.g., an activity diagram with more than 'one activity end' node). So, it is necessary to precise better the semantics of these two attributes. A resolution could be to add at the end of the first paragraph of page 289 something like: "...stimuli exist and only one finalization Step exists".

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the proposal to clarify semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

picture 11.8, ports "loc" and "ftp"

  • Key: MARTE-149
  • Legacy Issue Number: 12240
  • Status: closed  
  • Source: AdaCore ( Matteo Bordin)
  • Summary:

    On picture 11.8, ports "loc" and "ftp" are typed with the type of the interface they require (instead of a classifier requiring the interfaces). Probably the names "loc" and "ftp" are for the ports, but the type is for the (required) interface.

  • Reported: MARTE 1.0b1 — Wed, 20 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The port "loc" and "fp" are defined in Figure 11.18 and not in Figure 11.8. Still, the issue is totally relevant and the Figure 11.18 is updated according to the proposed resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 64 ClockConstraintSpecification

  • Key: MARTE-148
  • Legacy Issue Number: 12237
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    On page 64 ClockConstraintSpecification is said to be specified in CCS, but if you take a look in CCS (p.420) it is referenced as an element from Time::TimeRelatedEnt ities::ClockConstraints.

  • Reported: MARTE 1.0b1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Change in Figure C.2. ClockConstraintSpecification is now defined in CCS
    package and no longer refer to Time::TimeRelatedEntities

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 16.2.2 (SAM)

  • Key: MARTE-152
  • Legacy Issue Number: 12246
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    The first paragraph of page 289 makes reference to 'isSchedulability', which is wrong. The right name is 'isSchedulable'.

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    revise this mistake

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM-SAM cyclic dependency due to GQAM::WorkloadBehavior

  • Key: MARTE-151
  • Legacy Issue Number: 12245
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [SAM] There is a cyclic dependency between packages GQAM and SAM at Domain Model level due to SAM adds an association (workload: EndToEndFlow) in GQAM::WorkloadBehavior. The model needs to be revised. A simple resolution could be to remove the association as far as the owning relationship already exist between WorkloadBehavior and the owned elements of EndToEndFlow (i.e., WorkloadEvent and BehaviorScenario)

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We decided to proceed with the proposed resolution by the source

  • Updated: Fri, 6 Mar 2015 20:58 GMT

VSL variable declaration (inconsistency between the BNF and the metamodel)

  • Key: MARTE-150
  • Legacy Issue Number: 12242
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: VSL variable declaration (inconsistency between the BNF and the metamodel) Details: The direction of a VSL variable is refered as optional in the metamodel (multiplicity of 0..1) while it is presented as a mandatory term in the BNF. Proposed resolution: Change to BNF to turn variable declaration into an optional term.

  • Reported: MARTE 1.0b1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with proposal: change the BNF to do direction of variable declaration an optional term.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM Domain view inheritances

  • Key: MARTE-171
  • Legacy Issue Number: 12418
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    In the GQAM Domain view GQAM::GQAM_Resources::CommunicationHost should inherit from GRM::ResourceTypes::CommunicationMedia, and GQAM::GQAM_Resources::ExecutionHost should inherit from GRM::ResourceTypes::ComputingResource. This said from a conceptual point of view, seems to indicate that also the corresponding elements in the profile should keep this inheritance relationship with the corresponding elements in GRM. The names of attributes should be consistent or at least related semantically to those in GRM. This may required some minor structural changes since in GQAM platform elements include semantics form various elements in GRM like for example the scheduler as well as the processing resource.

  • Reported: MARTE 1.0b1 — Fri, 25 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Include in GQAM::GQAM_Resources::CommunicationHost the inheritance from GRM::ResourceTypes::CommunicationMedia. And in GQAM::GQAM_Resources::ExecutionHost inheritance from GRM::ResourceTypes::ComputingResource. Correspondingly update the profile, making GQAM::GaExecHost inherit from GRM::ComputingResource, and GQAM::GaCommHost inherit from GRM::CommunicationMedia.

    According to issue 11835 already resolved in ballot 2, some attributes in GQAM::GaCommHost are now inherited from GRM::CommunicationMedia, these attributes are:
    o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicable.
    o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize.
    o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum.
    o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values:

    {simplex, half-duplex, full-duplex}

    .
    The only difference is in the name of the attribute "bandwith" which is called "capacity" in GQAM. Since both of them represent the same concept one of the two should prevail; "capacity" is preferred as it is more general. As mentioned, this impact previous resolution of issue 11835, and as a duplicated also issue 11842.

    Attributes schedPolicy and isPreemptible in SaExecutionHost and SaExecHost are now redundant since they are inherited transitively from Scheduler.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM Observers: inconsistency between domain view and UML representation

  • Key: MARTE-170
  • Legacy Issue Number: 12417
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    GQAM Observers: inconsistency between domain view and UML representation Details: In the domain view (Figure 15.4), the Timing/TimedObserver has two properties startObs and endObs, typed by MARTE::Time::TimedInstantObservation. In the UML profile diagram (Figure 15.8), the related GaTiming/TimedObserver has two properties startObs and endObs, typed by UML::TimeObservation. In the UML profile description (p.281), the same GaTiming/TimedObserver has two properties startObs and endObs, typed by MARTE::Time::TimedInstantObservation. We need to choose whether a timed observer relates to a MARTE TimedInstantObservation or UML TimeObservation, and then to align the domain view, profile definition and profile description accordingly.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In the conceptual domain model, we rely in MARTE "concepts", independently of
    whatever UML construct. For that reason we use the concept coming from the Time
    chapter.
    However, in the profile view, it is permissible to use the UML corresponding metaclass,
    because there is no reason to constraint such TimedObservers to Observations
    stereotyped with the MARTE Time concepts. (The time concepts add the notion of
    clocked Observation (attribute "clock"), which are not essential here). We agreed with
    Charles Andre that such a stereotype should not be mandatory when
    defining a TimedObserver.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimedDomain stereotype

  • Key: MARTE-173
  • Legacy Issue Number: 12497
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    Resolution of issue 12414 introduced two base metaclasses for
    stereotype Clock (InstanceSpecification and Property).
    The TimedDomain stereotype has to be changed to support the case of
    Clock being a Property extension.
    The OCL rule number 1 has also to be updated.

  • Reported: MARTE 1.0b1 — Fri, 16 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Change the metaclass of TimedDomain from Package to Namespace in Figure
    9.26. Also change Extensions of TimedDomain (9.3.2.5). No need to change
    OCL rule for this issue because there is no ocl rule associated with
    TimedDomain, but see issue 12498 for indirect change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wrong multiplicity in sharedResources required for a SaStep

  • Key: MARTE-172
  • Legacy Issue Number: 12428
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Julio Medina)
  • Summary:

    This might be an editorial issue since it is correct in section F but not in SAM. In the association sharedResource from SaStep to SAM_Resources::SharedResource (see Figure 16.4, page 289 in SAM)change multiplicity from 0..1 to * , This is correct and well explained in the Domain description in Annex F (Section F.11.3 page 609) but Figure 16.4 and the description in sections 16.3.2.3 and probably 16.3.2.8 must be adjusted.

  • Reported: MARTE 1.0b1 — Tue, 6 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The resolution of this issue makes consistent the domain and UML views of SAM in the aspect of sharedResources linked to steps. It complements resolution of Issue 11778 stating consistently that a SaStep may require multiple passive shared resources to be locked during its execution.
    First it is necessary to change from 0..1 to * the multiplicity in the association sharedResource that exists between SaStep and SAM_Resources::SharedResource in Figure 16.4, page 289 in the domain view of SAM. Then align the profile correspondingly by correcting the pictures in Figure 16.7 or Figure 16.9, and insert the description of the association as it is in Section F.11.3 page 609 in the description of the stereotype SaStep in page 298. In the GRM domain view it is necessary also to change to 0..* the multiplicity of MARTE::GRM::ResourceUsages::ResourceUsage.usedResources so that it may admit incomplete definitions of usages. For consistency it is convenient also to extend the multiplicity of requiredAmount to 0..*.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 10.18

  • Key: MARTE-178
  • Legacy Issue Number: 12537
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    We have detected a difference between domain analysis "ResorceUsage" concept, the stereotype diagram in figure 10.18 and the stereotype description in 10.3.2.13. The association between ResourceUsage and Resource is unidirectional according to figure 10.13 and sections 10.3.2.12 and 10.3.2.13; however in figure 10.18 this association is shown as bidirectional.

  • Reported: MARTE 1.0b1 — Thu, 19 Jun 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The UML representation for resourceUsage maps the domain view in a more practical
    way. However, the navigability from resource to resourceUsage might be removed in
    Figure 10.18 to be consistent with the definition of resource (section 10.3.2.12) which is
    agnostic with respect to its usages.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistencies in GQAM

  • Key: MARTE-177
  • Legacy Issue Number: 12536
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    A number of inconsistencies have been detected in the GQAM subprofile description. The GaScenario stereotype description changes from the domain description section to the UML stereotype description sections (15.2.2.1, 15.3.1 and 15.3.2.12).

  • Reported: MARTE 1.0b1 — Thu, 19 Jun 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The differences are mostly in style of expression rather than substance,
    particularly in a property being expressed as an attribute in a diagram, because it
    is geometrically awkward to show an association. Attributes and associations are
    equivalent properties. There are two differences: (b3) timing is correctly represented in Fig 15.3 by an association
    (b4) timing is missing from the stereotype on p 283, and should be added.
    (a) GaWorkloadEvent has five properties:
    in Fig 15.3 in Fig 15.7 in stereotype p 286
    • pattern: attrib attrib attrib
    • generator: assoc attrib attrib
    • trace: assoc attrib attrib
    • timeEvent: assoc assoc attrib
    • effect assoc attrib assoc (proposed in resolution of
    issue 12538)
    The textual stereotype is consistent with the meaning of both diagrams, so no
    change is necessary.
    (b) The stereotype GaScenario in Figure 15.7 has attributes “cause” and “timing”
    which are not correctly represented in Fig 15.3 and in the stereotype on p 283.
    (b1) cause is represented in Fig 15.3 by the association inputStream. This should
    be changed to cause
    (b2) cause is not represented in the stereotype at all, it should be added.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex D.2

  • Key: MARTE-180
  • Legacy Issue Number: 12561
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    We have found that the current format for modelling probability distributions is not very good is some cases. For example, it is hard to model correctly the probability distribution related to a SporadicPattern. We propose that distributions are modelled as a ProbabilityDistribution <<choice_type>> element, with each probability distribution modelled as a <<tuple_type>> element each with the parameters needed (e.g. Uniform <<tuple_type>> should have 2 parameters: a min:NFP_Real and max:NFP_Real).

  • Reported: MARTE 1.0b1 — Thu, 3 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There is a misunderstanding in the way MARTE deals with probability distribution
    expressions. This is, in any case, a weak aspect in the description of such
    specification mechanism in MARTE. This resolution proposes to clarify this
    aspect, by adding an example in the NFP chapter and by making explicit the list
    of distributions in Annex D.
    In addition, this issue proposes to complete the textual description of all the
    NfpTypes included in the library MARTE_NfpTypes.
    Issue Dependency Warning: Note that the texts and figures provided in this
    issue depend on Issue 12196, which proposes new probability distributions.
    Thus, if Issue 12196 is not accepted, these new probability distributions need to
    be removed from the texts and figures proposed in this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in definition of GaEventTrace and GaWorkloadEvent

  • Key: MARTE-179
  • Legacy Issue Number: 12538
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    Errors in definition of GaEventTrace and GaWorkloadEvent. In page 275, the stereotype <<GaEventTrace>> has an association defined as "stream" which does not appera in figure 15.7. Moreover no multipicity is defined for such association. In page 271, in figure 15.7 stereotype <<GaWorkloadEvent>> a property called "effect" can be read; however the semantics behind this property cannot be found anywhere, nor in page 282 nor in the domain description (section 15.2).

  • Reported: MARTE 1.0b1 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    (a) This association is handled differently in Fig 15.7: GaWorkloadEvent has an
    attribute trace of type GaEventTrace, with default multiplicity 1. Thus the stream
    association can be removed from GaEventTrace.
    (b) There are two problems identified here.
    (b1) GaWorkloadEvent has an association effect:GaScenario in Fig 15.3, and
    also in Figure 15.7, with default multiplicity 1. This should be represented in the
    stereotype on p 286. If it is stated as an association then the constraint among
    the other four attributes is still correct.
    (b2) in Figure 15.7, GaWorkloadEvent is lacking the attribute
    timeEvent:UML::timeEvent[0..1] which is shown in the stereotype on p 286, it
    should be added to the figure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wrong numbering of figures

  • Key: MARTE-175
  • Legacy Issue Number: 12513
  • Status: closed  
  • Source: CATS CO., LTD. ( Shuji Kawasaki)
  • Summary:

    p.316, l.13: "Figure 17.5" should be Figure 17.6 p.325, l.7: "Figure 17.8" should be Figure 17.9 p.326, l.1: "Figure 17.9" should be Figure 17.10 These are a part of my MARTE errata. Since I cannot write them all here, I will send the errata file by E-mail to pubs@omg.org.

  • Reported: MARTE 1.0b1 — Wed, 28 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL rules for the Clock stereotype

  • Key: MARTE-174
  • Legacy Issue Number: 12498
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    Resolution of issue 12414 introduced two base metaclasses for
    stereotype Clock (InstanceSpecification and Property).
    The OCL rules [2] has to be changed to deal with both base metaclasses
    (The present rule deals only with InstanceSpecification).

  • Reported: MARTE 1.0b1 — Fri, 16 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Distinction has been done in ocl rules according to the base metaclass of Clock.
    Rule 1 is no longer valid (because change in issue 12497)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The tiler stereotype should be applied on the UML::Port metaclass

  • Key: MARTE-176
  • Legacy Issue Number: 12514
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The tiler stereotype should be applied on the UML::Port metaclass. Tilers are currently applicable on connectors and connector ends, along with instances (parts) of a given class. It would be very useful to make use of the same stereotype at a classifier level, in order to define the expected and produced data format at a classifier level. The UML::Port metaclass is a good candidate to carry this stereotype.

  • Reported: MARTE 1.0b1 — Thu, 29 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex B: how VSL constructs shall be typed and evaluated

  • Key: MARTE-123
  • Legacy Issue Number: 11878
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: Annex B doesn't clearly define how VSL constructs shall be typed and evaluated Details: Our problem: it seems to be missing some information in the current VSL specification that explains how language constructs shall be typed and evaluated. We had a look at other standard programming languages (ANSI C, Java) to see how such information is defined. In the ANSI C language reference, every section introducing a language element is organised with the same structure: a subsection that introduces the syntax, a subsection defining the constraints (including type constraints) and finally a subsection regarding the semantics (other type constraints plus explanations regarding the evaluation). For instance, we can have a look at an extract that introduces the function calls: > 6.5.2.2 Function calls > > Syntax > > primary-expression: > identifier > constant > string-literal > ( expression ) > > > Constraints > 1 The expression that denotes the called function shall have type pointer to function > returning void or returning an object type other than an array type. > > 2 If the expression that denotes the called function has a type that includes a prototype, the > number of arguments shall agree with the number of parameters. Each argument shall > have a type such that its value may be assigned to an object with the unqualified version > of the type of its corresponding parameter. > > Semantics > 3 A postfix expression followed by parentheses () containing a possibly empty, commaseparated > list of expressions is a function call. The postfix expression denotes the called > function. The list of expressions specifies the arguments to the function. > > 5 If the expression that denotes the called function has type pointer to function returning an > object type, the function call expression has the same type as that object type, and has the > value determined as specified in 6.8.6.4. Otherwise, the function call has type void. If > an attempt is made to modify the result of a function call or to access it after the next > sequence point, the behavior is undefined. In VSL, we have a definition of the abstract syntax (the meta-model) and the concrete syntax (the BNF) in the Annex B and we have a detailed description of the domain classes (abstract syntax elements) in the Annex F. It seems that the current "constraint" and "semantics" sections of the metaclass descriptions miss some detailed information on the way constructs shall be typed and evaluated. The information does not seem to be systematic and homogeneous. Examples: > F.13.6 ConditionalExpression (from Expressions) > Generalizations > • Expression (from Expressions) on page 560 > Associations > • conditionExpr: VSL::ValueSpecification [1] Boolean expression to be evaluated. > • ifTrueExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to True. > • ifFalseExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to false. > Semantics > Conditional Expressions define "if-then-else" statements, which can be used inside an expression. The result of evaluating > this expression will be the result of => Here it is not stated that the consequence (ifTrueExpr) and the alternative (ifFalseExpr) shall have the same type or that the type of such an expression if a boolean. OR > F.13.8 DurationExpression (from TimeExpressions) > Generalizations > • TimeExpression (from TimeExpressions) on page 567 > Semantics > DurationExpression is a time expression that denotes a duration value. => Again, here it may miss more detailed information on the type of the expression. This is the kind of information we missed when implementing the VSL editor and which we need to figure out by ourselves. Sometimes it's obvious but it happens to be definitely tricky. That's why we think that it would be beneficial for MARTE and VSL to complete the Annex F to add this information. In that context, we propose that: 1) every VSL domain class in Annex F shall provide information about its type. 2) if the type cannot be directly known, there shall be an explanation on how it can be computed (this is the case of all the subclasses of Expression and TimeExpression). 3) if information about the evaluation / execution semantics is provided then it shall be distinguished from the type information (because this is something really different). All this information would complete either the "constraint" and/or "semantics" section of Annex F.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    VSL complements MARTE for improving the UML data type system and the
    specification of expressions. The approach to define VSL was to balance both its
    precision and its level of formality in order to provide a very compact specification
    but still well-formed. MARTE Beta 1 and 2 have provided a good basis to develop
    a couple of tools supporting VSL parsing and type checking. There are, however,
    some aspects that need to be improved in the VSL specification to avoid
    ambiguity in tool implementations. Some of the ambiguity problems were
    described in the summary of this issue, but we can organize them more formally
    in the following categories:
    a) Some of the production rules are syntactically ambiguous because they are
    based on the UML model to which the VSL expression is attached (e.g., does a
    data type exist or not). This means that disambiguating rules have to be defined
    for those rules.
    b) In order to semantically evaluate VSL expressions, we need to define the type
    of each expression or value specification. The mapping of expressions to (data)
    types can be easily identified in many cases, but there are other cases that this
    requires making it explicit. Moreover, there are some expressions that cannot be
    evaluated to any existing data type defined in MARTE. For example, duration
    expressions have not a type counterpart in the library of MARTE primitive types. To solve item (a), we will add a section of “Disambiguating Rules” for each
    production rule. In addition, one of the suggestions proposed in the summary of
    this issue is to add a special section for a semantics description. It must be
    noted, however, that VSL is described in two main parts: abstract syntax and
    concrete syntax. The semantics of VSL construct is described in plain English as
    a part of the abstract syntax. More particularly, the semantics of VSL model
    elements is described in Annex F, section F.13. However, the mapping of
    abstract syntax constructs to concrete syntax constructs is not explicit. In this
    resolution, we propose to add this mapping by identifying the abstract syntax
    counterpart of each production rule explicitly in the concrete syntax section.
    To solve item (b), we will complete all the required primitive types and describe
    the types to which VSL expressions should be evaluated. For those expressions
    that cannot be directly mapped to a concrete type, we will provide rules to help
    evaluating them.
    In addition, we will add some clarifications to help VSL implementers to use this
    specification. The goal is that at the end of all processing every tool
    implementation should be able to produce the same well-formed instance of
    abstract syntax tree.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In Annex D, I would suggest make unit names (e.g. bits, bytes) singular

  • Key: MARTE-122
  • Legacy Issue Number: 11877
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In Annex D, I would suggest make unit names (e.g. bits, bytes) singular.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Modify Figures D.3 with singular unit names.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

improve the usability of the RtBehavior stereotype

  • Key: MARTE-111
  • Legacy Issue Number: 11866
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    To improve the usability of the RtBehavior stereotype, it should also extend the UML::Operation metaclass.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RtAction.isAtomic

  • Key: MARTE-110
  • Legacy Issue Number: 11865
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The meaning of the RtAction.isAtomic should be precisely state. In chapter 13, isAtomic is used in other contexts (e.g. flow ports) with other semantics.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Provide a precise, non-recursive definition: here, isAtomic means indivisible.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names should be identical

  • Key: MARTE-109
  • Legacy Issue Number: 11864
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The Refinement metaclass relates to the ClockRefinement stereotype. Names should be identical.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

concept of refinement

  • Key: MARTE-108
  • Legacy Issue Number: 11863
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Does the concept of refinement only apply to clock refinement. My first impression is that this concepts may apply to other NFPs. In any case, this needs to be clarified

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There is agreement to extend the Refinement to any kind of NFP constraints. Issue 11864 required to use the same name in the domain model and in the UML representation so we chose NFPRefine for the name.
    The resolution replaces every occurrence of ClockRefine by NFPRefine. It also replaces the association to Time::ClockConstraint by an association to NFPs::NfpConstraint. In the domain model, the metaclass Refinement is associated to NFP_Constraint instead of ClockConstraint.
    The second constraint is removed since it was assuming all constraints were ClockConstraint.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

VSL

  • Key: MARTE-117
  • Legacy Issue Number: 11872
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: VSL should support definition and application of functions, derivatives, sequences and series. Details: In the early stage of a development process, it may be useful to model control laws of a RTES. VSL seems to be a very good fit for that purpose. However, it misses several mathematical concepts to provide a comprehensive support. VSL should support definitions of functions, derivatives, sequences and series.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In VSL, functions are supported by means of:
    a) The definition of UML::Operations in DataTypes, for the declaration of
    functions in data type libraries.
    b) VSL::OperationCallExpression, for the specification of functions
    (reference/call to declared UML::Operations) in VSL expressions.
    We added a set of minimum operations/functions to MARTE primitive and data
    types (e.g., arithmetic and logic functions). The number of functions that could be
    added to VSL, and useful in the real-time and embedded system domain, is very
    large. In MARTE, we did not attempt to define all these functions. Instead, we
    proposed only a basic subset useful for general expressions. The initial intent
    was that further libraries could extend MARTE libraries to support domainspecific
    functions.
    However, we should assure that different kinds of functions can be declared with
    basis on the current VSL abstract and concrete syntaxes (e.g., the functions
    described in the summary of this issue). In this resolution, we describe how such
    functions (i.e., functions, derivatives, sequences and series) are added to the
    MARTE library of primitive types and supported by VSL.
    From a computer science viewpoint, every function declaration can be expressed
    as a tuple: <name, parameters/arguments, returning type>. For instance, all the
    functions supported by Matlab are defined in this way. In Matlab, functions are program routines, usually implemented in M-files that accept input arguments
    and return output arguments. Every mathematical (or not mathematical) function
    in Matlab is implemented with this basic principle2 (integrals, derivatives,
    matrices, potentials, optimization expressions, etc.). If we look at VSL, the
    “function” notion matches very well with the UML::Operation concept. Thus, VSL
    is supported in Operations for the declaration and specification (expression
    specifications) of functions. In VSL, however, our scope is just the language
    aspects. VSL does not support implementation support on those functions
    (although they could be implemented as methods –UML::Behavior- of such UML
    UML::Operations). Instead, VSL describes the semantic of functions in a
    declarative way.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM::SchedulableResource should have a period property

  • Key: MARTE-119
  • Legacy Issue Number: 11874
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: GRM::SchedulableResource should have a period property. Details: After some discussion with F. Thomas, it seems that the GRM::SchedulableResource misses a period property

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    SchedulableResource in GRM represents the capabilities for obtaining processing capacity from a processing resource. The period is not a fundamental quality of the concurrent units represented. The fact that it may be periodically activated or not is a design choice. To annotate this behavior among other alternatives, a workloadEvent with the periodic arrival pattern may be used.

    Revised Text:

    Disposition: Close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allocatedTo and allocatedFrom properties should not be derived

  • Key: MARTE-118
  • Legacy Issue Number: 11873
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: In chapter 12, Details: The concept of allocation in MARTE is quite generic. Any UML::NamedElement can be used as allocation end. That enables the use of allocations in various kind of diagrams, for multiple purposes (e.g., structural, behavioural allocation.) In the current specification, allocations are supported by three stereotypes: Allocate, ApplicationAllocationEnd and ExecutionPlaformAllocationEnd. The allocatedTo and allocatedFrom properties of ApplicationAllocationEnd and ExecutionPlaformAllocationEnd are derived from the UML::Abstraction that is stereotyped as Allocate. However, creating an abstraction (i.e., a dependency) between two elements, implies that these elements belong to the same diagram, which is not always the case. Moreover, it limits the use of allocation to specific diagram types (e.g., not all the UML modeling tools allow the use of dependency on composite structures). Proposed correction: 1) Do not considerer allocatedTo and allocatedFrom as derived properties and allow end users to directly make use of the ApplicationAllocationEnd and ExecutionPlaformAllocationEnd stereoypes to express allocations. 2) Identify mechanisms to allow a characterisation of this allocation (allocation kind, allocation nature) the way its done in the Allocate stereotype.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NFP does not introduce the concept of dimension

  • Key: MARTE-116
  • Legacy Issue Number: 11871
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: NFP does not introduce the concept of dimension. Details: NFP defines the notion of unit attached to a type but it does explicitly express the dimension related to this unit. This should be fixed to provide a comprehensive support for modeling quantities in RTES.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The Dimension concept, and its possible attributes such as the base dimensions,
    is required to do dimensional analysis and verify consistency of expressions with
    quantitative NFPs.
    The concept of Dimension is not explicitly formalized in the NFP domain model
    nor in the NFP profile. However, the enumeration which gather the literals that
    are stereotyped by Unit can be already seen as a Dimension. We make this
    concept explicit here. The design of the current profile support this clarification
    with minimal changes.
    Note that SysML also includes the concept of dimension. As a first result of
    discussions between SysML and MARTE communities and a first step towards
    an alignment between both profiles in this domain, we propose to also explicitly
    support this concept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In section 6.1, I would suggest mentioning RTCORBA and CCM

  • Key: MARTE-115
  • Legacy Issue Number: 11870
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In section 6.1, I would suggest mentioning RTCORBA and CCM

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE primitive types

  • Key: MARTE-121
  • Legacy Issue Number: 11876
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    MARTE primitive types: Integer, String, UnlimitedNatural and Boolean are redefined in the MARTELib. To facilitate integration, I would suggest making them subclasses of their UML counterpart.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There is no reason to have a syntactical link between MARTE primitive types and
    UML primitive types. The semantics of MARTE primitive types is clearly defined
    and a set of default operations are provided for each primitive type. Also, the
    meaning of the inheritance between primitive types is not fully defined, although
    not forbidden, in UML. Hence, this resolution proposes to close this issue with no
    change.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship between Alloc::Allocation and SRM::EntryPoint

  • Key: MARTE-120
  • Legacy Issue Number: 11875
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Relationship between Alloc::Allocation and SRM::EntryPoint should be clarified (maybe a generalization relationship?)

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    SRM::EntryPoint shloud specialized the Alloc::Allocation stereotype.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

suggest removing the notion of feature in the conformance section

  • Key: MARTE-113
  • Legacy Issue Number: 11868
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    I whould suggest removing the notion of feature in the conformance section. As this notion is not used in other places of the document

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Agree on the proposal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

For the sake of consistency, the rtf stereotype should be renamed

  • Key: MARTE-112
  • Legacy Issue Number: 11867
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    For the sake of consistency, the rtf stereotype should be renamed as rtFeature.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Rename "rtf" to be "rtFeature".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6: Remove the MSWord comment

  • Key: MARTE-114
  • Legacy Issue Number: 11869
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Remove the MSWord comment "[N.B. Clearly, this is something..." in the related standard section

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Ok, see revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[GQAM: General]

  • Key: MARTE-63
  • Legacy Issue Number: 11773
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: General] The references (publications) along the text should be moved to the annex.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Replace each reference by suitable words which name the authors of documents, and insert the references in Annex G.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM: Examples

  • Key: MARTE-62
  • Legacy Issue Number: 11772
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [HRM: Examples] Figure 14-78, 14-82, 14-83, 14-84 specify tagged values with a syntax that does not correspond to VSL (e.g., 166MHz, 64 MB). It should be clarified the syntax used, or align to VSL.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Figures 14-78, 14-82, 14-83 and 14-84 are modified in order to be consistent with VSL syntax, and with the syntax which has been allowed in the resolution of issue 11781.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MoCC: Examples

  • Key: MARTE-61
  • Legacy Issue Number: 11771
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [MoCC: Examples] Fig. 13-22 misuse time observation declarations when using the occurrence index at declaration level. This should be specified in time expressions.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Rather, time observation declarations should be specified in time expressions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[Alloc: Profile

  • Key: MARTE-60
  • Legacy Issue Number: 11770
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [Alloc: Profile] The MARTE allocation concept aimed to refine the SysML allocation concept. Furthermore, it seems that the idea was to not be dependent on SysML by re-defining the same concepts in the MARTE context. For this reason, MARTE uses the same names for the generic stereotypes (<<allocated>> and <<allocate>>). However, there is a limitation in the MARTE <<allocated>> stereotype that does not allow modelers to have the same capabilities. More precisely, when using the <<allocated>> stereotype, we cannot refers to the target and source ends. We are forced to use the more specialized stereotypes: <<ApplicationAllocationEnd>> and <<ExecutionPlatformAllocationEnd>>, which is not always practical (the annotation process requires to pollute the target model) or is not always what modelers want to allocate (physical-logical allocation, or others support by SysML). So, I’d suggest to add properties: /allocatedFrom:NamedElement[*] and /allocatedTo:NamedElement[*] for the stereotype: <<Allocated>.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add the proposed property in the stereotype Allocated to maintain compatibility with SysML. Replace Figure 12.3 and the description text accordingly. If the property allocatedTo and allocatedFrom are already defined in the stereotype Allocated, they need not be redefined in the specialized stereotypes (ApplicationAllocationEnd and ExecutionPlatformExecutionEnd). Thus, these two stereotypes can be replaced by a mere attribute of type AllocationEndKind.
    All figures where either the stereotype ExecutionPlatformExecutionEnd or ApplicationAllocationEnd were displayed have been replaced by a new Figure with the new notation.
    No concept is introduced or removed. It is just a different lighter way to implement the domain model so as to be consistently compatible with the SysML allocation.
    The revised text assumes that resolution 12214 will be resolved by referring to sources of an allocation as clients and to targets as suppliers.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM: Examples

  • Key: MARTE-59
  • Legacy Issue Number: 11769
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GRM: Examples] Fig 10.21 shows a composite diagram, which is not conform to UML: parts are shown with attribute and operation compartments. This should be revised.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Instead of using as an example a composite structure, it will be used a class diagram. There are no implications in the text, so the only change is in the diagram shown in Figure 10.21. The diagram is changed by the next one:

    The usage of the stereotype <<allocate>> in this diagram is simplified to the minimum to avoid cluttering the picture.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM: Domain Model

  • Key: MARTE-58
  • Legacy Issue Number: 11768
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GRM: Domain Model] A number of GRM domain concepts make it hard to understand and use. These mainly relate to its mapping with the UML profile and its refinement in the HRM, SRM and analysis profiles: a) Figures 10.3 and 10.4 illustrate the ‘resource’ concept as two kinds of entities: an instance (ResourceInstance) and a classifier (Resource). This separation is not explained and is not used along the remaining parts of the spec. I.e., all the associated or specialized concepts are related to ‘Resource’. Also, the profile only defines a ‘Resource’ stereotype. Furthermore, NFPs are only associated with ‘Resource’. What about NFPs related to ResourceInstances? ? I’d suggest to remove the ResourceInstance concept, as conceptually, has not any relevance, and create confussion. b) Fig. 10-13 introduces the concepts of ‘ResourceUsage’, ‘UsageTypedAmount’, which inherits from ‘ResourceAmount’. However, at UML profile definition level, only <<ResourceUsage>> is provided, by using the attributes of UsageTypedAmount (from the domain model). I’d suggest to harmonize both, domain model and profile. c) A double inheritance of ‘ComputingResource’ from ‘Resource’ has been defined (Fig. 10.6 and, Fig. 10.11 through ‘ProcessingResource’). I’d suggest to remove one of them. d) GRM attempts to be a generic framework for modelling resources. However, some of the attributes seems too specific and not useful when specializing this package (e.g., HRM & SRM). For instance, ‘packetSize’ in ‘CommunicationEndPoint’ (Fig. 10-8) is related to specific kinds of protocols. ‘speedFactor’ in ‘ProcessingResource’ is an analysis-specific parameters.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    a) Instances and Classifiers are consubstantial to UML and their role in
    MARTE are explained in the CoreElements Chapter. The instances are
    there to illustrate the finite nature of resources. No change.
    b) UML View is an utilitarian mapping of the domain model, and in this case
    the harmonization is already included in the constraints that describe the
    rules for the utilization of resourceUsage. No change.
    c) Double inheritance is neither conceptually nor practically a problem. No
    change.
    d) Very few attributes have been defined, but all of them are optional and do
    not jeopardize the conceptual and architectural role of the stereotypes in
    GRM. No change
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (02)

  • Key: MARTE-65
  • Legacy Issue Number: 11775
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I’d suggest to move this concepts to a more general package.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (01)

  • Key: MARTE-64
  • Legacy Issue Number: 11774
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: Domain Model & Profile] The PrecedenceRelation concept (fig 15.3) could be used to specify delays due to e.g., queues. However, PrecedenceRelation only exists in the Domain Model. Its implementation is intended to be supported by existing UML concepts (e.g., forks, joints, etc.) I’d suggest to define the corresponding stereotype (<<PrecedenceRelation>>) in order to allow for modelling delays or other precedence patterns like event divisors: a number of event occurrences triggers an execution.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This enhancement is not necessary, since everything it would provide can already be done using scenario Steps, and done better. However the method for showing an event divisor using steps should be added to the text.
    Since a precedence relation always leads to one or more steps, properties such as queueing etc can be attached to the step. The step is a better place for these properties because there may be multiple branches in a precedence relation (a branch or fork), each with its own properties. For example, a fork precedence would have a different waiting on each branch of the fork, which would be complex to describe or specify within the fork, but very easy on the following steps.
    An event divisor or multiplier can be provided using the CommStep stereotype. We assume that the event is a call invoking a Step. The call can be stereotyped as a CommStep, which has a repetition attribute. If this is set to N, it means the call is repeated N times, giving event multiplication. If it is set to 1/N, it means that every Nth execution of the sender gives a call... an event divisor. If the repetition attribute is specified as a deterministic NFP, it should be defined to be interpreted as 1/N for an integer N, determined by rounding to an integer if necessary. A stochastic division is also possible.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[SAM: Profile]

  • Key: MARTE-68
  • Legacy Issue Number: 11778
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [SAM: Profile] The SaStep domain concept (Fig. 16-4) has an association to a SharedResource. This is very useful to model execution steps that take a resource along all their execution (alternative to use the AcquireStep and ReleaseStep). However, this association has not been reflected in the UML profile. This should be added in Fig. 16-7.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    (FTF Group) Strike the phrase "Business Management Perspective" Change it by "system perspective"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (04)

  • Key: MARTE-67
  • Legacy Issue Number: 11777
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: Domain Model & Profile] A TimingObserver (Fig. 15-4) refers to 0 or 1 start event occurrence and 0 or 1 end event occurrences, which are modelled by TimedInstantObservation elements. However, more refined TimingObservers can define the synchronization between several events. I’d suggest to change the multiplicity of the start and end observation points to [*].

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Change the multiplicity of the start and end observation points to [*].

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (03)

  • Key: MARTE-66
  • Legacy Issue Number: 11776
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I’d suggest to move this concepts to a more general package

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This is identical to issue 11775, it was submitted or entered twice
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[Time] Fig. 9.29

  • Key: MARTE-57
  • Legacy Issue Number: 11766
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [Time] Fig. 9.29 refers to the Enumeration type ‘EventKind’. The formal definition of EventKind is an annex (Annex D). I’d suggest to show this definition in Fig 9.29 for a faster comprehensibility of the provided stereotypes.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This is easy to do, but I guess that this suggestion may apply to many diagrams. In the chapter time (for instance),
    · Fig. 9.26 refers to TimeStandardKind,
    · Fig. 9.27 refers to TimeInterpretationKind
    · Fig. 9.28 refers to TimeInterpretationKind
    · Fig. 2.29 refers to EventKind
    My question is: do we systematically include in UML extension diagrams the used enumerations and mention in the associated text that the enumeration is part of a library given in Annex D?

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[NFP: Profile]. Fig 8.4

  • Key: MARTE-56
  • Legacy Issue Number: 11765
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [NFP: Profile]. Fig 8.4 shows a domain model for NFP declaration. In this domain model, the NFP concept has to attributes (statisticalQualifier + direction). However, these two attributes do not appear in the corresponding Stereotype: <<Nfp>> (Fig. 8-5). Section 8.3.2.1 justifies this by saying: “the attributes of NFP, statistical qualifier and direction, are implemented in the library of NFP Types”. However, it could be useful to allow stereotype users to define these two parameters at the NFP declaration stage (and not only at the value specification stage). On the other hand, the current mechanism to define these two parameters at the NFP declaration stage (default values of NFPs), is not strict enough, as users can modify default values. So, I propose to put this two attributes (statisticalQualifier + direction) in the <<Nfp>> stereotype.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    If we adopt these two attributes for the 'Nfp' stereotype, there may exist some issues regarding to consistency and duplication of information. Indeed, statisticalQualifier and direction would be able to be specified in 'Nfp' and in the value specification too (e.g., maxLatency= (value=5, unit=ms, statQ=max)).
    Another question that rises is why other qualifiers would not able to be specified in 'Nfp' attributes (e.g., source) in the same way.
    In order to keep consistency and to avoid confusions between the domain model and profile definition, both 'statisticalQualifier' and 'direction' attributes of the 'NFP' metaclass are removed from the domain model.
    This means that the proposal to include these two attributes in the stereotype definition is not accepted. However, for comprehensibility, they are removed from the domain model.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: NFP

  • Key: MARTE-55
  • Legacy Issue Number: 11764
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [NFP] A very useful concept for NFP annotations could be the notion of ‘NFP level’. For instance, a NFP level may identify a group of non-functional values that are valid for a specific system operation mode. More specifically, in a component-based architecture, components can support different working modes, and these working modes may provide different non-functional values or qualities for the same services. In infrastructures supporting dynamic resource management, the resources may offer different non-functional values depending on the system load. From a conceptual viewpoint, a NFP level can identify a level of model refinement. For example, one may define NFP values according to available estimates in early development phases, while further accurate measurement values may be annotated in the same models. A NFP level, in this case, can offer a mechanism to organize non-functional values according to successive refinement stages.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In general, this is a problem than might need some especial mechanism in UML,
    or a trick/cheat annotation mechanism. We recognize that we need the ability to
    express differing configurations for modal analysis or tradeoff analysis. However,
    having multiple value annotations for arbitrary cases or situations is clearly
    beyond the scope of the MARTE Profile and is within the scope of the UML
    metamodel and modeling generally. For instance, this could be supported by
    allowing applying a given stereotype multiple times in the same UML model
    element. We need to raise the issue within the UML Revision Task Force.
    Also, MARTE offers AnalysisContext and VSL offers variables and the two are
    intended for multi-case analysis.
    Finally, modeling of NFP_Constraint annotations for specific operational model is
    treated in Issue 12797 (HLAM work group).
    Hence, we propose to close this issue with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider providing a tabular notation (as in SysML)

  • Key: MARTE-54
  • Legacy Issue Number: 11707
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Consider providing a tabular notation (as in SysML) to easy the setting of allocations and their implied constraints when the source and the target are in diagrams too far apart.

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add an example of a possible table that contains NFP constraints relative to an allocation activity groups.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HwTiming model of the HwLogical profile

  • Key: MARTE-50
  • Legacy Issue Number: 11694
  • Status: closed  
  • Source: CEA-LIST ( TAHA Safouan)
  • Summary:

    in the HwTiming model of the HwLogical profile, HwClock has a property named "frequency" that is already inherited from the HwResource stereotype. We should rename it or better remove it.

  • Reported: MARTE 1.0b1 — Wed, 28 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The HwResource stereotype actually owns a "frequency" property. As there is a (indirect) generalization relationship between HwClock and HwResource, the "frequency" property of HwClock must be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.2 add two stereotypes corresponding to HwSensor and HwActuator

  • Key: MARTE-49
  • Legacy Issue Number: 11693
  • Status: closed  
  • Source: CEA-LIST ( TAHA Safouan)
  • Summary:

    After many users feedbacks, we should add two stereotypes corresponding to HwSensor and HwActuator as specializations of the existing stereotype HwI_O from the HwDevice package. Even if we explained in the document that the HwDevice denotes both sensors and actuators, it is better to separate these concepts.

  • Reported: MARTE 1.0b1 — Wed, 28 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the proposal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1 figure 11.6

  • Key: MARTE-45
  • Legacy Issue Number: 11665
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    In figure 11.6, the [0..1] multiplicity of the direction tagged value is NOT displayed (whereas the [0..1] multiplicity of the kind tagged value of the MessagePort stereotype is displayed).

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Correct Figure 11.6 by adding a [0..1] multiplicity to the direction attribute on the FlowPort stereotype.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

  • Key: MARTE-44
  • Legacy Issue Number: 11664
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    In figure 11.6, this stereotype is called SendFlowAction instead of FlowSendAction

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There is indeed an inconsitency between the domain model where the action is named "FlowSendAction" and the profile definition where it is called "SendFlowAction".
    In UML, the action that sends an object is named SendObjectAction; the action that sends a signal is named SendSignalAction.
    The resolution for this issue is to align the the domain model on the profile definition terminology, which is consistent with UML related actions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In 12.4, all references to figures are wrong

  • Key: MARTE-53
  • Legacy Issue Number: 11705
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    In 12.4, all references to figures are wrong (e.g., 12.12.8 instead of 12.8).

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This is an editorial issue. All callouts of the form 12.12.x are replaced by 12.x.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial issue

  • Key: MARTE-52
  • Legacy Issue Number: 11704
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    First a typographical issue, there are some question marks appearing here and there. They should be replaced by slashes .

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This editorial issue is resolved by removing the unexpected question marks.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggest to extend ClockConstraints to ClockTypes

  • Key: MARTE-51
  • Legacy Issue Number: 11696
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    in the Time model, ClockConstraint is defined by
    "A ClockConstraint is a Constraint that imposes dependency between clocks."

    I suggest to extend ClockConstraints to ClockTypes.
    => "A ClockConstraint is a Constraint that imposes dependency between clocks or between clock types."

    This will allow more general constraints indirectly applied to all the clocks of a given type.

  • Reported: MARTE 1.0b1 — Thu, 29 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    I suggest adopting the extension

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.2

  • Key: MARTE-48
  • Legacy Issue Number: 11692
  • Status: closed  
  • Source: CEA-LIST ( TAHA Safouan)
  • Summary:

    In the HwCommunication model of the HwLogical profile, HwMedia should extend UML::Connector inspite of Association. Association in UML is a Classifier and the parent stereotype HwResource already extend it. By extending Connector we will help to use this concept within composite structure diagrams

  • Reported: MARTE 1.0b1 — Wed, 28 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with proposal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4.1

  • Key: MARTE-47
  • Legacy Issue Number: 11667
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    The Automative Example uses stereotypes that are not defined in the specification (namely SignalSpecification and ServiceSpecification

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11551 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2.1

  • Key: MARTE-46
  • Legacy Issue Number: 11666
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    It would probably be clearer if the BFeatureKind enumeration only proposes REQUIRED and PROVIDED enumeration literals (that is to say “qualifiers” that are already used and widely accepted in the UML to denote “direction” of signals and operations in message-oriented communications). IN, OUT, INOUT should be reserved to FlowPorts and FlowProperties (that is to say for data-flow communication schemes).

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11661 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2

  • Key: MARTE-43
  • Legacy Issue Number: 11663
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    FlowPort and MessagePort stereotypes have two common tagged values: isAtomic and isConjugated. These two properties could be inherited from a common ancestor stereotype (for example, an abstract InteractionPort stereotype).

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11658 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor edits to MARTE Chapter 17

  • Key: MARTE-37
  • Legacy Issue Number: 11649
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    p 311 Fig 17.2 The name of the package should be PAM_Resources

    also on the left halfway down the Fig, troughput --> throughput

    p 312 line 2 resources).... end bracket is missing.

    p 314 line 2 Figure 17.4

    line 14 "a message transmission is defined within the UML model, but if no network is specified it is an external service". Wording clarified.

    p 317 Fig 7.6 CommunicationStep inherits from PAM_Workload::PAM_Step. The attributes are inherited and can be eliminated from this figure.

    p 322 line 10 "identity of the resource" spelling

    p 325 sec 17.4.1 para 2 line 1 "In Figure 17.9 the blockT attribute of the LAN" corrected fig number, attribute name, plus clarification.

    p 325 fig 17.10 stereotype on database should be <<PaRunTInstance>>, same as for web

    p 326 first line after Fig 17.10: "In Figure 17.10 a simple sequence diagram"...wrong number

    second para after Fig 17.10, delete the last sentence, it refers to something in the example that was changed.

    third para, replace ExecStep by Step (two occurrences, plus another on p 327 line 1)

    Figure 17.13, in the box labelled dbReq, under the label should be "12.4 ms"

    p 329 last line, complette the sentence: "The behavior is shown in figure 17.15".

    p 330, Fig 17.15, two annotations near the bottom have "$images" which should be just "images"

    p 331 first sentence "with that a set" --> with a set" and add at the end "(with 95% probability)"

    p 332 para 2 line 1, replace "Process stereotypes" by "RunTInstance stereotypes"

    p 332 Fig 17.17 in the attributes of the <<GaWorkloadEvent>> stereotype the cycleTime95 variable should be preceded by "out$" (it is declared here, and it is an analysis output)

    lower in Fig 17.17 the $ sign should be removed from variables acquireThreads, frameSize, blocks, storeThreads, DBThreads. (they are declared in the context)

    p 333 para 2 delete the paragraph (it refers to aspects of the example that have been changed)

    p 335 line 2 Figure 17.21, three instances in the para

    p 336 Fig 17.21, the two <<PaProcess>> --> <<RunTInstance>>

    also in the context at the top "contextParams=$messageSize"

    below the figure, Figure 17.21 --> 17.22 and 17.22 --> 17.23

    p 337 Figure 17.22 <<PaProcess>> --> <<RunTInstance>> twice,

    also in the attributes, "runTInstance = webserver" --> "instance = webserver" (was not adapted to a change in definitions during profile development)

    and similarly "runTInstance = App" --> "instance = application"

    below Figure 17.23, increase Fig numbers by 1 (twice)

    p 338 bottom ...Figure 17.25

    p 339 line 1 Figure 17.25

    line 2, add to end of sentence "Figure 17.26."

    Figure 17.26 legend ends with "hierarchy of Figure 17.25" (no (b))

    p 340 para 2, Figure 17.26 --> 17.27 and 17.14 --> 17.15

    p 341 Figure 17.27 top: two instances of @Nusers should be $Nusers the first time, then Nusers.

    p 342 para 1, add a sentence for clarification:

    "The Markov Chain is solved to provide the steady state probabilities of each state, and thus of each behavior in the combined workload."

  • Reported: MARTE 1.0b1 — Sun, 11 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Editorial changes as follows.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B.2.4

  • Key: MARTE-36
  • Legacy Issue Number: 11644
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Inconsistency between the VSL BNF and metamodel (Variable declaration) In the VSL annex, Figure B.4 (VSL::Expressions package) indicates that a Variable has "direction" property: VariableDirectionKind [0..1]. On the other hand, in the BNF, the <variable-direction> term is not between brackets, which means that it is a mandatory term. Proposed resolution: either we update the BNF or we change the multiplicity of the direction property in the metamodel.

  • Reported: MARTE 1.0b1 — Tue, 6 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    As far as the variable direction is optional, as described in the metamodel, the grammar should be revised and modified with the brackets for the <variable-direction> term.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1 (data reception)

  • Key: MARTE-42
  • Legacy Issue Number: 11662
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    The FlowSendAction concept is introduced to enable sending of data via a FlowPort. It seems that there is no equivalent concept (action) for data reception. If a given behavior has to be expressed according to data arriving from an input port, how is the behavior “notified” that a data is available on this port (I mean: is there something equivalent to AcceptCallAction used for service oriented communication schemes)? Once that the notification has occurred in one way or another, do we access to this data with something like a ReadStructuralFeatureAction (because ports are structural features)?

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11840 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1

  • Key: MARTE-41
  • Legacy Issue Number: 11661
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    In the UML, a “Provided or Required” direction is implicitly associated to Signals that are exposed on the ports of a structured class or component (via the provided or required interfaces of the port). For UML consistency purpose, the “direction” attributes of SignalFeature and MessagePort should be typed by an enumeration like BFeatureKind (which is defined in the UML representation section), only with PROVIDED and REQUIRED enumeration literals. In other words, the DirectionKind enumeration (with enumeration literals IN, OUT and INOUT) should be reserved to FlowPorts, and used only to type “direction” attributes of FlowPort and FlowProperties classes.

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with suggested resolution in the profile definition and the domain model.
    Related issues: 11666, 11551

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class descriptions are missing

  • Key: MARTE-29
  • Legacy Issue Number: 11554
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Class descriptions are missing in the MARTE model library for extended datatypes (Annex D2).

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We describe a subset that requires unambiguous definition. The remaining extended data types are self-explanatory.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.1

  • Key: MARTE-33
  • Legacy Issue Number: 11631
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Inconsistency between GCAM profile definition and SAM example In Figure 16.14, the stereotype <<GaResourcesPlatform>> is applied on a part (i.e. a UML property) of the TeleoperatedRobotSAM composite class. Meanwhile, in Figure 15.6, it seems that this stereotype extends only UML::Classifier. Proposed resolution: either we remove the stereotype from the SAM example or we allow the stereotype <<GaResourcesPlatform>> to extend UML::Classifier and UML::Property. The second option would make sense to me.

  • Reported: MARTE 1.0b1 — Wed, 24 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The stereotypes are to be removed from the example.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15/3

  • Key: MARTE-32
  • Legacy Issue Number: 11620
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The stereotype <<gaEventTrace>> defines stereotype attributes: content, format, location that are not defined in the domain model (p. 263). I would suggest adding a definition of these attributes in the EventTrace domain class.

  • Reported: MARTE 1.0b1 — Tue, 16 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add definitions to the text of the domain model

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: GRM / 10.3.1

  • Key: MARTE-8
  • Legacy Issue Number: 11411
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The GRM packages defines a <<SchedulableResource>> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <<SwSchedulableResource>>. However, there is no direct link between these two stereotypes. GRM::SchedulableResource directly specializes GRM::Resource, while SRM::SwSchedulableResource specializes SRM::SwConcurencyResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar name, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

  • Reported: MARTE 1.0b1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Make stereotype SwSchedulableResource inherit from SchedulableResource. Since this
    inheritance is already present in the domain view, the sections to modify comprise only
    the UML representation of SRM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

concept of "resource"

  • Key: MARTE-7
  • Legacy Issue Number: 11402
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The General Resource Model of MARTE seems to define the concept of "resource" both at the instance and classifier levels. For instance, the GRM::Resource stereotype extends both InstanceSpecification and Classifier.

    The SwResource stereotype defined in the Software Resource Model of MARTE specializes the GRM::Resource stereotype. However, reading the SRM chapter, it seems that its use is much more focused on description of classifiers (to characterize properties or behavioral features for instance) than instances.

    In that context, does it make sense to apply a SRM::SwResource stereotype or one of its subclasses (for instance SRM::SwSchedulableResource) on an instance specification? Note that it seems to be legal given that SRM::SwResource specializes GRM::Resource, which extends InstanceSpecification.

    I would be pretty handy to do so, in order to describe a resource platform model provided in input of a scheduling analysis.

  • Reported: MARTE 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Complete the paragraph 7.3 with the rules for the default values of attributes of the stereotypes for instance of classifiers also stereotyped.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

grammar defined for conditional expressions

  • Key: MARTE-20
  • Legacy Issue Number: 11545
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The grammar defined for conditional expressions does not allow one to use operation call expressions in the condition predicate. The BNF defines only <condition-expr> ::= <variable-declaration> | <variable-call-expr> | <property-call-expr> As a consequence, it is not possible to define predicates based on value comparison. Thus, it is not possible to implement the expression "(clock_rate>5)?(5):(clock_rate)", provided as example page 404.

  • Reported: MARTE 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We add a new terminal to the <condition-expr> rule, which is operation call expression. This allows us to specify: "(clock_rate>5)" which is an infix operation call of ">" in clock_rate.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex D

  • Key: MARTE-19
  • Legacy Issue Number: 11544
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Operators (e.g., +, -, *, /, =, <, >) are not defined for the types in the MARTE_Library::BasicNFP_Types package. Such operators are required if one wants to define expressions such as "(end - start) < (10, ms)" where "end" and "start" are ObsCallExpression, for instance. Ideally, all the operators defined for the MARTE_Library::MARTE_PrimitiveTypes types should also exist for their MARTE_Library::BasicNFP_Types counterpart

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    One aspect that appears here is that the operations for NFP types like
    NFP_Real, NFP_String, etc, should be the same as the primitive type
    counterparts. So, it seems natural to reuse those operation definitions. One
    mechanism to reuse the operations (e.g., +, -, *, /, =, <, >) is to inherit NFP types
    from the primitive types.
    Hence, this resolution proposes to define the operations of Nfp_Types by
    inheriting from the corresponding MARTE primitive types.
    In addition, the semantic of such NfpTypes operations (in physical Nfp_Types
    such as NFP_Duration, NFP_Temperature, etc.) are different than their primitive
    type counterparts (Real primitive types). Indeed, operations in NfpTypes involve
    evaluating not only the “value” part but also the measurement “unit” part. This is
    left out of the scope of this specification, and an implementation supporting
    measurement unit conversion should take care of this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex B VSL BNF

  • Key: MARTE-23
  • Legacy Issue Number: 11548
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the VSL BNF, the use of the "[ ]" symbol should not be limited to collections. One may want to use it along with variable call expressions (e.g. "collec[2]"), property call expressions. Maybe other kinds of value specifications also apply.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The current mechanism of defining operations on data types allows one to define a given operation independently of the current value itself. For instance, a property could be typed by a Collection of Integers, and this collection could be specified by a Variable. So, we can apply to this variable, all the operations defined for Collections.

    This issue is also related to Issue 11547, and do not need any modification in the spec.

    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

VSL meta-model

  • Key: MARTE-22
  • Legacy Issue Number: 11547
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The VSL BNF defines a "[ ]" symbol that can be used along with a collection. The specification introduces the example: "

    {'a', 'b', 'c', 'd'}

    [2]". However, there is no related concept (access to a collection) in the VSL meta-model.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This notation (to get collection elements by using the index), comes from the TVL language in SPT, but the mentioned example was not updated to the current VSL mechanism to define operations in data types. For that, VSL uses the same approach as OCL, so that the operation for finding an element in a given collection should be defined and described at library level, in the operations of the concerned data types (collections in this case). The specification of the function will be allowed by using OperationCallExpression.

    The resolution is to remove the proposed examples from VSL.

    If new operations are required for Collections in the MARTE library of data types, this should be solved by posting a separated issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B3.3.3

  • Key: MARTE-5
  • Legacy Issue Number: 11339
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The <value-specification> rule references an <opaque-expression> rule that is not defined in the VSL grammar.

  • Reported: MARTE 1.0b1 — Tue, 11 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    VSL expressions are specified in OpaqueExpressions. Adding new opaque expressions within a VSL expression would make VSL expressions complex, and without a real added value. Hence, we do not support in VSL nested expressions written in new languages. Note that this doesn't mean that we do not allow one to extend VSL. VSL can be extended by reusing its metaclasses, as the Clock Constraint Language in MARTE.

    Hence, the term <opaque-expression> in the VSL grammar is not right. This resolution proposes to remove that term from the VSL grammar.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE_Library::MeasurementUnits model library

  • Key: MARTE-4
  • Legacy Issue Number: 11338
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    MARTE_Library::MeasurementUnits model library contains following bugs. In FrequencyUnitKind enumeration baseUnit tag value specified is W instead of Hz. In LenghtUnitKind enumeration baseUnit tag value is m for mm literal. In AreaUnitKind enumeration baseUnit tag value is mm2 for um2 litreal. In DataTxRateUnitKind convaFactor is 1024 instead of 1E3.

  • Reported: MARTE 1.0b1 — Mon, 10 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Modify Figures D.3 according to proposed corrections.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

rtf stereotype

  • Key: MARTE-10
  • Legacy Issue Number: 11417
  • Status: closed  
  • Source: SODIUS ( Philippe Soulard)
  • Summary:

    rtf stereotype is the only one which name does not start with an upperCase. Should be Rtf (or RTF). Lack of coherency.

  • Reported: MARTE 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The name of the RealTimeFeature stereotype SHALL be "Rtf".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: GRM / 10.3.1 - p 96

  • Key: MARTE-9
  • Legacy Issue Number: 11412
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The GRM package defines a <<MutualExclusionResource>> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <<SwMutualExclusionResource>>. However, there is no direct link between these two stereotypes. GRM::MutualExclusionResource directly specializes GRM::Resource, while SRM::SwMutualExclusionResource specializes SRM::SwSynchronizationResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar names, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

  • Reported: MARTE 1.0b1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Make stereotype SwMutualExclusionResource inherit from MutualExclusionResource.
    Since this inheritance is not present in the domain view, the sections to modify comprise
    both, the domain view, and the UML representation of SRM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider adding a new attribute to «boundedSubtype»

  • Key: MARTE-2
  • Legacy Issue Number: 11163
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Consider adding a new attribute to «boundedSubtype» to specify what the default value for the new type is. Something like <<boundedSubtype>>.defaultValue

  • Reported: MARTE 1.0b1 — Thu, 19 Jul 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Resolution:
    A BoundedSubtype, as other data types, defines a space of valid values. However, it doesn't describe any particular value property. Specifying a default value is to be done at property declaration level, and it's already supported by UML itself. This approach is natural from a pragmatic viewpoint (different properties typed by the proposed BoundedSubtypes could have different default values), and from the general practice in (modeling, programming) languages.

    For these reasons, we don't add default values for BoundedSubtype, or whatever data types.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Profile for MARTE acronym list

  • Key: MARTE-1
  • Legacy Issue Number: 11112
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The MARTE spec has a large number of Acronyms.

    Some (e.g. MARTE) are not expanded anywhere in the spec.

    It would be helpful to the reader to have a common section of the document to fully expand all acronyms used in the spec.

    Proposed resolution:
    Place a table of acronym expansions in the now empty Symbols section of the spec (perhaps relabeling the section as Symbols and Acronyms)

  • Reported: MARTE 1.0b1 — Tue, 26 Jun 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming conventions and typing errors

  • Key: MARTE-3
  • Legacy Issue Number: 11337
  • Status: closed  
  • Source: SODIUS ( Philippe Soulard)
  • Summary:

    Naming conventions and typing errors: - MARTE::MARTE_Foundations::GRM::GRService -> GrService for coherence - MARTE_Library::GRM_BasicTypes::EDFParameters -> EDF_Parameters or EdfParameters - MARTE::MARTE_AnalysisModel::SAM::SaSchedObs::suspentions -> suspensions

  • Reported: MARTE 1.0b1 — Mon, 10 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The convention of using uppercase for the prefixes would have been more consistent with the English style, but it has been almost consistently used along the spec the capitalization of only the first letter to reduce space, for this reason is probably better to just correct GRService in GRM as well as EDFParameters suspentios is clearly a typo to correct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B3.3.3 p 397

  • Key: MARTE-6
  • Legacy Issue Number: 11340
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    A circular reference between the <value-specification> -> <time-expression> -> <instant-expr> -> <value-specification> rules prevents a straightforward implementation of the VSL BNF grammar.

  • Reported: MARTE 1.0b1 — Tue, 11 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We modify the grammar for time expressions to prevent the circular reference.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6/6.3

  • Key: MARTE-17
  • Legacy Issue Number: 11528
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    In the first paragraph of sub-section 6.3.1 it is written "These are shown by the RTEM package in Figure 6.4, and the cluster of four AnalysisModelling packages, respectively". However, I see only three packages under the MARTE analysis model: GQAM, SAM, and PAM. Also I don't see the TCRM package (by the way, I presume that the RTEM and RTEMoCC are the same packages). Am I wrong at my assumptions?

  • Reported: MARTE 1.0b1 — Wed, 3 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    At the beginning, the Analysis package aims including an additional package dedicated to WCET analysis. At the end, this purpose was not achieved. So, this package contains at last only 3 packages => text need to be revised as described in the next section.
    In general, the figure 6.4 reflects correctly the current architecture of the MARTE extensions but the text put on top of this figure needs to be updated to take into account the final name of the package as described in the figure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6/6/2/1

  • Key: MARTE-16
  • Legacy Issue Number: 11527
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    In the first paragraph of section 6.2.1 is written "...it is possible to give some general descriptions of four main sub categories included in the RT/E domain category...". However, five domains are described: - Embedded domain - Reactive domain - Control/Command domain - Intensive data flow computation domain - Best-effort service domain Also, only the 'Intensive data flow computation domain' is sub-sectioned as 6.2.1.1 (how about the other domains?)...

  • Reported: MARTE 1.0b1 — Wed, 3 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The resolution of this issue consists in making the required editorial changes as described in the next section.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex D3 MARTE model library for time

  • Key: MARTE-11
  • Legacy Issue Number: 11504
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    In Annex D3 MARTE model library for time, 2 enumerations (EventKind and TimeStandardKind) have to be moved from the Time library to the TimeTypesLibrary, because these enumerations are used in the profile definition.

  • Reported: MARTE 1.0b1 — Thu, 20 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the proposed modifications.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

non-terminal symbol

  • Key: MARTE-25
  • Legacy Issue Number: 11550
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The VSL grammar introduces a non-terminal symbol <namespace> in the syntax definition of property call expression and variable call expression. However, this symbol seems to be missing in the syntax definition of enumeration specification as well as observation call expression. As a consequence, it is not possible to reference without ambiguity two time instant observations with the same name but with different fully qualified names. That prevents from using observations with similar names in different packages.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    For the case of Enumeration specification, it is not necessary to specify the namespace. Enumerations values are always related to a typed property or tag definition. The type of those properties or tag definitions (an Enumeration data type) defines the scope of the enumeration literal specified.
    For the case of Observation Call Expression, the namespace is missing. This resolution proposes to add such a namespace.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The VSL grammar does not define the "( )" symbol

  • Key: MARTE-24
  • Legacy Issue Number: 11549
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The VSL grammar does not define the "( )" symbol that allows one to indicate priorities in the syntax of arithmetical expressions. In the expression, "((1+2) * 3)" for instance.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    To allow building unambiguous expressions (mainly arithmetical ones), the
    language should include both proper rules supporting parentheses (i.e., “(“ and
    “)”) as well as precedence rules to specify the order in operations evaluation.
    In VSL, these aspects concern two different sections of MARTE. Parentheses
    need to be specified in the VSL grammar section, and precedence rules in the
    library of primitive types. The latter is because “operations” (e.g., arithmetic
    operations: +, -, *, /) are defined as operations of MARTE primitive types (Real,
    Integer, etc.).
    Hence, this resolution proposes to add/modify VSL as defined below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

automotive example

  • Key: MARTE-26
  • Legacy Issue Number: 11551
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The automotive example still uses stereotypes that have been renamed in the lastest versions of the document (e.g. <<msgPort>> instead of <<messagePort>>, <<serviceSpecification>> and <<signalSpecification>> instead of <<bFeatureSpecification>>). Such inconsistencies appear in diagrams and descriptions.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    1) Remove references to the msgPort stereotype and replace by the messagePort stereotype.
    2) Remove references to the serviceSpecification and signalSpecification and replace by the bFeatureSpecification stereotype.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 14.70 - HwCommunication package details

  • Key: MARTE-13
  • Legacy Issue Number: 11521
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    Lack of homogeneity in the enumeration litterals naming (considering the rest of the document) : - litteral should start with lowercase - "undef" should be used instead of "undefined"

  • Reported: MARTE 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed in all the figures affected by this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the property named "isSynchronous" is misspelled

  • Key: MARTE-12
  • Legacy Issue Number: 11520
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    On the stereotype HwBus in the diagram, the property named "isSynchronous" is mispelled ("isSynchrnous")

  • Reported: MARTE 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed in both Domain Model and Profile Definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6/6.4

  • Key: MARTE-18
  • Legacy Issue Number: 11529
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    There a lot of spelling errors in the section 6.4.1: - "...; chapter 0, General Component Model, introdces a general componenet model suitable for RTES." should be rewritten as "...; chapter 11, General Component Model, introduces a general component model suitable for RTES." - "..., chapter 13, RTE Model of Compuation and Communication, ..." should be rewritten as "..., chapter 13, RTE Model of Computation and Communication, ..." - "It does not intend to define new analmysis technologies, but to define the information required for annotation models on whoch external analysis techniques may be applied." should be rewritten as "It does not intend to define new analysis technologies, but to define the information required for annotation models on which external analysis techniques may be applied." - "..., specializes the generic framework for performaing schedulability analysis, whereas ..." should be rewritten as "..., specializes the generic framework for performing schedulability analysis, whereas ..."

  • Reported: MARTE 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Do editiorial change as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B

  • Key: MARTE-35
  • Legacy Issue Number: 11633
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Invalid reference in caption of Figure B.1. The caption of Figure B.1 is currently "Figure B.1 - Structure of the NFP framework" when it should be "Figure B.1 - Structure of the VSL framework".

  • Reported: MARTE 1.0b1 — Thu, 25 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Revise caption of Figure B.1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.2.3

  • Key: MARTE-34
  • Legacy Issue Number: 11632
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    << tupleType >> stereotypes would need to be added on HRM datatypes, to enable the use of VSL expressions. The UML representation section of HRM defines several datatypes (Timing, CacheStructure, PLD_Organisation, MemoryOrganisation, Env_Condition) that are not stereotyped as << tupleType >>. As a consequence, it is not possible to edit properties typed by these datatypes as VSL expressions. Proposed resolution: to apply the << tupleType >> stereotype on every datatype defined in HRM.

  • Reported: MARTE 1.0b1 — Thu, 25 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the modification of all the datatypes with tupletype in the HRM chapter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14/2

  • Key: MARTE-31
  • Legacy Issue Number: 11619
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In HRM, a stereotype called HwResource is used in the HwLogical subpackage to provide a logical representation of a hardware resource. At the same time, a stereotype with the name is used in the HwPhysical subpackage to provide a physical representation of a hardware resource. Although it is legal in this context, defining two stereotypes with the same names that have different semantics may create confusion in a user's mind. I would suggest renaming HwResource into HwLogicalResource / HwPhysicalResource. The same thing applies for HwLogical::HwResourceService and HwPhysical::HwResourceService.

  • Reported: MARTE 1.0b1 — Tue, 16 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class descriptions are missing in the MARTE model library for GRM (Annex D4

  • Key: MARTE-30
  • Legacy Issue Number: 11555
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Class descriptions are missing in the MARTE model library for GRM (Annex D4).

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    These Class descriptions are in section 10.3.3. They can be referenced from the annex or move to the annex and referenced in section 10.3.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1 figure 11.4

  • Key: MARTE-40
  • Legacy Issue Number: 11660
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    In figure 11.4, MessagePort is represented as an abstract class (“italic”). According to the description written in the spec, there is no particular reason to do that. This class should be represented as a concrete class

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Update Figure 11.4 to represent MessagePort as a concrete class (no italic).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1

  • Key: MARTE-39
  • Legacy Issue Number: 11659
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    The ability to type FlowPorts by Signals (or by FlowSpecifications containing FlowProperties typed by Signals) is confusing. MessagePorts (which are just a light specialization of UML ports) already enable signal-based communications. Things would be clearer if FlowPorts would only enable data-flow communications, and if MessagePorts would be used for service or signal-based communications (just as classical UML ports are). I suppose that this feature is inherited from SysML, but this is however confusing in the context of UML

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM::SchedulableResource should not have a property "host:ExecutionHost"

  • Key: MARTE-27
  • Legacy Issue Number: 11552
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the class diagram, the GRM::SchedulableResource should not have a property "host:ExecutionHost" (defined in QGAM). There is no dependency from GRM to GQAM, therefore the "host" property cannot be typed by "ExecutionHost". Moreover, GRM::SchedulableResource already has a property called "host: Scheduler". In that context, I would suggest just removing the "host: ExecutionHost" property from SchedulableResource in Figure 15.5.

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    To add an inheritance from scheduler in figure 15.5 for both executionHost and communicationHost. Then the association between SchedulableResource and executionHost is the same that already exist in GRM to scheduler. The scheduler in communicationHost is easy to justify as the arbitration/protocol that gives to each message access to the media.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no explicit dependency to QVT concepts

  • Key: MARTE-28
  • Legacy Issue Number: 11553
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    It is stated that MARTE uses "MOF 2.0 Queries, Views, and Transformation framework to define any model transformation rules...". Additionally, Figure 6.1 shows a <<use>> dependency between MARTE and QVT. However, no explicit dependency to QVT concepts has been used/found in this document.

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The comment is correct. I suggest then to modify the text of the first paragraph of the section 6.1 and modify the figure 6.1 in order to suppress this reference to MOF QVT.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong references in page 397

  • Key: MARTE-21
  • Legacy Issue Number: 11546
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Wrong references in page 397 : "The nature of these mechanisms is described in chapters Model Processing and The Model Configurer on page X-X" and "we use the standard BNF notational convention defined in Annex X". The chapters "Model Processing" and "The Model Configurer" may not exist anymore in the Beta 1 version.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    I suggest to remove these sentences that contain old (SPT) references.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2/2.2

  • Key: MARTE-15
  • Legacy Issue Number: 11526
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    "The extensionUnits defined in this specification..." should be written as "The Extension Units defined in this specification..."

  • Reported: MARTE 1.0b1 — Wed, 3 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Text to update according to the previous proposal. DDDDDDwxvcx

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The type NFP_Price does not exist in the document.

  • Key: MARTE-14
  • Legacy Issue Number: 11522
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    HwComponent stereotype has a property named "price" typed by "NFP_Price". The type NFP_Price does not exist in the document.

  • Reported: MARTE 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    To add the nfpType NFP_Price in Annex D.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1

  • Key: MARTE-38
  • Legacy Issue Number: 11658
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    FlowPort and MessagePort are subclasses of InteractionPort. These two classes have common properties: isConjugated and isAtomatic (there is actually a third one, “direction”, but I think there is an issue with this property). These properties could be directly defined as properties of the common parent class, i.e. InteractionPort.

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT