Signal Registry Service Plugin

Table of Contents

• Signal Registry Service
  • Signal Registry Service Concept
  • Listening on Signals
  • Providing Signals

Signal Registry Service

Introduction

The Signal Registry Service provides a distributed publisher-subscriber model for floating-point signals.

Plugin Information

Plugin Filename	adtf_signal_registry.adtfplugin
Plugin Description	adtf_signal_registry.plugindescription
Plugin Name	Signal Registry Service Plugin
License	ADTF
Support Mail	support@digitalwerk.net
Homepage URL	support.digitalwerk.net

Plugin Versions

Plugin Version	3.99.99
Plugin File Version	1.0
adtf	3.99.99
adtf::ucom	3.1.0

Component Information

Name	Signal Registry Service
CID	signal_registry.service.adtf.cid
Description	Use this System Service to extend the ADTF System with a distributed publisher-subscriber model for floating-point signals.
Type	Service
Default Runlevel	session

Provided Interfaces

IID
signal_registry.ant.services.adtf.iid
signal_registry.flash.services.adtf.iid
signal_listening.ant.services.adtf.iid
signal_listening.flash.services.adtf.iid

Signal Registry Service Concept

Signal providers (publisher) update their signals through the adtf::services::ant::ISignalRegistry::ISignalProvider interface. Signal listeners (subscriber) implement the interfaces adtf::services::ant::ISignalListening::ISignalsListener and adtf::services::ant::ISignalListening::ISignalListener. Both, publishers and the subscribers register themselves with the Signal Registry Service.

A signal has the attributes described by adtf::services::ant::ISignalRegistry::tSignalAttributes and is associated with a current value (as a tFloat64). The name of the signal has to be unique, otherwise and error occurs at registration.

The example Demo Signal Generator Plugin shows how a signal can be provided via the signal registry (publisher).
The example Demo Signal Listener Plugin shows how provided signals can be listened on (subscriber).

The Signal Registry is a useful service to improve access to signal values. However used incorrectly, it can eventually cause significant performance degradation. To prevent unexpected behaviors, keep in mind the following recommendations:

• Signal providers and signal listeners must not directly affect the user interface.
• Limit the number of signal providers and signal listeners.
• Limit the number of subscribed signals per signal listener.

Warning

Please be aware that you must not use the Signal Registry to transmit data. You cannot rely on an accurately timed notification about incoming new values.

Listening on Signals

To listen on signals these steps are necessary:

• Create a class implementing the following interfaces:
• adtf::services::ant::ISignalListening::ISignalsListener
• adtf::services::ant::ISignalListening::ISignalListener
• Retrieve the interface adtf::services::ant::ISignalListening of the signal registry service (e.g. using UCOM).
• Register your created class with that interface using the method RegisterSignalsListener, to be informed about new or removed signals.
• Register your created class with that interface using the method RequestSignalUpdates, to be informed about signal updates.

When you are informed about a new or removed signal the ID of the relevant signal is passed as an argument. You have to use that ID when registering for signal updates.

Providing Signals

To provide one or more signals via the signal registry one has to follow these steps:

• Retrieve the interface adtf::services::ant::ISignalRegistry of the signal registry service (e.g. using UCOM).
• Create a new provider instance using the method CreateProvider of signal registry.
• Add a signal to the just created provider using the method AddSignal of signal registry.
• Depending whether you want to be informed about changes in the subscription state (see next paragraph), you provide the optional argument pEnableCallbackpEnableCallback or not.
• Update this signal whenever you can provide a new value using method UpdateSignal of signal registry.

In Addition you can be informed whenever a signal listener subscribes or unsubscribes to one of your signals. To do so follow these steps:

• Implement the interface adtf::services::ant::ISignalRegistry::ISignalProvider::IEnabledSignals.
• Pass a pointer with the optional argument pEnableCallbackpEnableCallback to that interface when adding your signal with AddSignal (see paragraph before).
• The method EnableSignal of the interface will be called whenever a signal is subscribed.
• The method DisableSignal of the interface will be called whenever a signal is unsubscribed.
• Info: You have to use adtf::services::ant::ISignalRegistry::tSignalID to identify the affected signal.