Jump to content

Technical Reference:States of Operation: Difference between revisions

From BCI2000 Wiki
Mellinger (talk | contribs)
No edit summary
Mellinger (talk | contribs)
 
(16 intermediate revisions by the same user not shown)
Line 15: Line 15:
==System Startup==
==System Startup==
===Introduction===
===Introduction===
Since the
Since the system is a distributed system of encapsulated modules, a proper and well defined information flow at start-up needs to be ensured.
system is a
distributed system of encapsulated modules, this procedure ensures a
proper and
well defined information flow at start-up.
Each module publishes its requests for parameters and states to
Each module publishes its requests for parameters and states to
the Operator module, which configures those and sends them back.
the Operator module, which configures those and sends them back.
After Data Acquisition receives all parameters and states, it tries to
Once the Signal Source module receives all parameters and states, it tries to
connect
connect
to Signal Processing and -- upon successful connection -- sends a
to Signal Processing and, upon successful connection, sends a
positive status
positive status
message to the Operator.
message to the Operator.
In the same way, Signal Processing connects to the Application and the
In the same way, Signal Processing connects to the Application and the
Application module connects to the Data Acquisition module.
Application module connects to the Signal Source module.
After the Operator receives status messages from all three core
After the Operator receives status messages from all three core
modules, the
modules, the
system is fully initialized and is triggered to start, as soon as the
system is fully initialized and is triggered to start, as soon as the
Operator
Operator
sends the state <tt>Running</tt> with a value of 1 to the Data
sends the state <tt>Running</tt> with a value of 1 to the Signal Source module.
Acquisition module.


===Startup Sequence===
===Startup Sequence===
The operator module must be started first. Since in most cases the IP
The operator module must be started first. Its IP
address of
address is provided to core modules when they are executed, defaulting to ''localhost'' to match the most typical configuration.
the operator module can be more easily statically defined, its IP
 
address and
port number(s) have to be provided to the core modules.
The operator module listens on ports 4000
The operator module listens on ports 4000
(for Source), 4001 (for Signal Processing), and 4002 (for Application)
(for Source), 4001 (for Signal Processing), and 4002 (for Application),
and
and
waits for the respective core module to connect. Each can connect to
waits for the respective core module to connect. Each can connect to
its
its
assigned port on the operator module in any order. Upon start-up,
assigned port on the operator module in any order.
each core
 
module opens a listening socket on an arbitrary port number.
Once connected to the operator module, each core
module opens its own listening socket on an arbitrary available port, and creates a parameter to contain this port number. Later on, these sockets will be used to create connections between core modules.


===Publishing Phase===
===Publishing Phase===
Upon connection, each core module sends a [[Technical Reference:BCI2000 Messages|protocol version message]] which is then matched with the operator module's protocol version, making sure that only modules with matching protocol versions are combined.  
Upon connection, each core module sends a [[Technical Reference:BCI2000 Messages|protocol version message]] which is then matched with the operator module's protocol version, making sure that only modules with matching protocol versions are combined.  
Following its protocol version, each core module publishes its parameters to the
Following its protocol version, each core module publishes its parameters to the
operator module as a sequence of [[Technical Reference:BCI2000 Messages|parameter messages]].
operator module as a sequence of [[Technical Reference:BCI2000 Messages|parameter messages]].
Line 59: Line 54:
parameters, each core module publishes the states it requests as
parameters, each core module publishes the states it requests as
a sequence of [[Technical Reference:BCI2000 Messages|state messages]].
a sequence of [[Technical Reference:BCI2000 Messages|state messages]].
At this time, the operator module ignores
Following the last
every
field except ''Name''  and ''Length'' , which it needs to
construct the
state vector.
For this and all subsequent communication, the modules use the [[Technical Reference:BCI2000 Messages|BCI2000 messages]]
protocol. Following the last
state, each core module sends a system command containing the string
state, each core module sends a system command containing the string
<tt>EndOfState</tt>.
<tt>EndOfState</tt>.
On receiving this command from all core modules, the operator module
On receiving this command from all core modules, the operator module
processes the received parameters and states. It
processes the received parameters and states. It
creates a
creates a
list of all parameters and all states and creates the state vector
list of all parameters and all states, and creates a global state vector, ignoring all
(duplicate
fields from state messages, except ''Name''  and ''Length''.
parameters or states are ignored), and ends
this initial publishing phase.
In order to maintain integrity throughout operation, no parameters or
In order to maintain integrity throughout operation, no parameters or
states
states
Line 84: Line 72:
may modify
may modify
the value of the parameters and states (depending on the
the value of the parameters and states (depending on the
investigator's input or
investigator's manual input or loading a parameter file).  
the parameter file). The operator module then uses the same channel on
The operator module then uses the same connections on
which it
which it
received data from the core modules to send back to all core modules a
received data from the core modules to send back to all core modules a
list of
list of
all system-wide parameters and system-wide states (in any order).
system-wide parameters and system-wide states, in any order.
Since the IP
Since IP
address and port number on which the core modules listen for data from
addresses and port numbers on which the core modules listen for data from
other
other
core modules are published in system parameters as described, each
core modules are represented in system parameters as described above, each
module now
module now
knows where to send its data. The connections from the core modules to
knows where to connect to.
Accordingly, each core module opens a client
connection
to the core module it must connect to, i.e., Source opens a
connection to Signal Processing, Signal Processing to Application, and
Application to Source.
 
The connections from core modules to
the
the
operator module remain open (all subsequent traffic will go through
operator module remain open. All subsequent core-to-operator communication will go through
these
these
connections).
connections.
As in the publishing phase, the Information Phase ends when a system
 
As for the publishing phase, the Information Phase ends when a system
command
command
<tt>EndOfState</tt> is sent.
<tt>EndOfState</tt> is sent.


===Preflight Phase===
===Preflight Phase===
In the preflight phase, each core module declares whether it can process data with the
In the preflight phase, each core module declares to the Operator module whether it is able to properly process data using current parameters and states.
received parameters and states, and reports the properties of its output signal.
In addition, it reports the properties of its output signal to the core module next in the chain.


The operator module opens the preflight phase by sending an empty [[Technical Reference:BCI2000 Messages|signal properties message]] to the source module.
The Operator module opens the preflight phase by sending an empty [[Technical Reference:BCI2000 Messages|signal properties message]] to the Source module.
The source module then reports its output signal properties to the signal processing module by sending it an appropriate signal properties message.
The Source module then reports its output signal properties to the Signal Processing module by sending it an appropriate signal properties message.
The signal processing module, in turn, sends its output signal properties to the application module.
The Signal Processing module, in turn, sends its output signal properties to the Application module.


During the preflight phase, modules indicate errors by sending descriptions
During the preflight phase, modules indicate errors by sending [[Technical Reference:BCI2000 Messages|status messages]] containing plain-text error descriptions.
into an error channel.
If any errors are found during the preflight phase, a module will not initiate its initialization phase. The operator module will display error messages received from core modules, prompting the user to fix the problems detected rather than offering a "Start" option.
If any errors are indicated during the preflight phase, the module will not initiate the initialization phase; the operator module will display the errors, prompting the user to fix the problems detected, and not offer the "Start" option.


===Initialization Phase===
===Initialization Phase===
Each core module uses the information in the received parameters to
Each core module uses the information in the received parameters to
configure and
configure and
initialize its operation. It also opens an active (i.e., client)
initialize its operation.
connection
Then, each core module sends a [[Technical Reference:BCI2000 Messages|status message]]
to the other core module it must connect to, i.e., Source opens a
connection to Signal Processing, Signal Processing to Application and
Application to Source.
Each core module sends a [[Technical Reference:BCI2000 Messages|status message]]
to the
to the
operator that indicates either successful or failed initialization.
operator that indicates either successful or failed initialization.
The
The
Initialization Phase ends when all core modules indicate successful
Initialization Phase ends when all core modules indicate successful
Line 133: Line 125:
==System is Suspended==
==System is Suspended==
At the end of the Initialization Phase, the system is fully
At the end of the Initialization Phase, the system is fully
configured. All
configured.  
parameters and states (and positions thereof in the state vector) are
All parameters, states, and state vector, are now defined and available globally.
defined.
 
The system is suspended when ''Running'' is 0. Any module shall
The system's state is now determined by a special ''Running'' state variable, which is initially set to "0", indicating that the system is suspended.
 
As long as operation is suspended, any module might update system parameters and send them back to the Operator.
Any module shall
disregard a
disregard a
change in parameters if the system is not suspended. Data flows
change in parameters unless the system is in suspended state.
 
While the system is suspended, data may still flow
through the
through the
system and it is up to each module to decide how to process these
system.
data. The
It is up to each module to decide how to process these
Application, for example, might give visual feedback that indicates
data.
that the
The Application, for example, might give visual feedback that indicates
system is suspended. As long as operation is suspended (i.e.,
that the system is suspended.
 
==System is Running==
The system is started when the Operator module sets the special state variable
''Running''  
''Running''  
is 0), any module might update system parameters and send them back to
to 1 and sends it to the Source module.
the
Operator.


==System is Running==
During system operation, the Operator module may modify any state variable by sending
During system operation, the Operator module must send states only to
state messages to the Source module.
The Operator module must send states only to
the Source
the Source
module; Signal Processing and Application must disregard any state
module; Signal Processing and Application must disregard any state
that the
that the
Operator does send to them.
Operator does send to them.
The system is started when the Operator module sets the state
''Running''
to 1 and sends it to the Source module.


==System Termination==
==System Termination==
To each of the three core modules, the operator module indicates
To each of the three core modules, the operator module indicates
system termination
regular system termination
by closing the connection to that module.
by closing the connection to that module.


When a core module loses connection to the two other core modules it
Irregular system termination takes place when a core module loses connection to any of the two other core modules it
is connected
is connected
to, it will send an error message to the operator, and then quit.
to.
The operator module, in turn, will close the connections to the
In this case, it will send an error message to the operator, and then quit.
The operator module, in turn, will close connections to the
remaining core
remaining core
modules.
modules.


[[Category:Specification]]
[[Category:Specification]]

Latest revision as of 10:41, 22 October 2008

This page describes the states of operation that apply to a BCI2000 system as a whole. These are different from the concept of BCI2000 state variables which are saved to data files.

Driven by user interaction from the operator module, the system cycles through five phases of operation: Startup, Initialization, Suspended, Running, Termination.

State Diagram

Startup -> Initialization <-> Suspended -> Termination
                                  ^
                                  |
                                  v
                               Running

System Startup

Introduction

Since the system is a distributed system of encapsulated modules, a proper and well defined information flow at start-up needs to be ensured. Each module publishes its requests for parameters and states to the Operator module, which configures those and sends them back. Once the Signal Source module receives all parameters and states, it tries to connect to Signal Processing and, upon successful connection, sends a positive status message to the Operator. In the same way, Signal Processing connects to the Application and the Application module connects to the Signal Source module. After the Operator receives status messages from all three core modules, the system is fully initialized and is triggered to start, as soon as the Operator sends the state Running with a value of 1 to the Signal Source module.

Startup Sequence

The operator module must be started first. Its IP address is provided to core modules when they are executed, defaulting to localhost to match the most typical configuration.

The operator module listens on ports 4000 (for Source), 4001 (for Signal Processing), and 4002 (for Application), and waits for the respective core module to connect. Each can connect to its assigned port on the operator module in any order.

Once connected to the operator module, each core module opens its own listening socket on an arbitrary available port, and creates a parameter to contain this port number. Later on, these sockets will be used to create connections between core modules.

Publishing Phase

Upon connection, each core module sends a protocol version message which is then matched with the operator module's protocol version, making sure that only modules with matching protocol versions are combined.

Following its protocol version, each core module publishes its parameters to the operator module as a sequence of parameter messages. After publishing its parameters, each core module publishes the states it requests as a sequence of state messages. Following the last state, each core module sends a system command containing the string EndOfState.

On receiving this command from all core modules, the operator module processes the received parameters and states. It creates a list of all parameters and all states, and creates a global state vector, ignoring all fields from state messages, except Name and Length. In order to maintain integrity throughout operation, no parameters or states should be added to or removed from the system beyond this point.

System Initialization

Information Phase

At this point, the operator module may modify the value of the parameters and states (depending on the investigator's manual input or loading a parameter file). The operator module then uses the same connections on which it received data from the core modules to send back to all core modules a list of system-wide parameters and system-wide states, in any order. Since IP addresses and port numbers on which the core modules listen for data from other core modules are represented in system parameters as described above, each module now knows where to connect to. Accordingly, each core module opens a client connection to the core module it must connect to, i.e., Source opens a connection to Signal Processing, Signal Processing to Application, and Application to Source.

The connections from core modules to the operator module remain open. All subsequent core-to-operator communication will go through these connections.

As for the publishing phase, the Information Phase ends when a system command EndOfState is sent.

Preflight Phase

In the preflight phase, each core module declares to the Operator module whether it is able to properly process data using current parameters and states. In addition, it reports the properties of its output signal to the core module next in the chain.

The Operator module opens the preflight phase by sending an empty signal properties message to the Source module. The Source module then reports its output signal properties to the Signal Processing module by sending it an appropriate signal properties message. The Signal Processing module, in turn, sends its output signal properties to the Application module.

During the preflight phase, modules indicate errors by sending status messages containing plain-text error descriptions. If any errors are found during the preflight phase, a module will not initiate its initialization phase. The operator module will display error messages received from core modules, prompting the user to fix the problems detected rather than offering a "Start" option.

Initialization Phase

Each core module uses the information in the received parameters to configure and initialize its operation. Then, each core module sends a status message to the operator that indicates either successful or failed initialization.

The Initialization Phase ends when all core modules indicate successful configuration.

System is Suspended

At the end of the Initialization Phase, the system is fully configured. All parameters, states, and state vector, are now defined and available globally.

The system's state is now determined by a special Running state variable, which is initially set to "0", indicating that the system is suspended.

As long as operation is suspended, any module might update system parameters and send them back to the Operator. Any module shall disregard a change in parameters unless the system is in suspended state.

While the system is suspended, data may still flow through the system. It is up to each module to decide how to process these data. The Application, for example, might give visual feedback that indicates that the system is suspended.

System is Running

The system is started when the Operator module sets the special state variable Running to 1 and sends it to the Source module.

During system operation, the Operator module may modify any state variable by sending state messages to the Source module. The Operator module must send states only to the Source module; Signal Processing and Application must disregard any state that the Operator does send to them.

System Termination

To each of the three core modules, the operator module indicates regular system termination by closing the connection to that module.

Irregular system termination takes place when a core module loses connection to any of the two other core modules it is connected to. In this case, it will send an error message to the operator, and then quit. The operator module, in turn, will close connections to the remaining core modules.