Robotic Technology Component Avatar
  1. OMG Specification

Robotic Technology Component — All Issues

  • Acronym: RTC
  • Issues Count: 28
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
RTC-29 Data flow diagrams RTC 1.0b1 RTC 1.0 Resolved closed
RTC-7 Modes of operation diagrams RTC 1.0b1 RTC 1.0 Resolved closed
RTC-6 Stimulus response execution diagrams RTC 1.0b1 RTC 1.0 Resolved closed
RTC-3 RTC lifecycle state machine RTC 1.0b1 RTC 1.0 Resolved closed
RTC-13 Inconsistent definition of ComponentAction callbacks RTC 1.0b1 RTC 1.0 Resolved closed
RTC-12 Inconsistent definition of LifeCycle::reset RTC 1.0b1 RTC 1.0 Resolved closed
RTC-11 Connector End omitted from diagram RTC 1.0b1 RTC 1.0 Resolved closed
RTC-10 Sequence diagrams for Introspection should be added RTC 1.0b1 RTC 1.0 Resolved closed
RTC-9 Introspection interfaces diagram RTC 1.0b1 RTC 1.0 Resolved closed
RTC-8 Stimulus response and modes of operation sequence diagrams should be added RTC 1.0b1 RTC 1.0 Resolved closed
RTC-5 Sequence diagrams for Data Flow Types should be added RTC 1.0b1 RTC 1.0 Resolved closed
RTC-4 Sequence diagrams for activation/deactivation should be added RTC 1.0b1 RTC 1.0 Resolved closed
RTC-19 CORBA IDL definition of Port::connect RTC 1.0b1 RTC 1.0 Resolved closed
RTC-18 ExecutionContextAdmin should receive RTObject not ComponentProfile RTC 1.0b1 RTC 1.0 Resolved closed
RTC-15 Clarify contract between execution context and non-initialized components RTC 1.0b1 RTC 1.0 Resolved closed
RTC-14 Component can't reset another component RTC 1.0b1 RTC 1.0 Resolved closed
RTC-24 CORBA IDL's syntax error RTC 1.0b1 RTC 1.0 Resolved closed
RTC-23 Typographical Errors RTC 1.0b1 RTC 1.0 Resolved closed
RTC-28 Diagrams do not agree with text RTC 1.0b1 RTC 1.0 Resolved closed
RTC-17 ComponentAction callbacks argument RTC 1.0b1 RTC 1.0 Resolved closed
RTC-16 Update references to newest versions RTC 1.0b1 RTC 1.0 Resolved closed
RTC-22 Type Mode is not clearly defined RTC 1.0b1 RTC 1.0 Resolved closed
RTC-21 Definition of Connector in PSM is unclear RTC 1.0b1 RTC 1.0 Resolved closed
RTC-20 It seems better to merge LifeCycle with LightweightRTObject RTC 1.0b1 RTC 1.0 Resolved closed
RTC-25 refactoring of the ExecutionContext model element RTC 1.0b1 RTC 1.0 Resolved closed
RTC-27 FINALIZED in LifeCycleState RTC 1.0b1 RTC 1.0 Resolved closed
RTC-26 Page: 5, 11 RTC 1.0b1 RTC 1.0 Resolved closed
RTC-2 Lightweight RTC package diagram RTC 1.0b1 RTC 1.0 Resolved closed

Issues Descriptions

Data flow diagrams

  • Key: RTC-29
  • Legacy Issue Number: 10480
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 19:48 GMT

Modes of operation diagrams

  • Key: RTC-7
  • Legacy Issue Number: 10483
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stimulus response execution diagrams

  • Key: RTC-6
  • Legacy Issue Number: 10482
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RTC lifecycle state machine

  • Key: RTC-3
  • Legacy Issue Number: 10478
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent definition of ComponentAction callbacks

  • Key: RTC-13
  • Legacy Issue Number: 10491
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent definition of LifeCycle::reset

  • Key: RTC-12
  • Legacy Issue Number: 10490
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector End omitted from diagram

  • Key: RTC-11
  • Legacy Issue Number: 10489
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence diagrams for Introspection should be added

  • Key: RTC-10
  • Legacy Issue Number: 10488
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    Add diagrams as described below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introspection interfaces diagram

  • Key: RTC-9
  • Legacy Issue Number: 10487
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stimulus response and modes of operation sequence diagrams should be added

  • Key: RTC-8
  • Legacy Issue Number: 10486
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    Add diagrams as described below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence diagrams for Data Flow Types should be added

  • Key: RTC-5
  • Legacy Issue Number: 10481
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence diagrams for activation/deactivation should be added

  • Key: RTC-4
  • Legacy Issue Number: 10479
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    Add the non-normative example diagrams as described below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA IDL definition of Port::connect

  • Key: RTC-19
  • Legacy Issue Number: 10497
  • Status: closed  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutionContextAdmin should receive RTObject not ComponentProfile

  • Key: RTC-18
  • Legacy Issue Number: 10496
  • Status: closed  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify contract between execution context and non-initialized components

  • Key: RTC-15
  • Legacy Issue Number: 10493
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component can't reset another component

  • Key: RTC-14
  • Legacy Issue Number: 10492
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA IDL's syntax error

  • Key: RTC-24
  • Legacy Issue Number: 10559
  • Status: closed  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    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.: }

    ;

  • Reported: RTC 1.0b1 — Fri, 22 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical Errors

  • Key: RTC-23
  • Legacy Issue Number: 10535
  • Status: closed  
  • Source: Hitachi ( Saku Egawa)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    See the corrections noted below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagrams do not agree with text

  • Key: RTC-28
  • Legacy Issue Number: 11111
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

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

  • Reported: RTC 1.0b1 — Mon, 2 Jul 2007 04:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ComponentAction callbacks argument

  • Key: RTC-17
  • Legacy Issue Number: 10495
  • Status: closed  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update references to newest versions

  • Key: RTC-16
  • Legacy Issue Number: 10494
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type Mode is not clearly defined

  • Key: RTC-22
  • Legacy Issue Number: 10534
  • Status: closed  
  • Source: Hitachi ( Saku Egawa)
  • Summary:

    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

  • Reported: RTC 1.0b1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of Connector in PSM is unclear

  • Key: RTC-21
  • Legacy Issue Number: 10533
  • Status: closed  
  • Source: Hitachi ( Saku Egawa)
  • Summary:

    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).
  • Reported: RTC 1.0b1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

It seems better to merge LifeCycle with LightweightRTObject

  • Key: RTC-20
  • Legacy Issue Number: 10532
  • Status: closed  
  • Source: Hitachi ( Saku Egawa)
  • Summary:

    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.

  • Reported: RTC 1.0b1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

refactoring of the ExecutionContext model element

  • Key: RTC-25
  • Legacy Issue Number: 10601
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

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

  • Reported: RTC 1.0b1 — Mon, 22 Jan 2007 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

FINALIZED in LifeCycleState

  • Key: RTC-27
  • Legacy Issue Number: 11110
  • Status: closed  
  • Source: Shibaura Institute of Technology ( Mr. Takeshi Sakamoto)
  • Summary:

    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.

  • Reported: RTC 1.0b1 — Mon, 2 Jul 2007 04:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    Remove the FINALIZED in LifeCycleState.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 5, 11

  • Key: RTC-26
  • Legacy Issue Number: 11005
  • Status: closed  
  • Source: ( Fred Waskiewicz)
  • Summary:

    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[

  • Reported: RTC 1.0b1 — Mon, 14 May 2007 04:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lightweight RTC package diagram

  • Key: RTC-2
  • Legacy Issue Number: 10477
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: RTC 1.0b1 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — RTC 1.0
  • Disposition Summary:

    Add diagrams as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT