Framework (Requirements)

General (G):

1. Framework should allow to exchange data between different software modules

2. Data exchange must be type safe.

   Type information must be maintained while exchanging data so that there is no need for the receiver/consumer of the data to check if the data has a given type.

3. Data should be exchanged using channels where a channel is uniquely described by a name and a data type.
4. Read and write access to channels is done via the channel name
5. Data can only read from and written to a channel if the data type matches the type of the channel
6. Besides access using polling - read access should also be possible by registering a user defined module callback on that channel that gets called whenever data in the channel changes
7. All data in a channel is temporal stamped to allow associating data of one channel with the respective data of another channel at the same time
8. Besides accessing the current/newest data element in a channel it should be possible to access recent data in the channel at a specific timestamp. Therefore the channel needs to keep/store a history of data. This way synchronization of different channels will be possible.
9. When accessing recent/old data it must be possible to define the way how the data is obtained from the history (e.g. interpolating, extrapolating). It also must be possible to provide a user defined "interpolator". Interpolating the data allows a higher precision of the algorithms that need access to data at an exact timestamp even if there was no data sampled at that time.
10. To exchange loss less, non interrupted data streams (e.g. audio streams) it must be possible to access not only a single value from a channel but an interval of data where the beginning and end is given by a timestamp. This way a reading module can access all the data that was accumulated since the last read cycle.
11. The length of the channel history must be limited. The limit will be given in a configuration file. When history reaches these limits old data gets overwritten.
12. Distributed applications: Modules should have access to common data across processes and system borders (on the same system as well as over network via TCP/UDP).
13. When running modules in the same process in different threads the framework provides a way of thread safe concurrent access to the data.
14. When running modules in different processes or on different systems using multiple frameworks (using TCP/UDP) the framework provides a way to synchronize data between the different frameworks
15. When using multiple frameworks the framework ensures that there are no collisions of channels (names and data types) and that they are resolved.

Performance (P):

1. The framework should allow handling of huge amounts of data. Therefore there should be no need to copy data when exchanging it via channels. This is more important when running modules in the same process. Here only memory addresses should be exchanged.
2. When accessing (read and write) channel data the accessing module must not wait for the access neither should it block any other module (e.g by locking a mutex)
3. The transmission delay for a data message must be very low. Within the same process < 0.5ms. Between modules in different processes (depending on the network connection) < 10ms.
4. Throughput of data for modules in one process must be unlimited (e.g. by exchanging memory addresses). Between modules in different processes (depending on the network connection) >10-50 MB/s.

Stability (St):

1. A single module must not affect the stability of the framework. When a single module blocks while reading/processing/writing data (e.g. in a callback) the communication of other modules must not be affected.
2. When exchanging data across process borders one process must not affect the stability of other framework processes. E.g. when a process terminates unexpected all the other involved processes must continue to work.

Usability (U):

1. Data should not be explicit locked/unlocked by the user. The framework should hide the locking mechanism from the user (avoid implementation errors). The user should gain access to the data via a proxy object that encapsulates a locked data field. If the proxy object is destroyed (e.g. goes out of scope) the data is unlocked and listeners/callbacks gets notified automatically.
2. The framework should provide a light weight interface. It should only be necessary to implement a few methods to work with the framework. It should be also possible to access the framework without the need to derive from special callback classes of interfaces (using only global functions).
3. The API for data exchange must be fully transparent. This means there is no need to change code for running modules in one process or distributed in a network.

Security (Se):

1. The modules must register read and write access to the channels in order to get access to the data.
2. It must be ensured that the framework can be extended to limit the access rights for specific modules.
3. It should be possible to add encryption for exchanged data.

Design decisions:

• Data will be stored in channels. They provide a data buffer. The channels with their data will be managed by the framework so that different modules have access to the data via these channels (G1, G2)
• The channels itself are template classes that ensure the type safety of the contained data (G3, G6)
• The framework stores the channels by a globally unique name (G4, G5)
• Every data buffer of a channel consists of several slots. Slots allow independent write and read access to the stored data. The number of slots can be limited. (G12,P1,P2,St1).
• Slots will be ordered in correct temporal oder inside the channels buffer (mira::ChannelBuffer) (G9, G10, G11)
• Channels are accessed using channel objects (mira::Channel), which handle read and write access to the data slots via proxy objects (Se1, Se2)
• Access to slots is done via independent read (mira::ChannelRead) and write (mira::ChannelWrite) proxys. These proxys ensure that slots are protected from concurrent write access and that slots are unlocked automatically when access is not longer needed (G14, U1).
• Every process has its own Framework-Singleton (mira::Framework), that allows access to the channels (G1)
• The Framework-Singleton manages different "Authorities" (mira::Authority). These authorities identify all modules that want to have access to data. (G14, U2, Se1, Se2)
• Every framework process has a remote component (mira::RemoteModule). This component allows the connection of different frameworks and manages data exchange across process and system borders. (G13)
• The remote component behaves like a module that accesses the data of the framework. It takes read requests from other frameworks and directs them to the local framework. It also sends notifications whenever data changes locally to remote frameworks. (G15,St2,Se3)
• The framework distinguishes between local and globally unique channel names. The framework uses global names. Every authority can gain access to a channel via its global name but can use the local name internally. The registry component (mira::NameRegistry) of the framework allows conversion from local to global names. (G4)
• To avoid naming conflicts every authority can be assigned to a namespace. The global name then consist of the namespace and the local name.(G16)