Issues for Mailing list of the Robot Technology Components (RTC) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 10477: Lightweight RTC package diagram
Issue 10478: RTC lifecycle state machine
Issue 10479: Sequence diagrams for activation/deactivation should be added
Issue 10480: Data flow diagrams
Issue 10481: Sequence diagrams for Data Flow Types should be added
Issue 10482: Stimulus response execution diagrams
Issue 10483: Modes of operation diagrams
Issue 10486: Stimulus response and modes of operation sequence diagrams should be added
Issue 10487: Introspection interfaces diagram
Issue 10488: Sequence diagrams for Introspection should be added
Issue 10489: Connector End omitted from diagram
Issue 10490: Inconsistent definition of LifeCycle::reset
Issue 10491: Inconsistent definition of ComponentAction callbacks
Issue 10492: Component can't reset another component
Issue 10493: Clarify contract between execution context and non-initialized components
Issue 10494: Update references to newest versions
Issue 10495: ComponentAction callbacks argument
Issue 10496: ExecutionContextAdmin should receive RTObject not ComponentProfile
Issue 10497: CORBA IDL definition of Port::connect
Issue 10532: It seems better to merge LifeCycle with LightweightRTObject
Issue 10533: Definition of Connector in PSM is unclear
Issue 10534: Type Mode is not clearly defined
Issue 10535: Typographical Errors
Issue 10559: CORBA IDL's syntax error
Issue 10601: refactoring of the ExecutionContext model element
Issue 11005: Page: 5, 11
Issue 11110: FINALIZED in LifeCycleState
Issue 11111: Diagrams do not agree with text

Issue 10477: Lightweight RTC package diagram (rtc-ftf)

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.)

Proposed Resolution

The element of !ExecutionContextEntity is added. This is because !ExecutionContext is defined as interface. I think it would be better that the element that realized !ExecutionContext was necessary and added it.

[attachment:lightweight-rtc-metamodel.png] [[BR]] Meta-Model

[attachment:lightweight-rtc-stereotype.png] [[BR]] Stereotype

Discussion

I agree with the reorganization of the diagrams. Regarding !ExecutionContextEntity: if a class would be clearer/more useful than an interface, I think it would be better to just make !ExecutionContext a class instead of introducing a new type. -- RickWarren, 2006/11/27

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

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

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

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

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

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

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

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

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

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

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

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

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) {
    myComponent.reset(contexts[i]);
}

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

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

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

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 {
  UniqueIdentifier attach_executioncontext(in ExecutionContext exec_context);
  ReturnCode_t detach_executioncontext(in UniqueIdentifier ec_id);
  ReturnCode_t on_initialize();
  ReturnCode_t on_finalize();
  ReturnCode_t on_startup(in UniqueIdentifier ec_id);
  ReturnCode_t on_shutdown(in UniqueIdentifier ec_id);
  ReturnCode_t on_activated(in UniqueIdentifier ec_id);
  ReturnCode_t on_deactivated(in UniqueIdentifier ec_id);
  ReturnCode_t on_aborting(in UniqueIdentifier ec_id);
  ReturnCode_t on_error(in UniqueIdentifier ec_id);
  ReturnCode_t on_reset(in UniqueIdentifier ec_id);
 };

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 {
    typedef UNIQUE_ID_NATIVE UniqueId;
    // ...
};

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

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 {
   ExecutionContextProfile get_profile();
   ReturnCode_t add(in ComponentProfile comp_profile, in long index);
   ReturnCode_t remove(in ComponentProfile comp_profile);
 };

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 {
   ExecutionContextProfile get_profile();
   ReturnCode_t add(in RTObject comp, in long index);
   ReturnCode_t remove(in RTObject comp);
 };

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

-- Noriaki Ando, 2006/12/4

Revised Text

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 {
   PortProfile get_port_profile();
   ConnectorProfileList get_connector_profiles();
   ConnectorProfile get_connector_profile(in UniqueIdentifier connector_id);
   ReturnCode_t connect(in ConnectorProfile connector_profile);
   ReturnCode_t disconnect(in UniqueIdentifier connector_id);
   ReturnCode_t disconnect_all();
 };

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 {
   ReturnCode_t connect(inout ConnectorProfile connector_profile);
 };

-- Noriaki Ando, 2006/12/4

Discussion

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

Resolution

Revised Text

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.

 like the proposal. -- RickWarren, 2006/12/12

[attachment:20061220LWRTC2.png]
LightweightRTC Example(non-normative)

I drew Component diagram example(non-normative). -- Takeshi Sakamoto, 2006/12/14

Resolution

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).

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

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

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
  {
    abbr.:
  };
  
  interface ExecutionContextService : ExecutionContext, SDOPackage::SDOService
  {
    abbr.:
  };
  
  interface RTObject : LightweightRTObject, SDOPackage::SDO
  {
    abbr.:
  };

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."

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[

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.

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