Omg issue Number

Disposition: Resolved

OMG Issue No: 11832

Title: Tiler stereotype (pp 465,466)

Source:

INRIA (Mr. Pierre Boulet, [e-mail])

Summary:

a default value should be specified for the various attributes as it is done for the TilerSpecification data type; the type of the tiler attribute should be TilerSpecification

Resolution:

Add various default values in the descriptions of the stereotypes as in the TilerSpecification and modify the type of the tiler attribute to TilerSpecification.

Revised Text:

Page 466, replace

Attributes

• origin: MARTE_Library::MARTE_DataTypes::IntegerVector [0..1]

specifies the origin of the reference tile in the array.

• fitting: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1]

specifies how the pattern is mapped to a tile in the array with respect to a reference element.

• paving: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1]

specifies how an index in the repetition space is mapped to the reference point of a tile with respect to the reference tile.

• tiler: Tiler [0..1]

can be use as an alternative to the three previous attributes to specify the origin, fitting and paving using a Tiler object.

by

Attributes

• origin: MARTE_Library::MARTE_DataTypes::IntegerVector [0..1]

specifies the origin of the reference tile in the array. If it is absent, the origin is the zero vector of dimension the dimension of the array.

• fitting: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1]

specifies how the pattern is mapped to a tile in the array with respect to a reference element. If it is not specified, the fitting matrix is the identity matrix.

• paving: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1]

specifies how an index in the repetition space is mapped to the reference point of a tile with respect to the reference tile.

• tiler: TilerSpecification [0..1]

can be use as an alternative to the three previous attributes to specify the origin, fitting and paving using a Tiler object.

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11833

Title: E.4 Examples (pp 467,468)

Source:

INRIA (Mr. Pierre Boulet, [e-mail])

Summary:

put square brackets around the shapes on the diagrams

Resolution:

Correct all the diagrams of the examples to add the required brackets.

Revised Text:

Replace figure 8 by

and replace its caption

Figure E.82 - D repetition of a FFT component

by

Figure E.8 - 2D repetition of a FFT component

Replace figure 9 by

Replace figure 10 by

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11834

Title: Figure E.10 (p 468)

Source:

INRIA (Mr. Pierre Boulet, [e-mail])

Summary:

the fitting of the toTiler should be {{0,0}}.

Resolution:

Change the fitting as suggested.

Revised Text:

Resolved as part of the resolution of issue 11833. The figure E.10 replacement solves both issues. It is repeated below for completeness.

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11835

Title: RTEConnector should be removed from RTEMoCC

Source:

THALES (Mr. Sebastien Demathieu, Sebastien DOT demathieu AT thalesgroup DOT com)

Summary:

The RTEConnector should be removed from RTEMoCC. This concept overlaps with GRM::CommunicationMedia. All that relates to NFP characteristics of a communications between entities should be defined in GRM::CommunicationMedia (latency, jitter, bandwith) As a beneficial side effect, removing RTEConnector would remove the dependency from RTEMoCC to GCM, as it is not used anywhere else within RTEMoCC.

Rationale:

Chapter 13 builds upon the MARTE foundation packages (e.g. GRM) to define a model of computation for active objects and passive objects and defines the metaclasses involved in this model of computation. Then, Chapter 13 introduces the concept of RteConnector, which is a specialization of a UML connector with additional NFP. Although the definition of active and passive objects provides useful features for RTES design, the specification of the specification of a real-time connector is more controversial.

Resolution:

Remove RTEMoCC::RteConnector and refactor GRM::CommunicationsMedia to gain the attributes of the deleted RteConnector, and update the elements that use similar attributes in the rest of the spec so that they become consistent, that is at least in HwMedia.

Revised Text:

Delete Figure 13.7 and the last paragraph of page 154 which continues onto page 155.

Delete entirely Section 13.3.2.8 on page 161.

Delete entirely Section F.7.11 on page 549.

Delete attribute bandwith in the definition of HwMedia in section 14.2.3.2, in section F.9.28, and in Figure 14.70

In Section 10.3.2.4, on page 101, add the following bullet phrases:

• bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink.

• packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize.

• blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum.

• transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}.

In Section F.4.7, on page 515, add the following bullet phrases:

• bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink.

• packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize.

• blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum.

• transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}.

In Figure 10.8, on page 91, show the attributes for CommunicationMedia as stated in Section 10.3.2.4.

Disposition: Resolved