The following are a set of definitions for terms used within the Fledge documentation and code, these are designed to be an aid to understanding some of the principles behind Fledge and improve the comprehension of the documentation by ensuring all readers have a common understanding of the terms used. If you feel any terms are missing or not fully explained please raise an issue against, or contribute to, the documentation in the Fledge GitHub repository.


A representation of a set of device or set of values about a device or entity that is being monitored and possibly controlled by Fledge. It may also be used to represent a subset of a device. These values are a collection of Datapoints that are the actual values. An asset contains a unique name that is used to reference the data about the asset. An asset is an abstract concept and has no real implementation with the fledge code, instead a reading is used to represent the state of an asset at a point in term. The phase asset is used to represent a time series collection of 0 or more readings.

Control Service

An optional microservice that is used by the control features of Fledge to route control messages from the various sources of control and send them to the south service which implements the control path for the assets under control.

Core Service

The service within Fledge that is responsible for the oversight of all the other services. It provides configuration management, monitoring, registration and routing services. It is also responsible for the public API into the Fledge system and the execution of periodic tasks such as purge, statistics and backup.


A datapoint is a container for data, each datapoint represents a value that is known about an asset and has a name for that value and the value itself. Values may be one of many types; simpler scalar values, alpha numeric strings, arrays of scalar values, images, arbitrary binary objects or a collection of datapoints.


A combination of a Filter Plugin and the configuration that makes that filter perform the processing that is required of it.

Filter Plugin

A filter plugin is a plugin that implements an operation on one or more reading as it passes through the Fledge system. This processing may add, remove or augment the data as it passes through Fledge. Filters are arrange as linear pipelines in either the south service as data is ingested into Fledge or the north services and tasks as data is passed upstream to the systems that receive data from Fledge.


A microservice is a small service that implements parts of the Fledge functionality. They are also referred to as services.

Notification Delivery Plugin

A notification delivery plugin is used by the notification service to delivery notifications when a notification rule triggers. A notification delivery plugin may send notification data to external systems, trigger internal Fledge operations or create reading data within the Fledge storage service.

Notification Rule Plugin

A notification rule plugin is used by the notification service to determine if a notification should be sent. The rule plugin receives reading data from the Fledge storage service, evaluates a rule against that data and returns a triggered or cleared state to the notification service.

Notification Service

An optional service within Fledge that is responsible for the execution and delivery of notifications when events occurs in the data that is being ingested into Fledge.


An abstract term for any service or system to which Fledge sends data that is has ingested. Fledge may also receive control message from the north as well as from other locations.

North Plugin

A plugin that implements to connection to an upstream system. North plugins are responsible to both implement the communication to the north systems and also the translation from internal data representations to the representation used in the external system.

North Service

A service responsible for connections upstream from Fledge. These are usually systems that will receive data that Fledge has ingested and/or processed. There may also be control data flows that operate from the north systems into the Fledge system.

North Task

A task that is run to send data to upstream systems from Fledge. It is very similar in operation and concept to a north service, but differs from a north service in that it does not always run, it is scheduled using a time based schedule and is designed for situation where connection to the upstream system is not always available or desirable.


A linear collection of zero or more filters connected between with the south plugin that ingests data and the storage service, or between the storage service and the north plugin as data exits Fledge to be sent to upstream systems.


A dynamically loadable code fragment that is used to enhance the capabilities of Fledge. These plugins may implement a south interface to devices and systems, a north interface to systems that receive data from Fledge, a storage plugin used to buffer readings, a filter plugin used to process data, a notification rule or notification delivery plugin. Plugins have well defined interfaces, they can be written by third parties without recourse to modifying the Fledge services and are shipped externally to Fledge to allow for diverse installations of Fledge. Plugins are the major route by which Fledge is customized for individual use cases.


The process by which readings are removed from the storage service.


A reading is the presentation of an asset at a point in time. It contains the asset name, two timestamps and the collection of datapoints that represent the state of the asset at that point in time. A reading has two timestamps to allow for the time to be recorded when Fledge first read the data and also for the device itself to give a time that it sets for when the data was created. Not all devices are capable of reporting timestamps and hence this second timestamp may be the same as the first.


Fledge is implemented as a set of services, each of which runs constantly and implements a subset of the system functionality. There are a small set of fixed services, such as the core service or storage service, optional services for enhanced functionality, such as the notification service and control service. There are also a set of non-fixed services of various types used to interact with downstream or south devices and upstream or north systems.


An abstract term for any device or service from which Fledge ingests data or over which Fledge exerts control.

South Service

A service responsible for communication with a device or service from which Fledge is ingesting data. Each south service connections to a single device and can collect data from that device and optionally send control signals to that device. A south service may represent one or more assets.

South Plugin

A south plugin is a plugin that implements the interface to a device or system from which Fledge is collecting data and optionally to which Fledge is sending control signals.

Storage Service

A microservice that implements either permanent or transient storage services used to both buffer readings within Fledge and also to store Fledge’s configuration information. The storage services uses either one or two storage plugins to store the configuration data and the readings data.

Storage Plugin

A plugin that implements the storage requirements of the Fledge storage service. A plugin may implement the storage of both configuration and readings or it may just implement readings storage. In this later case Fledge will use two storage plugins, one to store the configuration and the other to store the readings.


A task implements functionality that only runs for specific times within Fledge. It is used to initiate periodic operations that are not required to be always running. Amongst the tasks that form part of Fledge are the purge task, north tasks, backup and statistics gathering tasks.