Summary

Like Figure 7.2 Lightweight RTC package,I think it would be better that Figure 7.6 Data flow type be divided into several diagrams.

In terms of the Stereotype description, dataFlowComposite (Page 33) and dataFlowParticipant (Page 35), since there is a description, "The dataFlowComposite stereotype may only be applied to a component that is also extended by the lightweightRTComponent stereotype or some subtype thereof" in Constraints, I think it would be better to take over the lightweightRTComponent stereotype. If lightweightRTComponent is taken over, the stereotype that takes over the characteristics of lightweightRTComponent is only one, either dataFlowComposite or dataFlowParticipant, and the description in Constraints can be deleted.

Proposed Resolution

[attachment:data-flow-metamodel.png] [[BR]] Meta-Model

[attachment:data-flow-stereotypes.png] [[BR]] Stereotypes

Discussion

I agree with the reorganization of the diagrams. I'm not sure about the stereotypes, though. By "take over the lightweightRTComponent stereotype," you mean define dataFlow* as subtypes of lightweightRTComponent? I think there may be a problem with that when multiple stereotypes are used. If a component has both dataFlowParticipant and dataFlowComposite, the lightweightRTComponent stereotype will really be there twice. I don't know whether that's a problem in UML, but when it is mapped to IDL and then to code, it will result in diamond inheritance, which can be inconvenient.

– RickWarren, 2006/11/27

Sakamot-san's comment.

Although two stereotypes have inheritance relation in stereotypes definition, they need not have inheritance relation in implementation.

• The stereotype definition defines how the meta-class (in our case, it is Component) should be extended.
• The inheritance (or generalization) makes the feature that is defined in the upper-class take over to a lower-classes as it is.
• According to the stereotype inheritance, the lower-classes can use extension method that is defined in upper-class.

Since the stereotype defines only meta-classes extension, it does not limit implementation or PSM.

– NoriakiAndo, 2006/12/4

Unify the dataFlowParticipant and dataFlowComposite stereotypes. The combined stereotype will extend the lightweightRTComponent stereotype directly.

Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Supporting Text

Disposition: Resolution Proposed

Summary

Like Figure 7.6 Data type flow, I think it would be better that Figure 7.12 Mode of operation be divided into several diagrams.

Proposed Resolution

[attachment:modes-metamodel.png] [[BR]] Meta-Model

[attachment:modes-stereotypes.png] [[BR]] Stereotypes

Discussion

Revised Text

Add diagrams as described below.
Also, the relationships among the stereotypes should be changed in the same way as the Data Flow stereotypes, as described in issue 10480.

Source: Technologic Arts (Takeshi Sakamoto, <tsakamoto AT SPAMFREE tech-arts DOT co DOT jp>)

Severity: Supporting Text

Disposition: Resolution Proposed

Summary

Like Figure 7.6 Data type flow, I suggest it would be better that Figure 7.9 Stimulus response execution be divided into several diagrams.

Proposed Resolution

[attachment:stim-response-metamodel.png]
Meta-Model

[attachment:stim-response-stereotypes.png]
Stereotypes

Discussion

Revised Text

Add diagrams as described below.
Simplify the relationships between the lightweightRTComponent stereotype and the fsm and fsmParticipant stereotypes as described below.
Add missing programmatic APIs for sending stimuli to state machine components.

Source: Technologic Arts (Takeshi Sakamoto, <tsakamoto AT SPAMFREE tech-arts DOT co DOT jp>)

Severity: Minor

Disposition: Resolution Proposed

Summary

The state machine diagram and the sequence diagram are related as follows.

[attachment:sequence-with-fsm.png]

Transition (Event) in the state machine diagram responds to operation called by other elements, and actions in the state respond to operation calls other elements operation. In Figure 7.4 RTC lifecycle, it describes operation that owned ExecutionContextEntity for Transition (Event) among Inactive state and Active states. Also, there is an explanation: "When an RTC is in Error, it may be reset. If resetting is successful, the RTC shall return to the Inactive state. If resetting is unsuccessful, it shall remain in the Error state" (Page 14). But Figure 5 describes that whenever "LifeCycle::reset" is called, it should transition from Error state to Inactive state for sure. Considering these points, I think that state machine diagram (part) about RTC becomes the following.

Proposed Resolution

[attachment:rtc-lifecycle3.png]

Discussion

I agree with the movement of the reset operation from LifeCycle to ExecutionContext. However, the updated diagram implies some behaviors that seem unusual to me. Are these intended?

*

When a component first enters the Alive state, it will receive an on_deactivate message even though it has never been Active.
*

A component leaving the Active state for the Error state will not receive an on_deactivate message.
*

on_reset occurs only when exiting the Error state, meaning after reset_component() has returned successfully. But the result from reset_component() should be based on the result from on_reset().

The only transition in the original lifecycle diagram that looks problematical to me is the reset transition. What if we keep the original diagram with the following two small changes:

*

change LifeCycle::reset to ExecutionContext::reset_component
*

add a guard condition [return == OK]

Would that address the concerns?

– RickWarren, 2006/12/1

Yes. The state machine diagram included some mistakes. Sakamoto-san corrected it. The state machine diagram was updated.

*

on_deactivate was moved from Inactive entry action to Active exit action.
*

Therefore, when a component does transition from "Active" state to "Error" or to "Inactive", now the component receives on_deactivate message.
*

If on_reset() returns error, "Error" state would not move to "Inactive" state.

– NoriakiAndo, 2006/12/4

The lifecycle is currently modeled as belonging to a component itself and having parallel regions corresponding to the execution context in which the component participates. This relationship should be reversed. The lifecycle should belong to the execution context and have parallel regions for the participating components. That change will give the transitions the correspondence to sequence diagram messages that is described above.

Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

Which is correct as for the on_aborting and on_reset callbacks on ComponentAction?

on_aborting(ExecutionContext) : void

Figure 7.2 (Page 11)

on_aborting(ExecutionContext) : ReturnCode_t

Table (Page 19) and RTC IDL (Page 76) and mars/2006-09-34 (Example C++ header)

on_reset(ExecutionContext) : void

Figure 7.2 (Page 11)

on_reset(ExecutionContext) : ReturnCode_t

Table (Page 19) and RTC IDL (Page76) and mars/2006-09-34 (Example C++ header)

Discussion

Is it useful for on_aborting to return an error if the component is already transitioning to an error state? I suppose the middleware implementation could log it.... – RickWarren, 2006/11/27

Resolution

I would propose that all callbacks, including on_aborting and on_error, should return ReturnCode_t instead of void to be consistent. The middleware implementation may choose to log the error or do something else; no particular behavior is required. – RickWarren, 2006/12/1

Do you mean that activate_component only returns the result of on_activate, and for example on_aborting does not relate with activate_component operation call? The specification has the following three sets of events and callbacks.

*

activate_component event only assumes that on_activate has finished before it returns.
*

deactivate_component event only assumes that on_deactivate has finished before it returns.
*

reset_component event only assumes that on_reset has finished before it returns. (If reset_component operation in FTF-12 is adopted.)

If so, I agree the above Rick's proposal. I think that the more details beyond it should be left as implementation-defined matter.

– NoriakiAndo, 2006/12/4

Revised Text

The return types of the ComponentAction callbacks are addressed in issue 10477, which updates the figure in question, Figure 7.2. With respect to that matter, this issue shall be considered a duplicate.
The remainder of this issue is addressed as follows:
· activate_component assumes that on_activate has finished before it returns.
· deactivate_component assumes that on_deactivate has finished before it returns.
· reset_component assumes that on_reset has finished before it returns.
· Remove extra arguments from on_transition and on_mode_changed

ource: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

Which is correct as for the definition of !LifeCycle::reset?

reset(ExecutionContext) : ReturnCode_t

...as in Figure 7.2 (Page 11) and Table (Page 15)

Or:

reset() : ReturnCode_t

...as in RTC IDL (Page 75) and mars/2006-09-34 (Example C++ header)

Discussion

Resetting is relative to a particular execution context (see the lifecycle state machine), so I think it has to be the former:

reset(ExecutionContext) : ReturnCode_t

– RickWarren, 2006/11/27

Resolution

There has been a suggestion to move reset to ExecutionContext to make it similar to activate_component, deactivate_component, and get_component_state. The new operation would be called reset_component. The ExecutionContext would therefore be a kind of "manager" for the component's per-context state. – RickWarren, 2006/12/1

Revised Text

Resetting a component is relative to a given execution context. This behavior should be mediated by the context, just like component activation/deactivation. Move the reset operation to ExecutionContextOperations as reset_component.

Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Supporting Text

Disposition: Resolution Proposed

Summary

At the Figure 7.1 Simplified depiction of components and their constituents from [UML], it describes Meta model related to Component but only Connector End is omitted as an element. Do we need to add Connector End? Was Connector End omitted because of the relationship with Profile?

Proposed Resolution

[attachment:uml-components.png]

Discussion

I think I created that diagram. I left out ConnectorEnd because I wanted to include only those things that were discussed in the specification. Component is necessary, of course. Property is the supertype of Port, but is also used to represent contained component instances. Ports have Interfaces, and Connectors join them together. ConnectorEnd is not mentioned in this specification, so I did not think it was necessary to show it. Do you think it is important? – RickWarren, 2006/12/1

Revised Text

ConnectorEnd is omitted for the sake of simplicity because it is not discussed in this specification.

ource: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Supporting Text

Disposition: Resolution Proposed

Summary

Just like RTC, I think it is difficult to understand behavior. I think it would be better that following sequence diagram is added.

Proposed Resolution

[attachment:introspection-connect-sequence.png] [[BR]] Connect

[attachment:introspection-disconnect-sequence.png] [[BR]] Disconnect

Discussion

Revised Text

Add diagrams as described below.

Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Supporting Text

Disposition: Resolution Proposed

Summary

Like Figure 7.2 Lightweight RTC package,I think it would be better that Figure 17 Introspection interfaces be divided into Meta model and the Interface description.

Proposed Resolution

[attachment:introspection-metamodel.png] [[BR]] Meta-Model

Discussion

Revised Text

Add diagrams as described below.
The interface Port has a confusing name, because it is the same as the Port type from UML itself. Rename the interface.

OMG ISSUE 10484: Stimulus response and modes of operation sequence diagrams should be added

Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Supporting Text

Disposition: New

Summary

Just like RTC, I think it is difficult to understand behavior about Stimulus Response Excution and Modes of operation.

Discussion

Resolution

Revised Text

Add diagrams as described below.

ource: Technologic Arts (Takeshi Sakamoto, <tsakamoto AT SPAMFREE tech-arts DOT co DOT jp>)

Severity: Supporting Text

Disposition: Resolution Proposed

Summary

Just like RTC, I think it is difficult to understand behavior.

Proposed Resolution

I think it would be better that following sequence diagrams is added.

[attachment:periodic-sequence.png]
Steady state

[attachment:periodic-set-rate.png]
Set rate

Discussion

Revised Text

I think it would be better that following sequence diagrams is added.

everity: Support Text

Disposition: Resolution Proposed

Summary

I think it is difficult to understand behavior. I think it would be better that sequence diagrams is added.

Proposed Resolution

[attachment:rtc-activate-sequence.png] [[BR]] Activate

[attachment:rtc-activate-sequence2.png] [[BR]] Activate (Updated)

[attachment:rtc-deactivate-sequence2.png] [[BR]] Deactivate

Discussion

According to the update of the state machine diagram in FTF-2 issue, Activate sequence diagrams was updated.

– NoriakiAndo, 2006/12/4

Should callbacks be executed in the thread of the method that triggered the callback or in the thread of the execution context they refer to? For example, if I call myContext::activate_component(myComp) and the activation fails, should on_aborting be called in my calling thread or in the thread represented by myContext?

• Can the choice of thread be left to the implementation?
• Can the observed concurrency be left to the implementation? That is, if activate_component returns with a failure, can I assume that on_aborting has already been called?

I would propose that:

• The specification already says that the relationship between execution contexts and physical threads is implementation-defined. Therefore, components should not make any assumption about what thread they are called from. The callback argument identified the relevant context; that is the only important thing.
  *

The observed behavior of the callback should be synchronous with the method that resulted in the callback. For example, if I call activate_component, I can assume that on_activate will have finished before activate_component returns. This behavior simplifies error propagation and the programming model in general.

– RickWarren, 2006/12/4

Add the non-normative example diagrams as described below.

ource: AIST (Noriaki Ando, [[MailTo(n-ando AT SPAMFREE aist DOT go DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

The Port interface is defined as follows,

interface Port : Service

;

The argument of Port::connect(in ConnectorProfile) is defined as in argument. Because of it, Ports cannot exchange connection information via ConnectorProfile.

To exchange connection information between Ports, ConnectorProfile argument should be inout.

interface Port : Service

;

– Noriaki Ando, 2006/12/4

Discussion

Above mentioned issue would depend on Port'c connection sequence. – Noriaki Ando, 2006/12/4

Resolution

Revised Text

A resolution for this issue can be combined with the resolution of issue 10488.

Source: AIST (Noriaki Ando, [[MailTo(n-ando AT SPAMFREE aist DOT go DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

ExecutionContextAdmin has no way to know RTObject itself. ExecutionContextAdmin is defined as follows,

interface ExecutionContextAdmin : ExecutionContext, Service

;

ComponentProfile does not include RTObject's reference (or pointer or object reference). Therefore ExecutionContextAdmin cannot call RTObject (or related classed for example ComponentAction, etc..)

– Noriaki Ando, 2006/12/4

Discussion

Resolution

The definition of the ExecutionContextAdmin should be as follows,

interface ExecutionContextAdmin : ExecutionContext, Service

;

Since RTObject has get_component_profile operation, ExecutionContextAdmin can access the component profile.

– Noriaki Ando, 2006/12/4

Revised Text

The add and remove operations are generally useful, not only for introspective RTCs but for all RTCs, because they effectively define an interface between a component and its hosting middleware (which will likely provide the execution context). Therefore, move the add and remove operations from ExecutionContextAdmin to ExecutionContextOperations and change the argument type from ComponentProfile to LightweightRTObject.
These add and remove operations should be complemented by attach/detach operations on the RTC itself to inform it of its participation in the context and to associate the context with an identifier ("ExecutionContextHandle_t") relative to that component (see issue 10495). To make callback operations less expensive in distributed environments, all callback operations should be passed these identifiers instead of ExecutionContext references.

Source: RTI (Rick Warren, [[MailTo(rick DOT warren AT SPAMFREE rti DOT com)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

The behavior of various !ExecutionContext methods (start, stop, activate_component, deactivate_component) are not fully specified in the case where a component has either (a) never been initialized, or (b) been finalized.

Discussion

Resolution

The behavior should be as follows:

• A context should not be allowed to start until all of its components are initialized. A failure should be indicated with PRECONDITION_NOT_MET.
• Before a component can be finalized, all contexts in which it participates must be stopped. A failure should be indicated with PRECONDITION_NOT_MET.
• Attempting to activate or deactivate a component that is not initialized or has been finalized should fail with PRECONDITION_NOT_MET.

The following sequence diagrams are examples (thanks, Sakamoto-san):

[attachment:rtc-initialize-sequence.png] [[BR]] Initialize and start

[attachment:rtc-finalize-sequence.png] [[BR]] Stop and Finalize

– RickWarren, 2006/12/1

Revised Text

The behavior should be as follows:
· A context should not be allowed to start until all of its components are initialized. A failure should be indicated with PRECONDITION_NOT_MET.
· Before a component can be finalized, it must be detached from all contexts in which it participates. A failure should be indicated with PRECONDITION_NOT_MET.
· Attempting to activate or deactivate a component that is not initialized or has been finalized should fail with BAD_PARAMETER.

Source: RTI (Rick Warren, [[MailTo(rick DOT warren AT SPAMFREE rti DOT com)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

The message to reset a component will usually come from another component. If a component resets itself, it can know which context has the error, so there is no problem. But if a different component wants to reset it, there is no way for it to know which context is the correct one.

Discussion

Resolution

I think we can solve this problem with a new method:

ExecutionContext[] LifeCycle::get_contexts()

The code would look something like this:

ExecutionContext[] contexts = myComponent.get_contexts();
//...
if (contexts[i].get_component_state(myComponent) == ERROR_STATE)

The usage is demonstrated in the following sequence diagram (which also shows a proposed move of the reset() operation from the component itself to the execution context – thanks, Sakamoto-san):

[attachment:rtc-reset-sequence.png]

– RickWarren, 2006/12/1

Revised Text

It is already possible to determine the state of a component in a given context with the ExecutionContextOperations::get_component_state operation. Therefore, the only functionality that is missing is the ability to learn in which context(s) a component participates and which context is associated with which handle. Add operations to provide that information.
The existing method RTObject::get_execution_context_services provides a subset of the functionality proposed here. It should be replaced with a more complete functionality.

n CORBA IDL does not allow interface's typedef. See CORBA specification, v3.0.3 http://www.omg.org/cgi-bin/apps/doc?formal/04-03-12.pdf Some IDL compilers complain that typedefed DistributedObject and Service are not interface but type when they are used as base interface.

omniORB and TAO's idl compiler allow interface typedef. MICO and ORBit2 IDL compiler does not allow interface typedef.

Proposed Resolution

The following typedefs should be deleted.

typedef SDOPackage::SDO DistributedObject;
typedef SDOPackage::SDOService Service;

and, the Port, ExecutionContextService and RTObject should be changed like this.

interface Port : SDOPackage::SDOService

;

interface ExecutionContextService : ExecutionContext, SDOPackage::SDOService

;

interface RTObject : LightweightRTObject, SDOPackage::SDO

;

Remove the typedefs for SDOPackage::SDO and SDOPackage::SDOService; use the original types instead.

I will report several minor problems that seems not worth registering as separate issues.

Typographical errors

6.1 Requirements [[BR]] Systematic execution: The execution ordering of modules within an *R* application ...

7.2.2.3 !LifeCycle [[BR]] At any other time, it shall not be required to *performs* any ongoing activity of its own; ...

Wording inconsistency

7.3 Execution sementics [[BR]] ... stimulus response processing (also known as discrete events), ...

7.3.2 Stimulus Response Processing [[BR]] The stimulus response design pattern is also referred to as asynchronous event processing.

Discussion

We should collect all such errors we find in this issue and vote on them together at the very end so that we don't end up with many issues that are so trivial. – RickWarren, 2006/12/13

See the corrections noted below.

In some diagrams (ex.Figure7.14), the subject matter of diagram is different from an explanation texts.

A Resolution for this issue can be combined with the resolution of Issues 10478, 10480, 10482, 10483, 10486, 10488 and 10492.
Revised Text:
None
Disposition: Merged (with 10478,10480,10482,10486,10488 and 10492)

Source: AIST (Noriaki Ando, [[MailTo(n-ando AT SPAMFREE aist DOT go DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

ComponentAction callbacks (on_startup, on_shutdown, on_activate, on_deactivate, on_aborting, on_error, on_reset) receive ExecutionContext as argument. In CORBA IDL PSM, this is directly described as follows.

interface ComponentAction {
:
ReturnCode_t on_activated(in ExecutionContext exec_context);
:
};

However, these operations only use the given context as monicker to know which ExecutionContext is calling the operation. Since the cost of an operation call giving a pointer as an argument may be low, ExecutionContext's pointer is one of better moniker of the ExecutionContext, in local mapping. In CORBA, however, giving object reference as a moniker of ExecutionContext costs very high. Especially, if DataFlowParticipant's on_execute operation would be called in real-time loop, very heavy servant side object reference creation would happen in each period. These operations only need moniker to identify the ExecutionContext, and the moniker would be PSM dependent matter.

– Noriaki Ando, 2006/12/4

Discussion

Resolution

I'd like to propose the following CORBA IDL.

interface ComponentAction

;

In ExecutionContextAdmin::add, attach_executioncontext would be called. ExecutionContext that calls ComponentAction's callback is notified by using attach_executioncontext and it returns a unique identifier (it may be unique only in the ComponentAction).

– Noriaki Ando, 2006/12/4

I like the proposal. Because of the dependencies between RTC and SDO, the definition of UniqueIdentifier cannot be reused from SDO. But there is a useful pattern for this situation in the DDS specification:

#define UNIQUE_ID_TYPE_NATIVE long
module RTC

;

The meaning is that the representation of the UniqueId type is outside of the RTC module, so implementations are free to choose their own. Implementations built on top of SDO can use:

#define UNIQUE_ID_TYPE_NATIVE SDO::UniqueIdentifier

...but other implementations can choose something else. – RickWarren, 2006/12/4

Revised Text

Define an ID to represent an execution context in the callbacks. Provide operations to map between the ID and the object reference for callback implementations that require that information.
A resolution for this issue can be combined with the resolution of issue 10496.
Disposition: See issue 10496 for disposition

Source: RTI (Rick Warren, [[MailTo(rick DOT warren AT SPAMFREE rti DOT com)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

The RTC specification refers to now-out-of-date versions of other specifications. These references should be updated. Examples include:

• XMI (XMI file uses XMI 2.0; should be 2.1)
• LwCCM (spec uses LwCCM 1.0; should be CCM 4.0, which includes LwCCM)

UML is also in the middle of an update from 2.0 to 2.1. If that FTF finishes in time, we should update that reference as well.

Discussion

Resolution

Revised Text

· Update XMI file format from version 2.0 to version 2.1.
· Update UML from version 2.0 to version 2.1.1.
· Replace references to Lightweight CCM 1.0 to CCM 4.0.

Type Mode is not clearly defined in the current specification.

*

Mode is used but not defined in PIM.
*

In the IDL, Mode is defined as an interface but it seems better to be an enumeration.
*

ModeList is defined but never used.
*

Since supported modes may vary between components, using a common Mode type in all components may not be useful.

Proposed Resolution

*

Define Mode as an integer in PIM and PSM/IDL, and let the component developer assign arbitrary numbers to modes of the component.
*

Delete ModeList from the IDL.

Discussion

I myself think using integer as Mode is not so good manner. – Saku Egawa

It is not correct that Mode is not defined in the PIM. It is defined in section 7.3.3.5. It is a class with no attributes or operations. Even though there are not currently any operations, a mode is semantically an object, and so the type should remain a class. An enumeration is not appropriate, because there are no well-known instances that are common to all mode-capable components; each component implementation defines its own.
ModeList should be removed from the IDL. It is left over from a previous draft of the specification and is obsolete.

Description for Connector in PSM seems confusing or insufficient.

In the first paragraph of 8.3.3 (Connectors, Local PSM), Connector is defined as a data instance. This seems to reflect the definition of Interface in 8.3.2 that allows using simple data instead of implementing "interfaces in the IDL sense". On the other hand, the last paragraph of 8.3.3 describes an implementation issue for method-type interface.

• It is unclear whether it is mandatory to use data instances for interfaces and connectors in local PSM.
• The multiple connection issue described in the last paragraph of 8.3.3 seems also applicable to CORBA PSM.

Proposed Resolution

• Modify 8.3.2 and 8.3.3 as either one of the follwoing:
  o If it is mandatory to use data instances for interfaces and connectors in local PSM, change "UML interfaces may be represented" in 8.3.2 to "UML interfaces shall be represented" and delete last paragraph of 8.3.3.
  o If it is allowed to use both data instances and method-type interfaces, modify 8.3.3 like: "In the case of using data instances as interfaces, .... In the case of using method call as interfaces ..."
• Add the multiple connection isssue to 8.5.2 (Mapping for Connectors, CORBA PSM).

It is not mandatory to use data-only types for ports and connectors in the Local PSM. Therefore, section 8.3.2 does not need to be changed. However, section 8.3.3 is written in a confusing way and should be updated.
CORBA-not including support for CORBA Component Model-does not include an explicit concept of connector objects. Therefore, the multiple connector mechanism described in section 8.3.3 is not applicable to the CORBA PSM.

Originally, LightweightRTObject was an interface that just combines LifeCycle and ComponentAction. It existed for convenience to characterize lightweightRTC by a single interface. However, in the discussion of issue 10492, an operation, get_context(), was added to LightweightRTObject and its role was changed.

LightweightRTObject is now an interface that defines basic operations for lightweightRTComponent except business logic operations defined by ComponentAction. Since the role of LifeCycle is also to provide basic component operations, it is no longer needed to define LifeCycle as a seperate interface. The model will become simpler and more clearly understandable if LifeCycle is merged with LightweightRTObject.

Proposed Resolution

Move LifeCycle operations to LightweightRTObject and delete LifeCycle.

Merge the contents of the LifeCycle interface into the LightweightRTObject interface and remove the LifeCycle interface.

The model element ExecutionContext, which is currently an interface, has association ends and a state machine. Therefor, it would be more correct to model it as a Class instead. Its operations can be moved to a new Interface "ExecutionContextOperations" that will be implemented by the Class ExecutionContext."

ExecutionContext should be a Class so that it can have a state machine and association ends. However, a separation between Class and Interface is felt to be a good design. Therefore, the operations of ExecutionContext shall be moved to a new Interface ExecutionContextOperations, and ExecutionContext itself shall become a Class.

Originally, LifeCycleState has FINALIZED attribute. I think that FINALIZED is not necessary. Because FINALIZED is compatible with Final state of statemachine. (I think that it cannot transit from FINALIZED to other states.)

In some language (such as Java), it is possible to call LightweightRTObject::finalize on the object and still have a valid object reference. But I think that it depends on implementation in PSM level. So I think that FINALIZED in LifeCycleState is not necessary in PIM level.

Remove the FINALIZED in LifeCycleState.

Typos Sec. 6.1, 4th bullet. Correct "Systematic execution: The execution ordering of modules within an R application ..." Fig. 7.4: incorrect closing square bracket – Inactive[n[

A resolution for this issue can be combined with the resolution of issue 10535.

At the Figure 7.2 Lightweight RTC package, it explains about Lightweight RTC but followings are mixed in the diagram.

• Meta model:
  o Describes how each model element relates to other elements. Since it is a model that focused on the static relationship among elements, it does not describe operation usually.
• Stereotype description
  o Describes what the base elements such as Component, elements already described for the elements described newly in the specification, are and what additive attributes are .
• Interface description
  o Describes what sort of operation each element has.

In the OMG specification, it seems that the elements are categorized and described in separate diagrams mostly. Therefore, I think it would be better if the diagram should be divided as follows. (I think it would be better that Interface description should be described at the beginning of explanation about individual element.)

Add diagrams as described below