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

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.