Introduction

This manual describes the CDP Logger component in CDP Studio, the independent automation software for open PC-based real-time distributed control systems.

The CDP Logger is a component for logging values and events. It is designed for long-term storage of high-frequency numeric data. Depending on the selected datastore, data is either stored to a local file or a remote server, see the Choosing a Datastore page for more information. CDP Logger also contains a server for remote access to logged data, see Viewing Data.

Note: The CDP Logger is a licensed feature. See the CDP Runtime License manual for more information.

Usage

To set up a CDP Logger for an application, simply add it as a subcomponent. Next, add a Datastore to the CDP Logger component (e.g. CDPCompactDatastore). To actually log something, add LoggedValue nodes and set the Routing attribute to any signal or property in the system. Alternatively, you may right-click on any signal or property and select Add to Logger...

Example

See the How to Setup Logging in Automation System page for a step-by-step example.

Features

Stale Data Detection

Each LoggedValue can have StaleDataDetection enabled. When the value has not changed for a time configured by the logger component's StaleDataCheckIntervalSec property, an alarm is set. For maximum confidence that the whole logging pipeline is working as intended, the check is performed by reading back the logged data from the datastore.

It is recommended to enable StaleDataDetection for all LoggedValues that are expected to change frequently. In addition, enable it at least for one LoggedValue per application to ensure sibling CDP applications have started correctly and are producing data.

Tagging Data

The CDP Logger supports tagging logged data with metadata such as unit, description, and other custom tags. Tags can be set for each LoggedValue individually by modifying the Tags property of the LoggedValue node. Additionally, the CDP Logger supports TagLookup rules that allow fetching tags from the logged node or its parent nodes. This is useful for automatically tagging logged data with relevant metadata without having to manually set tags for each LoggedValue.

Built-in Server

The CDP Logger contains a built-in server that allows remote access to the logged data, see Viewing Data.

The server listens on a configurable port and can be bound to a specific network interface. The server port can be configured by setting the ServerPort property, and the network interface can be set by modifying the ServerInterface property. If the ServerInterface is left empty, the server will listen on all available network interfaces.

Delta Logging

The CDP Logger supports delta logging, which means that it only logs value changes that are larger than a configured delta value. This is useful for reducing the amount of logged data, especially when logging high-frequency signals that change frequently but only by small amounts. The delta value can be set for each LoggedValue individually by modifying the Delta property of the LoggedValue node. When the delta value is set to 0, all value changes are logged.

Size Alarm

The CDP Logger can set an alarm when the size of the datastore exceeds a configured limit. This is useful for monitoring the growth of logged data and ensuring that the datastore does not become too large. The size limit is set by the SizeAlarmGB property

Advanced Features

Other less frequently used features are described in the Advanced Features section.

Configuration

Here is a list of configuration options specific to this component.

LoggedValue

LoggedValue represents the node (signal or property) that is logged.

Datastore

Datastore is the backend used by CDP Logger, usually some database. The default is CDPCompactDatastore.

For more information about datastores, see the Choosing a Datastore page.

TagLookup

TagLookup defines a tag that should be fetched for each LoggedValue (if available) and for each node that emits a CDP event (when Event Logging is enabled) and saved to the chosen Datastore as metadata for the node. The tag for a LoggedValue is fetched once during startup while for an event sender, it is fetched when it emits the first event.

For example, a TagLookup with SearchType='DirectChild' and Value='Unit' means that for each logged value, if the value has a child named "Unit", it will be saved at startup.

By default, the following tags are fetched for each LoggedValue and each event sender:

• unit - the unit of a logged value (if available).
• description - the description of a logged node (if available).
• metric - a container for related values from a single measurement or device (e.g. "weather_sensor" metric can contain "temperature" and "humidity" values). It is used by some Datastores when creating the schema (for example, the metric could become a table name in a database). By default, it is the Model of the logged node's parent.
• label - the type of the logged data, e.g. "temperature" or "humidity" (it does not have to be unique). It is used by some Datastores when creating the schema (for example, the label can become a column name in a table). By default, it is the short name of the logged node.
• group - the Group property of a CDPAlarm. Useful for filtering logged alarm events.

If the default TagLookup rules are not suitable, they can be disabled by setting the Enabled property to false.

Event Logging

When enabled, the logger will subscribe to CDPAlarm (Set, Clear, Acknowledge) and other CDP events and log them to the selected Datastore.

Signals

Properties

Viewing Data

CDP Logger contains a server for remote access to the logged data that can be used to view data no matter which datastore is used.

There are several options to view logged data through the log server:

• Using CDP Studio Analyze mode Historic Data functionality which will detect a running CDP Logger or LogServer and connect to it. The Analyze mode can also be used to export the logged data to CSV format.
• Making your own GUI application that includes Database Graph Widget.
• Python code can query values from a running CDP Logger or LogServer using the PythonCDPLoggerClient.
• The ValueLogReader and EventLogReader sequencer blocks can be used to extract and process logged data.

The selected Datastore might provide other custom ways to view logged data. See the manual for the selected datastore to get specific information on that.

Advanced Features

Here are some advanced features of the CDP Logger that are not commonly used but can be useful in specific scenarios.

In-Memory Logging

The CDP Logger has limited support for in-memory logging, which means that it can log data to temporary buffers instead of directly to the datastore. This is useful for scenarios where you want to log data only when certain conditions are met, such as when an interesting event occurs.

The in-memory logging can be enabled by setting the InMemoryLogging property to true. When in-memory logging is enabled, the logger starts in the LogToBuf state. The content of the buffer can be written to the datastore sending the LogToOutput message. The buffer span can be configured by setting the BufferSpanMinutes property.

Switching the Front-end Protocol

The CDP Logger supports two front-end protocols: Messenger (the default) and StudioAPI. It is configured by the Protocol property. The front-end protocol determines how the logger retrieves values from the CDP system.

Messenger Protocol

The Messenger protocol is the default protocol used by the CDP Logger. It uses regular CDPProperty routings to retrieve values from the CDP system (through the MessengerIOServer component).

Benefits:

• It is well-established and widely used in the CDP ecosystem.
• It supports all CDPProperty-based nodes, including signals, arguments, parameters and properties - it can log any value that can be routed in a CDP system.
• It is suitable for most use cases where periodic logging of values is sufficient.
• Excellent performance when logging values from the same application where the logger is as local values are retrieved directly from the CDPProperty nodes without going through the network.
• Logging local values continues to work even when the network interface is down.
• For nodes where the Value property has RouteType=Periodic (e.g. all CDPSignals, CDPSignalChannels and Arguments), the values are published at a fixed frequency even when not changed, making the protocol highly resilient to packet loss and temporary network issues.

Limitations and drawbacks:

• It only retrieves values from nodes that are either CDPProperties or have a child CDPProperty called Value, which means it cannot log some values seen in CDP Studio (e.g., CDPSettings).
• Periodic properties publish their values at a fixed frequency (whether changed or not), which may cause excessive network traffic when logging signals from high-frequency components residing in a remote application.
• Only periodic logging is supported (configured by the PeriodicLogFrequency property). There is no option to log every value change as it happens.
• Timestamps of logged values are assigned by the logger when the value is received, which may not match the exact time when the value was produced by the source application.
• For remote applications, the CPU load is usually similar to the StudioAPI protocol, although the latter can have an advantage in case of many rarely changing values.

StudioAPI Protocol

With the StudioAPI protocol, the logger retrieves values through the StudioAPIServer - the same way as CDP Studio.

Benefits:

• It allows logging every value seen from CDP Studio, including CDPSettings and other non-CDPProperty nodes.
• It supports logging every value change as it happens instead of periodically checking for changes. To enable this, set the PeriodicLogFrequency property to 0.
• The protocol provides a timestamp for each value change, which is the exact time when the value was produced by the source application, not when it was received by the logger. Note, this is only used when sampling is disabled by setting the PeriodicLogFrequency property to 0.
• Reduced network traffic because it only sends changed values and for high-frequency values, multiple changes are sent in a single packet (with exact timestamps of each change).

Limitations and drawbacks:

• The protocol is more advanced and complex, which often causes a higher CPU load.
• Even logging local values requires a network connection to the StudioAPIServer, which causes some performance overhead and also means that logging local values does not work when the network interface used by StudioAPIServer is down.

Internal Properties

When disabling the Hide Internal Items filter, some additional properties become visible. It is normally not necessary to access them.