An Approach to Intra-Vehicular Data Registration and Management

1. An Approach to Intra-Vehicular Data Registration and Management Presented by Mr. William Pritchett DCS Corporation 1330 Braddock Place Alexandria, VA 22302 wpritche@dcscorp.com

2. Agenda • Background • Objectives • Enabling Technologies • Interface Concept • Example Application • Future Work

3. Vector/Raster Data DTED Data Feature Data Vector/Raster Data DTED Data Feature Data Vector/Raster Data DTED Data Feature Data Data Loader Data Loader Data Loader Map Display And Presentation Terrain Services Autonomous Mobility MMU Background • Problem • The evolving focus towards data-driven network centric systems requires an increased capability to share, interpret, and disseminate data (inter/intra vehicle). • Database management systems are not typically integrated into embedded real time weapon systems and generally stovepipe approaches to data sets are integrated through individual applications.

4. Map Display And Presentation Terrain Services Autonomous Mobility Data Registration and Mgmt Vector/Raster Data DTED Data Feature Data Data Loader MMU Background (Cont’d) • Need • Common architectural approach to populate, disseminate, and distribute commonly used/interpreted system data in an implementation independent manner.

5. Background (Cont’d) • WSTAWG identified data registration and management component as part of the Weapon System Common Operating Environment (WSCOE). • Provides for standardized registration, access, and interchange of intra-vehicle data shared across the common support application layer. Intended to provide for the interchange of data among heterogeneous applications without knowledge of the specific underlying data management/database services in effect.

6. Background (Cont’d) WSTAWG WSCOE

7. Background (Cont’d) • Presentation Goals • Identify a set of base requirements, enabling technologies, and concept approach to support the continued definition of a data registration and management WSCOE component.

8. Objectives • High Level Requirements: • Define an architecture/interface that facilitates application and subsystem insertion. • Abstract/encapsulate interface to support varying implementation approaches (ranging from ad-hoc to commercial DBMS). • Provide support for data interchange among heterogeneous subsystems. • Provide scalable approach to support varying applications (ranging from specific data aware to dynamic general purpose applications). • Provide general purpose "query" capability (database-like operations) to support dynamic and/or filtered data. • Provide general publish/subscribe service to distribute well-known often used data (e.g. position data).

9. Enabling Technologies • Sun Java Data Objects (JDO) • W3C Simple Object Access Protocol (SOAP) • OMG Data Distribution • OMG Query Specification

10. Enabling Technologies (Cont’d) • Java Data Objects (JDO) • Status: • Developed by Sun Microsystems. • Undergoing standardization as Java Specification Request 12 within the Java Community Process. • Overview: • Standard for transparent object persistence. • Datastore independent: • Can be used with relational/object databases, file systems, etc. • Relieves the need to know SQL or other specific query language. • Developers are free to concentrate on designing the domain object model for their applications.

11. Enabling Technologies (Cont’d) • Java Data Objects (JDO) • Benefits • Developers need not know SQL or any other query language. • Supports multiple back-ends (databases, files, etc): • Increases portability--not dependent on any one technology. • Drawbacks • Technology is still emerging. • Java-centric.

12. Enabling Technologies (Cont’d) • Simple Object Access Protocol (SOAP) • Status: • 5/8/2000 Ver 1.1 released as W3C Recommendation. • 5/7/2003 Ver 1.2 released as proposed W3C Recommendation. • Overview: • Provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. • Defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules.

13. Enabling Technologies (Cont’d) • Simple Object Access Protocol (SOAP) • Benefits • Open standard. • Vendor-neutral. • Supports heterogeneous interoperability. • Multi-protocol support. • Promotes loosely-coupled distributed systems. • Large tool support base. • Drawbacks • SOAP over HTTP requires a stateless request/response architecture that is not appropriate under all circumstances. • All SOAP data is serialized and passed by value: • Currently there is no provision for passing data by reference. • Overhead of extracting SOAP envelope, parsing XML, creating appropriate objects and converting parameters. • ASCII-based XML messages may require significant bandwidth.

14. Enabling Technologies (Cont’d) • OMG Data Distribution • Status • Recommended for adoption by OMG Technical Committee. • On target for June 2003 Adoption. • Overview • Provides data publish/subscribe capabilities. • Benefits • Enables loosely-coupled systems: • Data producers need not know about data consumers • Efficient, low-latency data distribution. • Supports hard real-time programming. • Drawbacks • Specification is not approved (though imminent): • Little vendor support • Publish/Subscribe paradigm not appropriate in all cases.

15. Enabling Technologies (Cont’d) • OMG Query Service • Status: • Approved specification. • Overview • Provides operations on collections of objects. • Benefits • Provides distributed query capabilities for all kinds of data sources: • Datastore technology independent. • OMG Standard. • Drawbacks • Not designed for real-time, embedded systems: • No embedded implementations. • Programmers still required to know query language (SQL, etc.).

16. Interface ConceptHigh-Level Design • Publish Subscribe Services for real-time distribution of transient data • Modeled after OMG Data Distribution • Persistent Storage Services for access to persistent data • Based on Java Data Object

17. Interface Concept (Cont’d)Persistent Storage Service

18. Interface Concept (Cont’d) Persistent Storage Service • The PersistenceManagerFactory is the interface used to obtain PersistenceManager instances. • The PersistenceManager is the primary interface for application components. • The Query interface allows applications to obtain persistent instances from the data store. • Instances of the Extent class represent the entire collection of instances in the data store of the candidate class possibly including its subclasses. • The Extent instance has two possible uses: • To iterate all instances of a particular class. • To execute a Query in the data store over all instances of a particular class. • PersistentData is the “Base Object” for all data that is persistent. • Collection and Iterator are used to iterate over items returned through queries or extents. • The Transaction interface provides for initiation and completion of transactions under user control. (Modifying data in the datastore).

19. Interface Concept (Cont’d)Example Write

20. Interface Concept (Cont’d)Example Query

21. Interface Concept (Cont’d)Publish-Subscribe Service

22. Interface Concept (Cont’d)Publish-Subscribe Service • Publisher—responsible for data issuance. • Subscriber—responsible for receiving published data and making available to applications. • DataReader—facade to subscriber. • DataWriter—facade to publisher. • Topic—associates a name, data type and QoS to data itself: • Allows subscribers to unambiguously refer to publications. • Data—common base from which all published/subscribed data is derived. • Domain Participant—represents the local membership of the application in a domain: • A domain conceptually links all publishers and subscribers.

23. Interface Concept (Cont’d)Example Publish

24. Interface Concept (Cont’d)Example Subscribe

25. Future Work • Identification/incorporation of security requirements. • Identification/specification of real-time attributes (e.g. caching) for persistent storage. • Specification of valid query strings for filters for persistent storage. • WSCOE Technology/Program Coordination: • FCS • WSTAWG • CDAS • 4DRCS