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 SendS