Omg issue Number

Disposition: Resolved

OMG Issue No: 11880

Title: HRM::HwMemory

Source:

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

Summary:

In HRM::HwMemory, I would suggest adding a throughput attribute (typed by a NFP_DataTxRate) to specificy the notion of throughput in a memory.

Resolution:

A throughput:NFP_DataTxRate attribute is added to the HwMemory, in both domain view and uml representation.

Revised Text:

Fig. 14-57 p.215 is modified as follow:

Fig 14-68, p.225 is modified as follow:

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11882

Title: “Missing Delay and Offset in SAM”

Suggested Title: “Replace Ambiguous SaStep::delayTime Tag Definition”

Source:

Universidad de Cantabria (Dr. Julio Medina, Julio DOT medina AT unican DOT es)

ARTiSAN Software (Mr. Lonnie VanZandt, lonnievz AT artisansw DOT com)

Summary:

In Section F.11.3, page 609, the pairing of the attribute SaStep::delayTime with the provided definition leads to cognitive dissonance due to use of the same term but with a different meaning in real-time programming when describing a schedulable entity that voluntarily yields the Processing Resource. The other reference to SaStep::delayTime is within Figure 16.4 on page 288.

If the attribute remains as a member of SaStep, the SAM sub-Profile requires a term to express a SaStep which voluntarily relinquishes the Processing Resource during a duration. An additional specialization of GaStep which includes offsets and delays SHOULD be added to the GQAM sub-Profile.

Rationale:

In real-time programming, a delay is a voluntary yield and is implemented with primitives like sleep, clock_nanosleep in POSIX, mdelay in linux, and delay in Ada. Note that there are active forms of delay, sometimes called spinning, where a task delays its execution without yielding its Processing Resource.

In one of the definitive texts in the field of Schedulability Analysis, “Real-time Systems”, Jane Liu defines the time that a schedulable entity is blocked from execution by lower priority entities that enter into nonpreemptible durations as “nonpreemption blocking”. She defines the time that a schedulable entity is blocked from execution due to voluntary self suspension as “self suspension blocking”. She further points out that one must also know the number of times a schedulable entity will suspend itself during its execution.
Although nonpreemption blocking typically arises when contending for shared resources, there is no need to restrict applicability of the term “nonpreemption blocking” to only the case where schedulable entities contend for shared resources. Therefore, the MARTE definition will simply state that it is due the nonpreemptibility of lower-priority schedulable entities.
Resolution:

Be explicit and conformant with existing practice: replace the attribute SaStep::delayTime with three new attributes, SaStep::nonpreemptionBlocking, SaStep::selfSuspensionBlocking, and SaStep::numberSelfSuspensions.

If an additional specialization of GaStep is needed—and arguably it is—then that SHALL be addressed in a new and separate issue allocated to GQAM.

Revised Text:

On page 288, remove SaStep::delayTime in Figure 16.4.

On page 288, add SaStep::nonpreemptionBlocking, SaStep::selfSuspensionBlocking, and SaStep::numberSelfSuspensions to Figure 16.4.

On page 609, remove entirely the phrase:

• delayTime: NFP_Duration [0..1] length of time that an step that is eligible for execution waits while acquiring and releasing resources.

On page 609, add these bullet phrases:

• nonpreemptionBlocking: NFP_Duration [0..1] maximum length of time within the context of the current SaStep that a ready SaStep is blocked while lower priority schedulable entities are nonpreemptible.

• selfSuspensionBlocking: NFP_Duration [0..1] maximum length of time within the context of the current SaStep that a ready SaStep voluntarily yields the Processing Resource.

• numberSelfSuspensions: NFP_Integer [0..1] maximum number of times an SaStep self suspends during its execution. (MUST be provided if selfSuspensionBlocking is provided.)

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11886

Title: use of stereotype names in UML model examples is inconsistent

Source:

Carleton University (Dr. Dorina C. Petriu, [e-mail])

Summary:

b) The first letter of a stereotype applied to a UML model element should be lower-case or upper-case (e.g., <> or <>) ? The use of stereotype names in UML model examples is inconsistent in different chapters: starting with lower-case in chapters 8, 9, 11, 12, 13, 14, 16, etc. and with upper case in chapters 10 (Figures 10.20 to 10.22), 17.

Resolution:

By convention, when a stereotype is applied to a model element, the first letter of the stereotype name must be lower-case. In the examples mentioned in the summary of the issue, the first letter of stereotype names must be set to lower-case.

Revised Text:

For the following figures, the first letter of stereotype names must be set to lower-case:

• 
  Fig 10.20, p.114
  
• 
  Fig 10.21, p.115
  
• 
  Fig 10.22, p.116
  
• 
  Fig 11.18, p.132
  
• 
  Fig 17.9, p.325
  
• 
  Fig 17.10, p.326
  
• 
  Fig 17.14, p.329
  
• 
  Fig 17.15, p.330
  
• 
  Fig 17.16, p.331
  
• 
  Fig 17.17, p.332
  
• 
  Fig 17.19, p.334
  
• 
  Fig 17.21, p.336
  
• 
  Fig 17.22, p.337
  
• 
  Fig 17.23, p.337
  
• 
  Fig 17.24, p.338
  
• 
  Fig 17.26, p.339
  
• 
  Fig 17.27, p.341
  

Disposition: Resolved