Unified Component Model for Distributed, Real-Time and Embedded Systems Avatar
  1. OMG Specification

Unified Component Model for Distributed, Real-Time and Embedded Systems — Closed Issues

  • Acronym: UCM
  • Issues Count: 13
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Introduce structured configuration parameters

  • Key: UCM13-16
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    It is currently not possible to gather several configuration parameters together.

    For example, let us suppose we want to design a message connector that handles channels with different FIFO priorities.
    Such a connector would allow the specification of a channel number for each emission port.
    It would also allow the specification of a FIFO priority for each channel number in each reception port.

    See the following example of what would be needed:

    <interactionModule name="enhanced_fifo_connector">
      <contractModule name="data_types">
        <integer kind="int32" name="channel_id_t"/>
        <integer kind="uint8" name="fifo_priority_t"/>
      </contractModule>
      <connectorDef name="enh_fifo_msg_cnt" pattern="::ucm_core::messages::msg_intr_pat">
        <extends ref="::ucm_core::messages::simple_msg_cnt"/>
        <portConf port="emitter">
          <configParam max="1" min="1" name="channel_id" type="data_types::channel_id_t"/>
        </portConf>
        <portConf port="receiver">
          <structParam max="-1" min="0" name="fifo_priorities">
            <comment>the default fifo priority is 0</comment>
            <configParam max="-1" min="1" name="emitter_channel_id" type="data_types::channel_id_t"/>
            <configParam max="1" min="1" name="fifo_priority" type="data_types::fifo_priority_t"/>
          </structParam>
        </portConf>
      </connectorDef>
    </interactionModule>
    

    Sets made of several channels and one priority can be specified for each port “receiver”.

    Such a connector could be used as follows:

    <componentModule name="components">
      <contractModule name="contracts">
        <integer kind="int16" name="payload_t"/>
      </contractModule>
      
      <bindingSet name="payload_binding">
        <binding abstract="::ucm_core::messages::api::transm_data_t" actual="contracts::payload_t"/>
      </bindingSet>
      
      <compType name="C_sender">
        <port bindings="payload_binding" name="snd" type="::ucm_core::messages::msg_emtr_pt"/>
      </compType>
      
      <compType name="C_receiver">
        <port bindings="payload_binding" name="rcv" type="::ucm_core::messages::msg_rcvr_pt"/>
      </compType>
      
      <compType name="C_appli">
      </compType>
      
      <atomic lang="::ucm_lang::cpp::CPP11_typed" name="CI_sender" type="C_sender"/>
      <atomic lang="::ucm_lang::cpp::CPP11_typed" name="CI_receiver" type="C_receiver"/>
      
      <composite name="appli" type="C_appli">
        <part name="c1" ref="CI_sender"/>
        <part name="c2" ref="CI_sender"/>
        <part name="c3" ref="CI_sender"/>
        <part name="c4" ref="CI_receiver"/>
        <part name="c5" ref="CI_receiver"/>
        <connection name="cnx1" ref="::enhanced_fifo_connector::enh_fifo_msg_cnt">
          <end name="c1_snd" part="c1" port="snd">
            <config def="channel_id" value="1"/>
          </end>
          <end name="c2_snd" part="c2" port="snd">
            <config def="channel_id" value="2"/>
          </end>
          <end name="c3_snd" part="c3" port="snd">
            <config def="channel_id" value="3"/>
          </end>
          <end name="c4_rcv" part="c4" port="rcv">
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="1"/>
              <config def="fifo_priority" value="2"/>
            </structConfig>
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="2"/>
              <config def="emitter_channel_id" value="3"/>
              <config def="fifo_priority" value="9"/>
            </structConfig>
          </end>
          <end name="c5_rcv" part="c5" port="rcv">
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="1"/>
              <config def="fifo_priority" value="5"/>
            </structConfig>
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="2"/>
              <config def="fifo_priority" value="2"/>
            </structConfig>
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="3"/>
              <config def="fifo_priority" value="1"/>
            </structConfig>
          </end>
        </connection>
      </appAssembly>
    </componentModule>
    

    Composite component 'C_appli' contains 5 subcomponents: c1, c2 and c3 send messages to c4 and c5.
    Subcomponent c1 sends on channel 1, c2 sends on channel 2, c3 sends on channel 3.

    Subcomponents c4 and c5 receive all messages, with different priorities.
    Thus, c4 receives data from c1 (channel 1) with priority 2, data from c2 and c3 (channels 2 and 3) with priority 9.
    And c5 receives data from c1 (channel 1) with priority 5, data from c2 (channel 2) with priority 2, data from c3 (channels 3) with priority 1.

  • Reported: UCM 1.2 — Thu, 15 Oct 2020 13:16 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    create structured configuration parameters

    Add two new concepts in the meta-model: StructuredConfigurationParameter and StructuredConfigurationParameterValue.
    Update the XML schema and DTD accordingly.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Unexpected mention of “monolithic” component implementation

  • Key: UCM13-17
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In section 14.1.2.2 (From technical policies to fragments), diagram 35 shows a “monolithic” component implementation. Monolithic component implementations are mentionned nowhere else in the document; this “monolithic” component is should be renamed “atomic” instead.

  • Reported: UCM 1.2 — Thu, 15 Oct 2020 13:39 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    rename “monolithic” into “atomic”

    In the early stages of the UCM standard, atomic component implementation were called monolithic. Update diagram 35 to use word “atomic”.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

problems in the XML schema and the DTD

  • Key: UCM13-5
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In the DTD, tag "comment" is missing in the declaration of element componentModule, line 283.

    In the XML schema, elements "componentModule" and "contractModule" are inverted with respect to the DTD, lines 672 and 673.

  • Reported: UCM 1.2b1 — Tue, 3 Mar 2020 13:49 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Fix the problems in the DTD and the XML schema

    Fix the problems

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

List XML tags names and clarify the rules for name references

  • Key: UCM13-23
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Although the XML syntax of UCM is specified by a DTD and an XML schema, it would be nice to have at least a list of the XML tags in the main document, to help read the DTD and the schema.
    Also, the way of referencing entities is not completely clear for relative names.

  • Reported: UCM 1.2 — Tue, 2 Mar 2021 17:31 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    List XML tags names and clarify the rules for name references

    List the main tag names of the XML syntax. Clarify relative name references.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

broken link in the document

  • Key: UCM13-13
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The content of section 17.4 “Components” is “The examples of this section correspond to the example illustrated in sectionError: Reference source not found”.
    This is obviously a broken link.

    The link should be updated to point to section 11.3 “Example”.

  • Reported: UCM 1.2 — Tue, 29 Sep 2020 11:57 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    fix the broken link

    Update the link to section 11.3 (Example)

  • Updated: Mon, 4 Oct 2021 17:10 GMT

Rephrase some explanations

  • Key: UCM13-21
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    There are some inconsistencies in the first sections of the document.
    For example, section 1.4 is entitled “Programming model” while section 14 is entitled “UCM container model”.
    Also, section 9.1.2 mentions “properties”, which do not seem to be defined in the rest of the document.

  • Reported: UCM 1.2 — Tue, 9 Feb 2021 17:54 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Rephrase some explanations

    Some terms (e.g. “properties” or “programming model”) had been used in the early stages of the standard, but are have not been used in the final version of the document. Replace these obsolete terms with the correct ones.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

define port types for “pull-pull” interactions

  • Key: UCM13-11
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM core library defines the message connector in which the data producer pushes data to the connector, and the connector pushes data to the consumer. This more or less corresponds to the event interactions of CCM.

    Yet, in some situations, pulling data from the producer is a good architectural choice. For example, if we want to ensure a piece of data is sent periodically, it is best to let the connector manage this, instead of the component: even if there are bugs in the component business code, that connector shall periodically fetch the data.

    It might be difficult to standardize a “pull-pull” connector because there could be many different situations: periodic fetching, fetching upon request from the consumer, etc. The UCM standard should simply define port types in order to have standard APIs.

  • Reported: UCM 1.2 — Wed, 23 Sep 2020 16:54 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    define a data pull connector

    Define a data pull connector in the extended interactions. This connector involves one supplier and one or more consumers. Whenever a consumer pulls a piece of data, the piece of data is fetched from the supplier.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Add a method in the comp_trace policy to log messages with a default severity

  • Key: UCM13-4
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The invocation of the standard technical policy for traces consists of a method
    log that takes two parameters:

    • the severity (trace, debug, warning, etc.)
    • the log message (a wide character string)

    It can be tedious to always have to specify the severity. There should be an
    additional log method with a default severity.

  • Reported: UCM 1.2 — Tue, 7 Jan 2020 17:13 GMT
  • Disposition: Closed; No Change — UCM 1.3
  • Disposition Summary:

    Do not change the comp_trace policy

    No commonly used logging API (e.g. log4cpp) supports a default severity level. Therefore, such a mechanism does not correspond to current pratice, and may be difficult to understand.

    Platform providers that really want to deal with a default severity loggin level can define their own, non standard, technical policy.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

Allow specific configuration for the ports and policies managed by a given technical policy

  • Key: UCM13-3
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Technical policies can have configuration parameters, and can manage component
    features (i.e. they can intercept them). However, it is not possible to
    associate a specific configuration with a given component feature.

    Current state

    Technical policy definitions can specify configuration parameters. In the
    following example, technical policy definition watchdog specifies a
    configuration parameter for the timeout. It also declares an interface named
    watchdog_intf that must be provided by components. The policy calls method
    timeout if no activity has been detected on the intercepted component
    features for some time.

    <policyModule name="example">
     <contractModule name="api">
       <interface name="watchdog_intf">
        <method name="timeout"/>
       </interface>
     </contractModule>
    
     <technicalAspect constraint="any_number" name="asp"/>
    
     <policyDef applicability="on_some_ports" aspect="asp" name="watchdog">
      <comment>This policy intercepts some component ports and policies. It invokes method timeout if no activity is detected on one of these ports and policies after max_delay.  </comment>
      <portElement interface="api::watchdog_intf" kind="provided" name="wdg"/>
      <configParam name="max_delay" type="::ucm_ext_exec::contracts::ucm_duration_t"/>
     </policyDef>
    </policyModule>
    

    One can set the value max_delay when declaring such a policy. In the
    following, we declare an atomic component named calculation_impl that has
    two input ports input1 and input2. It is associated with technical
    policy watcher that monitors both ports. Policy watcher triggers an
    alert after 2 seconds of inactivity on both ports.

    <componentModule name="comp">
     <contractModule name="data_types">
      <integer name="int32_t" kind="int32"/> 
     </contractModule>
    
     <bindingSet name="bindings">
      <binding abstract="::ucm_core::messages::api::transm_data_t" actual="data_types::int32_t"/>
     </bindingSet>
    
     <compType name="calculation">
      <port name="input1" type="::ucm_core::message::msg_recv_pt" bindings="bindings"/>
      <port name="input2" type="::ucm_core::message::msg_recv_pt" bindings="bindings"/>
     </compType>
    
     <policy name="watcher" def="::example::watchdog">
      <componentRef ref="calculation_impl"/>
      <managedPort ref="input1"/>
      <managedPort ref="input2"/>
      <configValue name="max_delay" value="{2, s}"/>
     </policy>
    
     <atomic name="calculation_impl" lang="::ucm_lang::cpp::cpp11_typed">
      <policyRef ref="watcher"/>
     </atomic>
    </componentModule>
    

    Limitation

    The problem is, it is impossible to set a specific timeout value for each
    intercepted port. Thus, one cannot specify that policy watcher shall
    trigger an alert after 2 seconds of inactivity on port input1, or 3 seconds
    of inactivity on port input2.

    Having two separate policies (one for each intercepted port) is not convenient
    because the component business code would then have to implement two different
    methods timeout (one for each policy).

    What should be added

    Technical policy definition should be extended to declare configuration
    parameters that apply to particular managed component features. Thus, the
    declaration of watchdog may be something like this:

    <policyDef applicability="on_some_ports" aspect="asp" name="watchdog">
     <comment>This policy intercepts some component ports and policies. It invokes method timeout if no activity is detected on one of these ports and policies after max_delay.  </comment>
     <portElement interface="api::watchdog_intf" kind="provided" name="wdg"/>
     <configParam name="default_max_delay" type="::ucm_ext_exec::contracts::ucm_duration_t"/>
     <specificConf name="specific_delays">
      <configParam name="max_delay" type="::ucm_ext_exec::contracts::ucm_duration_t"/>
     </specificConf>
    </policyDef>
    

    An additional section named featureConf allows the declaration of per-feature configuration parameters.

    Technical policy watcher may then be declared as follows:

    <policy name="watcher" def="::example::watchdog">
     <componentRef ref="calculation_impl"/>
     <managedPort ref="input1"/>
     <managedPort ref="input2"/>
     <configValue name="default_max_delay" value="{2, s}"/>
     <featureConf name="input2_config">
      <managedPort ref="input2"/>
      <configValue name="max_delay" value="{3, s}"/>
     </featureConf>
    </policy>
    

    Here, the policy triggers an alert after 2 seconds of inactivity on input1
    (default policy configuration) or after 3 seconds of inactivity on input2
    (specific configuration).

  • Reported: UCM 1.2 — Tue, 7 Jan 2020 15:17 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Allow the specification of configuration parameters that are associated to particular ports or policies

    Create two new meta-classes:

    • SpecificPolicyParameter enables the declaration of configuration parameters that may be associated to some managed ports or policies
    • SpecificPolicyConfigurationValue actually associates configuration parameter values to managed ports or policies

    Provide an example for a better understanding.

    Update the XML schema and DTD with the new syntactic elements.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Attribute values of parts cannot be set in composite component implementation, while configuration parameter values of connections can

  • Key: UCM13-2
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In CompositeComponentImplementation, the ucm_base meta-model allows the specification of configuration parameter values in Connection and ConnectionEnd, but it does not allow the specification of attribute values in AssemblyPart. The meta-model would be more consistent if it supported the specification of attribute values in AssemblyPart.
    For example, if we have the following component declaration:

    <componentModule name="comp">
      <compType name="C1">
        <attribute mode="read" name="attr1" type="::dataTypes::Int32_t"/>
      </compType>
    
      <atomic name="C1_i1" lang="::ucm_lang::cpp::CPP11_typed" type="C1"/>
    </componentModule>
    

    We should be able to write something like this:

    <componentModule name="comp2">
      <compType name="C2"/>
    
      <composite name="C2_i1" type="C2">
        <part name="c1a" ref="::comp::C1_i1">
          <attrVal ref="attr1" value="23"/>
        </part>
        <part name="c1b" ref="::comp::C1_i1">
          <attrVal ref="attr1" value="12"/>
        </part>
      </composite>
    </componentModule>
    

    Attribute attr1 shall be initialized to 23 for part c1a and to 12 for c1b.

  • Reported: UCM 1.2 — Thu, 5 Dec 2019 12:26 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Set attribute values in assembly parts

    Add a new metaclass AttributeValue that allows the specification of a value for an attribute. This metaclass is referenced by metaclass AssemblyPart.

    Also update the DTD and XML schema.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Named entities have no ID in the meta-model

  • Key: UCM13-1
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM DTD and XML schema specify an ID field for each named entity. Yet, such ID do not exist in the INamed metaclass of the ucm_base metamodel. Adding IDs in INamed entities would ease the importation of XML files into existing UCM models by enabling model mergers.

  • Reported: UCM 1.2 — Thu, 5 Dec 2019 10:37 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Add an ID field in class INamed

    add a field “id” to class INamed

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Inconsistency in number of bindings for technical policies

  • Key: UCM13-8
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Field “bindings” of technical policies is specified with cardinality [0…*] in the text, while it is displayed with cardinality [0…1] in diagram 31.

  • Reported: UCM 1.2 — Mon, 7 Sep 2020 10:08 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    change cardinality of field “bindings” of class TechnicalPolicy

    The correct cardinality is [0…1]. Change the text accordingly.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

rename “executor” into “context” in the container model

  • Key: UCM13-10
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM container model specifies that a PortElementObject uses the name “executor” to refer to the ComponentObject it belongs to. The name “context” may be a better choice for this.
    Indeed, the methods of a PortElementObject use the ComponentObject to retrieve the references to the other PortElementObjects of the component. So, the ComponentObject can be seen as a context for the execution of PortElementObject methods.
    Using “context” would make UCM more consistent with CCM.

  • Reported: UCM 1.2 — Wed, 23 Sep 2020 16:34 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    replace “executor” by “context”

    In section 13, replace “executor” by “body” (1 replacement).
    In the rest of the document, replace all occurrences of “executor” by “context” (4 replacements).
    Update two diagrams that describe the UCM container model.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments: