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

value ranges are wrong for 8-bit integers

  • Key: UCM11-19
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The resolution of issue UCM11-2 introduced some typo in section 9.2.3.3.
    The table should contain

    INT8 -2 7 2 7 - 1 int8 (in IDL 4.2)

    instead of

    INT8 -2 8 2 8 - 1 int8 (in IDL 4.2)

    and

    UINT8 0 2 8 - 1 uint8 (in IDL 4.2)

    instead of

    UINT8 0 2 8 uint8 (in IDL 4.2)
  • Reported: UCM 1.0 — Mon, 9 Apr 2018 14:18 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    fix the value ranges for 8-bit integers

    The edition must come after UCM11-2.
    Write the correct value ranges: -2 7 .. 2 7 - 1 for int8 and 0 .. 2 8 - 1 for uint8.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

there should be no returned error code for data consumers in the standard library

  • Key: UCM11-18
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Standard library model core.xml contains the following declaration:

    <interface name="message_intf">
    <method name="push">
    <param dir="in" name="message" type="message_type_t"/>
    <param dir="return" name="ecode" type="::core::return_codes::comm_ecode"/>
    </method>
    </interface>
    

    and

    <portType name="msg_emtr_pt">
    <portElement interface="api::message_intf" kind="required" name="emtr_pe"/>
    </portType>
    <portType name="msg_rcvr_pt">
    <portElement interface="api::message_intf" kind="provided" name="rcvr_pe"/>
    </portType>
    

    This indicates that message emitter and message receiver port types rely on the same interface message_intf. This interface has a unique method push with a return type for error codes. The error code makes sense for the emitter, as it let it know wether the communication has been successful or not. But it makes no sense for the receiver: the value of the error code must be set by the connector, not the receiving component.

    There is a similar problem with the request-reponse connector.

  • Reported: UCM 1.0 — Mon, 9 Apr 2018 13:58 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    remove return codes for data reception interfaces

    create separate interfaces for data emitter and data receiver for message and request-response interactions

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

names of standard library files should be consistent with module names

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

    The UCM standard defines a set of standard libraries stored in 5 files (core.xml, execution.xml, interactions.xml, properties.xml and timer.xml). Inside these files, the names of the top level modules do not always match the file names (core, ext_comp_exec, interactions, std_ann, timer).
    Although the standard does not states that UCM files should be named after the module they contain, it would make more sense to do so.

    In addition, module names should be less generic, as UCM is designed to encourage the use of additional libraries.

    Hence the standard library files may be renamed as follows:

    • ucm_core.xml
    • ucm_ext_exec.xml
    • ucm_ext_interac.xml
    • ucm_std_ann.xml
    • ucm_timer.xml
  • Reported: UCM 1.0 — Mon, 9 Apr 2018 12:29 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    update library and example declarations

    Rename the modules of the standard library models:

    • core becomes ucm_core
    • ext_comp_exec becomes ucm_ext_exec
    • interactions becomes ucm_ext_interac
    • std_ann becomes ucm_std_ann
    • timer becomes ucm_timer

    Also add a new subsection to describe the standard port roles, introduced by UCM 1.1

    Update XML and IDL code blocks to match the new module names of the standard library models

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

improve the specification of task periods

  • Key: UCM11-15
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Configuration of component execution policies relies on type ucm_timeval_t, which is a structure with two fields: seconds and nanoseconds. It is thus not convenient to specify task periods in milliseconds: too many zeroes to write, which may lead to mistakes. It should be nice to have a more adequate data structure.

  • Reported: UCM 1.0 — Tue, 27 Mar 2018 15:56 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    new specification for task periods

    The new definitions are provided in the attached file ucm_ext_exec.xml

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

remove parameter "methods_to_trace" from port_trace technical policy

  • Key: UCM11-14
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Technical policy port_trace has a parameter named methods_to_trace to indicate which method calls should be logged. It is not very convenient to use, as it leads to list all method names in a single string. It would be better to simply remove it and have port_trace log the invocations of all port methods.

  • Reported: UCM 1.0 — Tue, 27 Mar 2018 15:32 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    remove parameter "methods_to_trace"

    Simply removed the parameter declaration from the XML and IDL codes. Also remove the associated data types.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

allow extension relationship between Annotation Definitions

  • Key: UCM11-7
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Subclasses of IConfigurable (ConnectorDefinition, TechnicalPolicyDefinition, etc.) have an extension relationship. This should be applied to AnnotationDefinition too, to bring the same level of flexibility.

  • Reported: UCM 1.0b2 — Mon, 13 Nov 2017 10:29 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    add extension relationship for AnnotationDefinition

    Most UCM entities have an extension relationship. By adding it to AnnotationDefinition we ensure consistency.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

Improve component port declaration

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

    Component ports in UCM are specified by 3 parameters:

    • a name
    • a définition
    • bindings to actual types if need be

    UCM defines a set of nested classes in the meta-model, which makes the XML syntax verbose. See for example:

    <compType name="Compare">
      <port name="in1">
        <typeSpec type="::core::messages::msg_rcvr_pt">
          <binding abstract="::core::messages::api::message_type_t" actual="::complex_types::image_t"/>
        </typeSpec>
      </port>
      <port name="in2">
        <typeSpec type="::core::messages::msg_rcvr_pt">
          <binding abstract="::core::messages::api::message_type_t" actual="::complex_types::image_t"/>
        </typeSpec>
      </port>
    </compType>
    

    Three nested XML tags are necessary: port, typeSpec and binding.

    The specification of data binding is nested in the port declaration. Although it is a clean way to specify bindings, it brings two issues:

    • users have to write the binding specification for each port; a binding cannot be written once and used for several ports, which would be simpler
    • it is difficult to implement efficient code generators: a naive generator will generate specific code for each port instead of for each unique binding; this leads to redundant code.

    It would be better to write something like this:

    <bindingSet name="binding1">
      <binding abstract="::core::messages::api::message_type_t" actual="::complex_types::image_t"/>
    </bindingSet>
    
    <compType name="Compare">
      <port name="in1" def="::core::messages::msg_rcvr_pt" binding="binding1"/>
      <port name="in2" def="::core::messages::msg_rcvr_pt" binding="binding1"/></compType>
    

    Also, when refining a component type, ports can be refined. By “refined”, one must understand “redefined”: UCM actually allows a complete port redefinition; no shared data or semantics is required between the original port and its refinement.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 13:53 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    Improve component port declaration

    introduce the notion of PortRole to restrict component port refinement: a component port can only be refined by a component port the port type of which references the same port role. For example, a message emitter port can refine a data producer port, but not a service client port.
    Also remove the notion of IPortSpec, PortTypeSpec and PortRoleSpec, and instead have a reference to the port type and binding in the port declaration.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

Create a DTD for the XML syntax

  • Key: UCM11-6
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    UCM 1.0 defines an XML schema, which is sufficient to validate file structures.
    However, XML provides a nice feature: entities. Entities allow automatic string substitution. Some of them are standard. For example: &nbsp;, &quot;, &gt;

    As UCM relies on absolute names to reference elements, XML files can become verbose:

      <policyDef applicability="on_component_only" aspect="::core::comp_exec::comp_trig_asp" extends="::core::comp_exec::self_exec_comp" name="prdc_self_exec_comp">
        <configParam name="psec_period" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
        <configParam name="psec_priority" type="contracts::priority_t"/>
        <configParam name="psec_offset" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
      </policyDef>
    

    It would be nice to be able to write instead:

      <policyDef applicability="on_component_only" aspect="&ce;::comp_trig_asp" extends="&ce;::self_exec_comp" name="prdc_self_exec_comp">
        <configParam name="psec_period" type="&ucm_timeval_t;"/>
        <configParam name="psec_priority" type="contracts::priority_t"/>
        <configParam name="psec_offset" type="&ucm_timeval_t;"/>
      </policyDef>
    

    XML entities require the specification of a DTD.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 15:39 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    provide a new XML schema and DTD

    replace ptc/17-05-07 with ucm_base.dtd and ucm_base.xsd

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

Add cardinalities (i.e. min and max) for configuration parameters

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

    It is impossible to declare optional configuration parameters or to specify that a configuration parameter can accept several values. See for example the following declaration of the standard technical policy for periodic component execution:

    <policyDef applicability="on_component_only" aspect="::core::comp_exec::comp_trig_asp" extends="::core::comp_exec::self_exec_comp" name="prdc_self_exec_comp">
      <comment>periodic self-executing component. It will invoke method run every period.</comment>
      <configParam name="psec_period" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
      <configParam name="psec_priority" type="contracts::priority_t"/>
      <configParam name="psec_offset" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
    </policyDef>
    

    It has 3 mandatory parameters:

    • period
    • offset
    • priority

    While the period is obviously mandatory, the offset information might be optional. It would be nice to be able to specify that offset is not mandatory (min="0"):

    <policyDef applicability="on_component_only" aspect="::core::comp_exec::comp_trig_asp" extends="::core::comp_exec::self_exec_comp" name="prdc_self_exec_comp2">
      <configParam name="psec_period" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
      <configParam name="psec_priority" type="contracts::priority_t"/>
      <configParam min="0" name="psec_offset" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
    </policyDef>
    

    Also, one could imagine some kind of complex policy with several different execution periods in order to create a complex execution pattern.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 12:33 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    add lower and upper cardinalities to configuration parameters

    Add fields “lower” and “upper” to configuration parameters, just like UML does for properties.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

Bring more flexibility in composite component extensions

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

    Composite component implementations can extend other composite implementations. Parts and connections can be refined, with some limitations to guarantee consistency:

    • refined parts must be of the same component type
    • refined connections must be of the same connector definition or an extended connector definition

    This is actually too restrictive. The following should be allowed:

    • refined parts should be of the same component type OR a component type that refines the initial component type
    • refined connections should simply be consistent with the connected ports
  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 10:14 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    bring more flexibility in composite component extensions

    In component types, restrict port refinements: instead of allowing any refinement, refining ports must now reference the same port role.
    In composite component implementations, allow a part to reference any refinement of the component referenced by the inherited part, instead of restricting to the same component type. Also, allow connection refinement to reference any connector definition as long as it gives a consistent architecture.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

Add support for 8-bit integers

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

    IDL42-6 recently introduced support for 8-bit integers in IDL. UCM should follow this enhancement and support 8-bit integers.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 09:55 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    Add support for 8-bit integers

    add literals INT8 and UINT8 in enumeration PrimitiveIntegerKind, and replace literals SHORT, LONG, etc. by INT16, INT32, INT64, UINT16, UINT32 and UINT64 for consistency.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

remove class ProgrammingLanguages from the meta-model, as it is useless

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

    Class ProgrammingLanguages had been created to gather programming language declarations and avoid having them scattered in NonfunctionalAspectModule. In the actuality, it creates unnecessary complexity when creating tools without bringing real advantage. It is better to simply remove it and have its contents (class Language) directly linked with class NonfunctionalAspectModule, as illustrated in the attached diagram.

  • Reported: UCM 1.0b2 — Mon, 9 Oct 2017 15:37 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    remove class ProgrammingLanguages

    The change consists of having programming language declarations directly in Nonfunctional modules, instead of nesting them in the intermediate class ProgrammingLanguages.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

Connectable interfaces does not support more that one portelement per port-type

  • Key: UCM11-16
  • Status: closed  
  • Source: MBDA Italia ( marco di ferrante)
  • Summary:

    Port-type can have 1..* PortElements, as clearly shown in Figure 9.22.
    So a component can provide and require a set of PortElementObjects as instances of couple PortName/PortElementName and this is correctly mapped in the component Port Mapping getter for provided portelement “get_<port_name>_<provided_port_element_name>".

    When looking for REQUIRED port elements and the interface to connect them to the related provided port element object, this Port/PortElement coupling seems lost.

    Infact:

    • ComponentObject::get_portElement (in string provided)
    • Connectable::on_connect (in string port_name, in PortElementObject required);
    • Connectable::on_disconnect (in string port_name);
    • Container::get_port_element (in componentId comp_instance, in string port_name)
    • Container::connect (in componentId instance, in string port_name, in PortElementObject to_port)
      support only one PortElementObject for Port.

    If the understanding of the UCM is correct they should be updated as

    • ComponentObject::get_portElement (in string port_name, in string port_element_name);
    • Connectable::on_connect (in string port_name, in string port_element_name, in PortElementObject required);
    • Connectable::on_disconnect (in string port_name, in string port_element_name);
    • Container::get_port_element (in componentId comp_instance, in string port_name, in string port_element_name);
    • Container::connect (in componentId instance, in string port_name, in string port_element_name, in PortElementObject to_port);
  • Reported: UCM 1.0 — Mon, 19 Feb 2018 14:09 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    update the programming model to explicitly manipulate port elements

    In the programming model APIs, replace parameter “port_name” by two parameters “port_or_policy” and “port_elem”.

    Document ptc/17-05-05 shall be replaced by file ucm.idl.

  • Updated: Wed, 3 Oct 2018 14:18 GMT