Many embedded systems now operate within and depend on webs of wired and wireless connectivity to each other, to enterprise networks and to the broader Internet. As a result, real-time embedded system developers face the challenge of interfacing or 'bridging' to the Global Information Grid (GIG) and maintaining deterministic behavior while moving large quantities of information over non-deterministic network transports.

This involves providing an efficient 'data-path' allowing embedded applications the ability to communicate efficiently with enterprise applications. By combining the data-centric technologies of both the Data Distribution Service (DDS) protocols and data base management systems (DBMS), a viable architectural strategy has emerged. This architectural approach can be used (see Figure 1, below) to facilitate data-centric communication with Service Oriented Architecture (SOA) messaging solutions such as JMS and Web Services.

By bridging the embedded with the enterprise, valuable real-time tactical information can be shared across the broader electronic community. But it's critical that the act of bridging information between enterprise and embedded systems not compromise the real-time deterministic performance of the mission critical embedded systems.

Figure 1. RTI Distributed Data Management framework provides embedded to Enterprise (e2E) bridge.

Network-Centric Computing Model
A key element in providing this critical linkage between the soft and non-real time enterprise and deterministic, hard real time embedded devices is the use of a network-centric computing model that facilitates localized management of distributed data as an integral part of the real-time application that does not rely on a central server topology (for scalability reasons).

The model's topology is peer-to-peer, versus client/server, allowing system architectures to be designed, from the computing nodes perspective, with no single point of failure (i.e. no central server). Network-centric computing is based on all computing nodes being networked such that real-time middleware abstracts the hardware specific details so that the software design doesn't require knowledge of the underlying network topology. This computing model facilitates the design of location transparent software, which directly impacts software module reuse.

Within the network-centric computing model, a huge challenge is managing the distributed data throughout the entire system. Real-time data must be captured, stored, retrieved, queried, and managed such that the proper information can be quickly accessed by all interested participants within the system.

This data management capability can be viewed as, but is not limited to, a distributed real-time database where peer-to-peer (P2P) networking and real-time in-memory database management systems (DBMS) are leveraged to provide a solution that manages storage, retrieval, and distribution of fast changing data in dynamic network environments. Figure 2 below provides a simple illustration of the data management architecture. The benefit of the distributed database model is that it guarantees continuous real-time availability of all information critical to the enterprise.

Figure 2. Real-time Distributed Database Architecture.

Leveraging Standards
As Figure 2 illustrates, the net-centric distributed database architecture is complemented by the support of the leading industry standards for application programming interfaces, data modeling, data manipulation, and high performance, data-centric, publish and subscribe communication, such as ODBC, JDBC, SQL, and DDS. These familiar interfaces minimize the learning curve and facilitate quick time-to-market. In addition, the use of standards greatly simplifies integration with existing infrastructure solutions.

DDS. The OMG's DDS standard, which is now a mandated DoD technology within the DISR (previously JTA), is quickly gaining market traction due to it's ability to abstract the complexities of the network, facilitate the design of location transparent applications, and provide application level control of data QoS within a publish/subscribe communication paradigm.

By utilizing DDS technology for node-to-node communication, the complexity of managing a dynamic network environment, such as ad-hoc wireless networks, is removed from the application developer. It's imperative that a network-centric system accommodate network dynamics without adversely affecting the computing nodes comprising the overall distributed system.

SQL/ODBC/JDBC. Today's DBMS solutions utilize SQL, and ODBC (or JDBC) and are widely accepted standards within the data management community. SQL is used for both data definition and data manipulation while ODBC/JDBC is used as a Call Level Interface for the C/C++ (or Java) programming language. Database Synchronization Framework What is necessary is an integrated database synchronization framework for distributed real-time information management that can implement a distributed shared database where fragments of the shared database are kept in the local data caches (i.e. local memory) of the hosts that comprise the network - on an as-needed basis.

Essentially a DDS enabled distributed database system that operates across an extendable network without the access bottlenecks associated with a central server-based model, the framework allows server nodes to keep complete copies of a database's data store in local memory, reducing the need to move data to and from a disk during operations.

It also permits synchronization of database copies on multiple nodes, creating a distributed database rather than a central server. This enables fast access throughout a distributed system, independent of the number of network nodes. It allows optimized access to data regardless of its source and provides scalability for the network utilizing the database. In addition, such a database synchronization framework virtually eliminates server bottlenecks while providing fault tolerance. With the data available on multiple nodes at any given time, a failure at one node will neither damage data integrity or impede data access at any other system node.

With such a framework, software applications gain reliable, instant access across dynamic networks to information that changes in real-time. Such an architecture uniquely integrates peer-to-peer networking (DDS) and real-time, in-memory database management systems (DBMS) into a complete solution that manages storage, retrieval, and distribution of fast changing data in dynamically configuring network environments.

It guarantees continuous availability in real-time of all information that is critical to the enterprise. DDS technology is employed to enable a truly decentralized data structure for distributed database management system (DBMS), while DBMS technology is used to provide persistence for real-time DDS data.

The power of the model is that embedded applications don't need to know SQL or OBDC semantics, and enterprise applications aren't forced to know publish/subscribe semantics. This is a critical point when building large systems: get the data to where it needs to go in a format that is native to the developers. Thus the database becomes a combination of the data tables distributed throughout the system. When a node updates a table by executing an SQL INSERT, UPDATE, or DELETE statement on the table, the update is proactively pushed to other hosts that require local access to the same table via real-time publish-and-subscribe messaging. This architectural approach enables real-time replication and synchronization of any number of remote data tables.

From a practical perspective, it is important to recognize that a relational database can now be implemented on multiple computing nodes. Furthermore, within such a data synchronization framework, applications view the combination of these distributed data tables as a single 'distributed database.' Figure 3, below, illustrates how this approach unifies the global data space for both embedded and enterprise applications.

Figure 3. Unifying the Global Data Space.

DDS-DBMS and DBMS-DDS Integration
DDS-DBMS integration (i.e. DDSQL) technology facilitates the bridging of embedded real-time systems with enterprise based systems by allowing relational database table updates to be propagated, in real-time, to the embedded nodes.

The embedded node utilizes the DDS API and subscribes to a DDS topic associated with a data table. When the table is altered, either by an enterprise application (via SQL) or an application utilizing the DDS API, the local table is updated, and the update information is published, via DDS, for consumption by all interested DDS subscribers. This allows information to be seamlessly bridged from an enterprise application to an embedded real-time application.

In addition, the framework allows DDS publications and/or subscriptions to be captured and logged into the in-memory database, in real-time, in order to capture and log all incoming or outgoing publish/subscribe activity. This allows live network traffic captures to be logged directly into RAM, thus facilitating the ability to post-process and analyze system communication activity. This logging capacity provides the primitives for building distributed system debug and trace tools, message auditing, as well as design tools that can capture, and playback messages in order to re-create the original system activity for the purposes of lab testing and debug.

Figure 4, below, illustrates the functioning of both table synchronization and DDS-DBMS integration within such a framework.

Figure 4. System Architecture Utilizing RTI Distributed Data Management Capabilities.

DDSQL Building Blocks
To provide application developers further control over the global data space, the data synchronization framework also provides two key bridge components: DDS-DBMS and DBMS-DDS (Figure 5, below).

The DDS-DBMS Bridge monitors the applications published data and incoming (subscribed) data. It enables automatic storage of DDS topic data within the DBMS by mapping DDS topics to tables within the DBMS. As each topic instance is published, the topic instance is likewise inserted as a row in the table. This bridging provides the functionality necessary to support the ability to log both incoming/outgoing message traffic, in real-time, without suffering the performance penalty typically associated with disk based databases.

Figure 5. DDSQL Bridge Components.

The DBMS-DDS Bridge manages the automatic publication of changes made to tables in the DBMS. It will also apply changes received via DDS to tables in the DBMS. This bridge allows table changes, whether made by an SQL enterprise application, or by a DDS enabled application, to be 'pushed' to a pure DDS subscriber, in real-time. This bridge component provides table event bridging from the enterprise application to the embedded application.

Each of these bridge elements contain a Publication and Subscription component with the four components for DDS-DBMS Publication and Subscription and DBMS-DDS Publication and subscription. DDS-DBMS Publication. This component consists of a DDS Data Writer and DBMS Propagator, which is a collection of functionality that disseminates topic instances as well as propagating the outgoing DDS samples to a DBMS table. The propagator performs the DDS-DBMS data-type conversion automatically for the user data types and creates the associated database table, if it doesn't already exist.

It's important to note that node-to-node message latency is not negatively affected with the presence of the Propagator functionality due to the fact that the topic instance is disseminated, via the DDS Data Writer, prior to it being sent to the DBMS Propagator. This bridge component facilitates the local logging of DDS publications destined for remote subscribing applications.

DDS-DBMS Subscription. This component includes a 'DBMS Propagator' which is a collection of functionality that can propagate an incoming DDS sample to a table managed within the DBMS. The propagator provides the necessary functionality to perform the DDS-DBMS data conversion, and create the table if it doesn't yet exist. It also includes a 'DBMS Change Filter,' which filters out samples from DDS that have already been applied to the table to be updated.

The DDS Data Reader will receive the incoming publication allowing the subscribing application to process the data at the application level. The publication is then propagated to the DBMS before the read/take function returns. The DBMS Propagator performs the DDS to DBMS data conversion from the DDS data representation to the DBMS table data representation, and inserts the row in the database for each sample of a topic instance.

If the row already exists, the row is updated. If history configuration is employed, then each publication will be stored as a separate row in the table. The DBMS Change Filter is not used in this scenario. It only plays a role when the DBMS-DDS Bridge is active. This bridge component facilitates the logging of DDS publications from remote applications.

DBMS-DDS Publication. This component, includes a 'DBMS Monitor', 'DBMS Change Filter', and DDS Data Writer. The DBMS Monitor watches for table changes within the DBMS. When a change in a DBMS table is detected, the DBMS Monitor forwards the information to the Change Filter. The filter is used to filter out those changes that have already been distributed via DDS. The altered table row is then distributed using the DDS Data Writer. The DDS Data Writer does not use any type-specific code; instead, it performs a DBMS-DDS data conversion using the table schema to serialize the row contents directly into the DDS wire format.

Thus an enterprise application can change data within a DBMS table, and ultimately have the table update information published, via a DDS Data Writer to any interested subscribing applications, whether they are other enterprise applications, or real-time embedded systems. As a result, this bridge component facilitates the notification and update of table alterations to a subscribing DDS based application, thus bridging data from the enterprise application to the embedded system.

DBMS-DDS Subscription. This component includes a DDS Data Reader, 'DBMS Change Filter', and a 'DBMS Monitor.' The DDS Data Reader will be associated with a table and will subscribe to associated DDS topics to capture. The DDS Data Reader does not use any type specific code; instead, it performs a DDS to DBMS data conversion using the table schema to deserialize the received samples from the DDS wire format directly.

The received sample is applied to the table row as an update by the DBMS Propagator. The DBMS Change Filter mechanism is the same as the one utilized within the DDS-DBMS Subscription component and filters out samples received via DDS that have already been applied to the DBMS table.

So when the DDS Data Reader receives the sample from a remote DDS Data Writer as a result of a table update, the DBMS Change Filter filters out the samples that have already been applied to the DBMS before passing it on to the DBMS Propagator, which sends the incoming DDS topic instance to the appropriate table within the DBMS. Once the table is updated, SQL based application can now access the changed data.

Utilizing DDSQL
With such a data synchronization framework, developers now have a choice when accessing the global data space. Updates made via the SQL API will be visible to DDS user applications, and updates made via the DDS API will be visible to DBMS user applications.

These mechanisms offer a unique combination of features: storage of DDS data in DBMS tables; publication of DBMS data via DDS; mapping between IDL and SQL data types; mapping Between DDS data samples and DBMS table updates; history; and feedback cancellation.

By allowing automatic storage of DDS data into DBMS tables, changes made via the DDS API are propagated to the associated DBMS, as are the changes detected by DDS. Once the data is propagated to the DBMS table, it can be accessed by a SQL user application via the SQL API.

With the ability to do automatic publication of changes in specified DBMS tables, changes made via the SQL API (i.e. INSERT and UPDATE statements) will be published into the network via DDS. SQL queries will report the user data changes received from the network via DDS.

The automatic mapping between DDS data type representation and DBMS schema representation makes it possible to directly translate a DBMS table record to the DDS wire format representation and vice-versa.

Because the DDS type metadata specified in an Interface Description File (IDL) is mapped to a table schema in a DBMS, a DDS topic corresponds to a table in the DBMS, which may be named after the DDS topic name.

Since DDSQL can automatically keep track of the history samples of a DDS topic instance, the number of history samples to store for an instance can be specified as a configuration parameter of the DDS-DBMS Bridge. Normally, a topic instance is mapped to a single row in the associated table, but when history is enabled, each sample of a topic instance will be stored as a separate row.

Finally, when data in the DBMS is changed, DDSQL automatically publishes the change via DDS Publisher. However, since changes made via the DDS API are propagated to the DBMS, 'acoustic' feedback may occur.

DDSQL eliminates this feedback by utilizing a DDS Change Filter and a DBMS Change Filter. Changes received via DDS that have already been applied to the associated DBMS table are automatically filtered out, as are changes in the DBMS that have already been distributed via DDS.

Mark A. Hamilton is Senior Field Application Engineer at Real-Time Innovations .