Omg issue Number

Disposition: Resolved

OMG Issue No: 12371

Title: {Delay times in GQAM and PAM}

Source: Carleton University (Dr. Murray Woodside, [e-mail])

Summary:

Generated, based on extensive discussion, to deal with the issue raised in 11882, whose resolution is only for SAM.

There are two kinds of delay in a step, a self-initiated delay (such as sleeping or thinking or some latency included in the step), or a blocked delay waiting for an event (such as a signal) or condition (such as a resource availability).
The latter is represented by the domain concept Step.blockingTime, which is the profile property gaStep.blockT.
The former is not represented. It should be added, along with some explanatory text.
Resolution:

1. In GQAM, add the domain property Step.selfDelay:NFP_Duration and the profile property gaStep.selfDelay:NFP_Duration.

Add text to the domain model to explain selfDelayTime
Add the definition of selfDelay to the UML representation.
2. In PAM examples, many Steps have internal delay represented as a value of blockT, all of these should be changed to selfDelay.

Revised Text:

1. 
   modify domain text: modify last row and add a row to Table 15.1 which defines common NFP attributes for analysis:
   

old last row:

col 1: blockingTime: NFP_Duration[*]

col 2: blocking time (N/A)

col 3: a pure delay which is part of the behavior of the Step or Scenario

col 4: N/A

modified row:

col 1: blockingTime: NFP_Duration[*]

col 2: blocking time (N/A)

col 3: a pure delay waiting for passive resources to be available or an event controlled from elsewhere (value is an output variable)

col 4: N/A

additional row:

col1: selfDelay: NFP_Duration[*]

col2: delay

col3: a pure delay controlled or requested by the Step. (value is an input variable)

col4: N/A

(2) Fig 15.3, add attribute to GaStep class in domain model:

selfDelay:NFP_Duration[*]

(3) Fig 15.7, add attributes to GaStep class in profile:

selfDelay:NFP_Duration[*]

(4) Sec. 15.3.2.13, change the UML definitions:

old text:

• 
  blockT: NFP_Duration [*]:
  

a delay inserted in the execution of the Step.

new text:

• 
  blockT: NFP_Duration [*]
  

a delay inserted in the execution of the Step, waiting for an event controlled elsewhere (by another step or scenario), or for a condition such as the availability of passive protected resources nedded by the step but in use by preempted (i.e. lower priority schedulableResources) concurrent steps.

• 
  selfDelay: NFP_Duration [*]
  

a delay inserted in a Step, whose duration is controlled or requested by the Step (e.g. a sleep time).

{Precise editing instructions for applying resolution, including exact text, models, diagrams, references to be included or deleted. NOTE: IDL should be shown in Courier font}

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12402

Title: Specify a maximum number of period for periodic real-time constraints

Source:

Commissariat a l Energie Atomique-CEA/LIST (Mr. Chokri Mraidha, [e-mail])

Summary:

It would be nice to be able to specify a maximum number of period for periodic real-time constraints. Proposed modification: add a property named max of type Integer (multiplicity 0..1) in PeriodicPattern tupleType on page 437.

Resolution:

Add a new parameter for the periodic arrival pattern indicating the number of occurrences. This parameter is optional: multiplicity 0..1. So, it doesn’t need to be specified in the graphical view.

Revised Text:

-Modify the library of basic NFP data types, Fig. D-5 by adding a new parameter ‘occurrences: NFP_Integer’. (Note that the following figure also add the missing NFP type NFP_Weight: see Issue 12410)

-Add to class descriptions of Annex D (see Issue 11554 in Ballot 1 that adds class descriptions for arrival patterns), in Section D.2.3 PeriodicPattern, the attribute:

occurrences: NFP_Integer the number of occurrences of the periodic arrival event.
Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12410

Title: Type NFP_Weight does not exist

Source:

THALES (Mr. Sebastien Demathieu, [e-mail])

Summary:

HwComponent stereotype has a property named "weight" typed by "NFP_Weight". The type NFP_Weight does not exist in the document.

Resolution:

This NFP type was missing in the MARTE library.

Revised Text:

-Modify the library of basic NFP data types, Fig. D-5 by adding NFP_Weight (this figure takes into account Issue 12402 too)

-Modify the library of measurement units, Figure D-3 with:

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12414

Title: {title of the issue}

Source:

Thales; [e-mail]

Summary:

The Clock stereotype would need to extend UML::Property along with UML::InstanceSpecification, in order to make use of clocks in composite structures and interactions. This way, the Time chapter would be compliant with the "instance/classifier" pattern defined for resources.

Resolution:

Property is added as a base class for Clock

Revised Text:

Figure 9.26

Old:

New: (it is a visio picture)

Para 9.3.2

Old: (after solving issue 11847)

Extensions

• 
  InstanceSpecification (from UML::Classes::Kernel)
  

Generalizations

• 
  None
  

New:

Extensions

• 
  Property (from UML::Classes::Kernel)
  
• 
  InstanceSpecification (from UML::Classes::Kernel)
  
• 
  
  

Generalizations

• 
  None
  

Para 9.3.2.1 Clock

Old:

A Clock is a model element that represents an instance of ClockType. A Clock gives access to time. A Clock exists in a TimedDomain. A Clock maps to a TimeBase in the semantic domain. The stereotype specifies the unit of the Clock. A Clock is also characterized by its resolution, and optionally by its offset (its initial instant value) and its maximal value. The values of these attributes are contained in the slots of the stereotyped InstanceSpecification.
New:

Add the sentence:

A Clock can also be a stereotyped Property, so that it can be used in composite structure and interactions.
Disposition: Resolved