Introduction

The Signal Router is a hopit Edge service designed to connect Targets and manage all read and write operations. It reads signals from one or more Sources and writes them to one or more Destinations, allowing flexible and rule-based data routing for multiple Signal Routes simultaneously.

The following graph shows the signal flow of an exemplary signal route with all modules enabled in the pipeline. The route reads from two source targets and ingests the data into the Python Compute Module. Next, the signals can be mapped (e.g. from an OPC UA node id to a human readable name). The Condition allows to only continue in the data pipeline if a specific condition is fulfilled (e.g. greater than a constant). Next, the Trigger module only triggers the send Operation either periodically or on change.

Router and the Processing Pipeline

Each Signal Route defines a pipeline from one or more sources to one or more destinations. The flow can include the following stages:

Stage	Description
Compute (optional)	Executes user-defined computations on incoming signals using embedded Python scripts. These scripts can be dynamically edited and applied per route.
Map (optional)	Maps incoming signal identifiers (e.g., OPC UA node IDs, ADS names) to logical names (e.g. signal harmonization, human readable names).
Condition (optional)	Evaluates logical expressions against the latest signal values or constants (e.g., greater than, less than, equal, greater than or equal, less than or equal ). Signals are only further proceed if the condition is satisfied.
Trigger	Determines when signals should be processed. You can configure it to trigger: • Periodic – based on a user-defined scape interval • On Change – the changed signal is further processed • On Change Full – all signals are processed if one signal changes
Operation (optional)	Defines the send operation, including how the processed signal should be formatted using an AsyncAPI schema

The read time is synchronized between all routes. Therefore, all routes with the same scrape interval, defined in the trigger, are always read at the same time. On connection losses, the Router buffers the signals. The amount of saved signals can be controlled with the BufferSize parameter for each Target.

Routes can be added by clicking the "Add Route" button.

The following screenshot shows the user interface of hopit for a single route. Each route must have a unique name and can be enabled or disabled. The source targets are shown on the left whereas destination targets are shown on the right side. Additional Targets can be added by clicking the respective button. Each route can be duplicated or deleted. The "Compute" button opens the Python code editor for this route.

Sources

Source Targets define data sources for each route. The configurator allows for configuring the source signals for each target (e.g. node id for a OPC UA target). Further, a Condition consists of a Signal name and a Value. The Router will forward the Signals of this Source only, if the Signal equals this Value.

Destinations

Each destination primarily contains the destination target with the respective scrape trigger and the scrape interval. The scrape interval defines the cyclic polling interval. Further, the scrape trigger allows to configure if the data is either sent periodic with the cyclic polling interval to the destination target or only on change. If the the trigger is set to publish the data on change, the scrape interval for polling the source target still applies but the data is only published if a signal changes. It can be configured to either send all signals if at least one signal changed ("On Change Full") or only the respective changed signal ("On Change").

Destinations have the parameters:

• Target Name: The name of the Target to write the signals.
• Scrape Interval: The interval to trigger the Sources to read the Signals.
• Scrape Trigger:
  • Periodic: Signals are sent periodically.
  • On Change: Only the Signals, which changed while the previous cycle are sent.
  • On Change Full: All Signals are sent, if at least one Signal changes.
• Constants: Name/Value pairs to add to each sent message.
• Persistent Buffer: Stores the buffered messages not in the RAM, but on the hard disk in order to restore them after a power outage.
• Conditions: Condition, which must be fulfilled in order to send the message. [[LAST_VALUE]] can be used as a comparative value for the value from the previous cycle. The following relational operators are available:
  • Less
  • Greater
  • LessOrEqual
  • GreaterOrEqual
  • Equal
  • NotEqual
• Properties:
  • For Azure Targets: Name/Value pairs added as Properties in the Azure message.
  • For MQTT, Magenta and ThingsBoard Targets: A topic property defines the MQTT topic to publish the Signals. Default topic is /telemetry.
• Signal Map: Name/Value pairs to replace signal names before sending it to the destination Target.
• Operation: Defines the send operation according to the AsyncAPI standard.

Need more help configuring routes or scripting your compute logic? Check out:

• Target Configuration
• Writing Python Scripts for Compute
• Setting up AsyncAPI Output Operations