Repository navigation
Node
The MIDAS node is the basic processing unit in the MIDAS framework. Nodes can be of two main types. A node that receives a physiologic signal, processes it and performs feature extraction can be considered a primary node, whereas secondary nodes can be used for all other purposes.
In short, primary nodes rely directly on some raw signal (basically time series) and must be connected to an incoming LSL-datastream. Primary nodes have in-built properties for storing and accessing collected raw data. Secondary nodes have no such requirements and can be used, for example, as intelligence nodes performing data fusion over several primary nodes or as completely custom nodes that get their data in a user-specified format.
All nodes share a similar architecture. The architecture of a node is shown in Figure 3, and the main functions of the node are described below.
Figure 3. Architecture of a MIDAS node
The receiver reads incoming data. In the case of a primary node, the data is typically received from an LSL stream, whereas in the case of a secondary node, data is received from other nodes.
The receiver can also perform some signal processing, e.g., R-peak detection for an ECG signal, in which case the resulting series of interbeat intervals (IBIs) would be used in subsequent analysis steps instead of the original signal.
The broker is a load-balancer that receives incoming messages to the node from the dispatcher and routes the messages to an available responder. The use of a broker allows for concurrency within the node, since several parallel requests can be handled. The number of parallel requests depends on the number of responder processes.
The responder processes incoming requests to the node and performs tasks depending on the type of message, e.g., a request for a metric, data or a command to the node. The Midas Messaging Protocol is described below in more detail.
Each node in the MIDAS network implements a beacon. The beacon broadcasts information about the node, status messages. The beacon also provides heartbeating, which makes it possible to track the status of the node. The beacons broadcast a message with the node information on UDP port 5670.
The dispatcher listens for the beacons, which makes it possible to autodetect available nodes in the MIDAS network, without manual configuraton, apart from instructing which nodes to look for.
The message broadcast by the beacon is one string, where each field is separated by semicolons. Functions simplifying the broadcasting and receiving of beacon messages are provided.
The MIDAS system also supports a publisher-subscription model for message distribution. In this model, nodes can publish messages (e.g. broadcast the value of a metric once every ten seconds, or broadcast when some index has exceeded a certain level). This makes the MIDAS system more flexible, since it does not require that the clients constantly pull information from the nodes, as it allows the nodes to push information to the clients, which allows for event-based actions. Each message can be tagged using a pre-defined topic, which makes it easy for clients to listen to messages of a particular type in the MIDAS network.
If a client wants to subscribe to messages that are broadcast in the MIDAS system, the language that the client is written in must be any of the languages for which there exists bindings for ZeroMQ. The messages broadcast by the nodes are centrally relayed through the dispatcher, so clients only need to connect to the publisher socket of the dispatcher, instead of having to separately connect to every node.
Depending on the request to the node, initiated by the client, the node's responder calls an appropriate analysis function in the node. The analysis function calculates metrics from the data available to the node and returns the results back to the client, through the dispatcher. Analysis functions can also be processes that automatically calculate and store processed values from the raw data, or even publish the result (depicted as analyzer in Figure 3.).
If the node refines the data (e.g., raw signal) it receives, and produces some values, these can be stored too. An example would, e.g., be an ECG node that performs R-peak detection from the raw ECG signal, and stores the interbeat intervals as a new time series. These new data values (e.g., interbeat intervals), become secondary channels in the node, in contrast to primary channels that represent raw signal data.
It should be noted, that the analysis functions are task-specific for each node and are to be written by the user. This means, that although an ECG processing node and an EEG processing node share most of the functionality through the general MIDAS architecture, what sets them apart from each other are the analysis functions. In general, it can be thought that each signal requires a dedicated node, with custom analysis functions.
The goal of the MIDAS framework is to make the writing of new nodes as easy as possible by providing a common architecture shared by the nodes.