MIRA
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
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: