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

instead of

and

instead of

fix the value ranges for 8-bit integers

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

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.

remove return codes for data reception interfaces

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

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

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

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.

remove class ProgrammingLanguages

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

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.

new specification for task periods

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

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.

remove parameter "methods_to_trace"

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

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

add extension relationship for AnnotationDefinition

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

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

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.

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

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.

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

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.

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.

provide a new XML schema and DTD

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

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.

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.

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.

add lower and upper cardinalities to configuration parameters

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