ARCHITECTURE
MnemonicBroker™ and Interpret™ Architecture: the Context
The picture below shows the overall separation of concerns in a typical RT data acquisition and interpretation system and the role played by Truescope Technologies, Inc. MnemonicBroker™ and Interpret™
The MnemonicBroker™ Architecture
The MnemonicBroker™ is a multi-tiered architecture built around a rich set of meta-data. This enables high value-added capabilities as well as ensuring maximum configurability and run-time self-tuning.
The architecture is tiered around the following layers:
- Publish/Subscription management layer;
- Mnemonic management layer;
- Storage layer;
- Encryption and authorization conern, pervasive throughout the architecture
Some of the core features supported (see a coarse-gain level view):
Cewntral mnemonics (measurement points):
- Mnemonics: a central feature of the MnemonicBroker™ is its ability to manage measurement points (called mnemonics). As such, a mnemonic is strictly indexed by a precise time value which represent when the value(s) of the measurement point(s) the mnemonic datapoint contains has(ve) been acquired.
- Mnemonics services: the following are basic services provided to process incoming or outgoing mnemonics values: Sampling, synchronization, filtering (max-min, linear interpolation, average, etc.) and more. Note that customs services can be programmed and plugged-in into the MnemonicBroker™ services layer
- Services allow pre-transformation or pre-computation upon mnemonics points as they are acquired or notified to client applications.
- Multi-point mnemonics: Ability to associate to one mnemonic multiple measurement points acquired at similar frequency. E.g., for a Pump_output mnemonic, one measurement point for Torque, Pressure, Temperature, and Flow each time Pump_output is acquired.
- Multi-source mnemonics: Ability to associate to one mnemonic multiple sensors for instance to upgrade critical ones, or to ensure a continuous data value acquisition. As some particular measurement points are often vital and for which there cannot be any interruption of acquisition, one strategy commonly used is to have redundant sensors capturing the same measurement point. A multi-source mnemonic allows one to aggregate all sensors of a similar type to one mnemonic audits name which makes sure at least one of the sensor value pair is returned. The same concept can be used for maintenance of sensors, etc.
- Transient mnemonics: To facilitated communication among client applications, each client can define mnemonics that only exist temporary and are not physically stored. Another client can then be notified here thereof, and subscribe to such mnemonic. Note that within one client application, the same option applies. This facilitates greatly inter-application (computed mnemonics communication)
- Compound mnemonics: Ability to define one mnemonic as an aggregation of other mnemonics along time intervals (strictly non-time-overlapping on the time axis).
Contextual data:
- Support for contextual data: Ability to augment the MnemonicBroker™ with an open-source RDBMS in which an application can persist complex objects (such as alarms, state of dynamic models (fluids, physiological (medical compound),reservoir, etc).
TCO, Systems & Performance:
- Manages and Scales to up to at least 10,000 different mnemonics at an average of 5Hz each
- The above, concurrently with a large number of client-based mnemonic subscriptions/notifications.
- Distributable architecture: for maximum scalability, or redundancy, the MnemonicBroker™ server can be distributed across a number of physical servers.
- Thread pooling: To get around the thread count limitation and management overhead of some operating systems as well as to reuse existing resources to gain further performance, the MnemonicBroker™ incorporates a smart thread pooling management.
- MTBF of over 90 days
- Mnemonics are flushed to physical storage in near real-time (configurable)
- "Install, configure, and forget". Much effort has been spent on the survivability of the system and its ease of use and administration.
- Simple packaging: The MnemonicBroker™ has been designed to be embedded in our customers application when needed. As such it can be totally silent, and be included in your standard install and administration seamlessly.
- Runs wherever a compatible JVM does (JDK v1.5 required)
- Tested with the virus scna leaders on Windows
Meta-data driven:
- A full set of meta-data is available about:
- The mnemonics
- The configuration of the MnemonicBroker™
- The state of the MnemonicBroker™
The MnemonicBroker™ can be deployed in a number of configurations:
- Single server: All components running on one physical server - this is the most common usage.
- Multi-server: This corresponds to the distributable architecture option for maximum mnemonic load and servicing.
- Repeaters: Ability to have redundant MnemonicBroker™ within the same network for reliability (and other use)
- Layered: Ability to set a structure (think Petri-net like) of MnemonicBroker&tradel intercommunicating together in specific main flows for particular application processing and data architectures. One concrete example is one where:
- A first layer is made of MnemonicBroker™ whose role is to make sure all mnemonics points are captured without exceptions (say on a number of locations)
- A second layer of MnemonicBroker&tradel at a remote location that receives particularly subscribed and filtered data of interest for such and such application processing.
- One can think of n-levels or special purpose MnemonicBroker&tradel being populated by certain types of mnemonics only, say, all mnemonics concerning radiation measurements coming from all different physical locations among others.
The available configuration depends though on which member of the MnemonicBroker™ family one uses.
The MnemonicBroker™ product is a 100% Java application built on top of Corba (the underlying backbone of existing J2EE and RMI implementations). It leverages core capabilities of the corba-based publish/subscribe architecture. In doing so, it relies on a 100% proven remote object connection and reliability architecture running on many of the core QoS critical domains around us. Today, as reported in Aviation Week, a Space Technology magazine, over 80% of modern Air traffic Control systems are built on corba-based architectures.
The Interpret™ Architecture
Interpret™ leverages the mnemonics data available through the MnemonicBroker™ to help you build your interpretation applications.
Interpret™ is an application development environment with deployment capabilities which help you focus on the computation elements of your value-add interpretation, not on the mechanics of how to access or store mnemonics. At the lowest level of granularity, you build "services" (i.e.: small unit of interpretation) which you can combine in fully-fledged applications with Interpret™. Note: Interpret™ is built on as a plug-in to Eclipse, an open-source Java-based IDE.
A typical scenario runs like this:
The mnemonics the MnemonicBroker™ is acquiring captures measurement points which feeds a model you have built for a particular purpose; say for instance, to predict a rise in temperature or blood pressure.
- To start with, Interpret™ allows you to browse the MnemonicBroker™ mnemonic meta-data dictionary to select the mnemonics necessary to compute your model
- You then develop the logic of your model in Interpret™ using the incorporated coding framework for interfacing with the Mnemonic Broker™
- Once done, you then package the logic as a service which can then be deployed (run) from a particular location. The service will connect the MnemonicBroker™ to start processing as you request it to do so.
- Note: Services can be embedded one into the other.
Interpret™ encompasses all the necessary framework glue to make sure your engineers only concern themselves with the logic of your interpretations and value-add applications, and as little as possible with the programmatic and system deployment aspects of building your applications.
This is applicable for rich interpretations which you identify in the data in real time and/or make available to other applications (possibly for pro-active actions). Or also, to feed to complex topical models (environmental, physiological, reservoir, hydraulics, etc) you need to interface to with RT data for particular processing and action.
Interpret™ achieves a 5x productivity in developing custom interpretation and analyses with custom topical model interfacing using a meta-data driven generation tool. It also provides real time (sampled) data migration to an off-line SQL RDBMS for external access or standard-based reporting.
Interpret™ is a 100% Java application.
Note: Interpret™ built applications can also be run directly on the system running the MnemonicBroker™ server.