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_at_dcscorp.com

2
Agenda

• Background
• Objectives
• Enabling Technologies
• Interface Concept
• Example Application
• Future Work

3
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
Background (Contd)

• Need
• Common architectural approach to populate,
  disseminate, and distribute commonly
  used/interpreted system data in an implementation
  independent manner.

5
Background (Contd)

• 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 (Contd)
WSTAWG WSCOE
7
Background (Contd)

• 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 (Contd)

• 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 (Contd)

• 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 (Contd)

• 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 (Contd)

• 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 (Contd)

• 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 (Contd)

• 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 (Contd)Persistent Storage
Service
18
Interface Concept (Contd) 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 (Contd)Example Write
20
Interface Concept (Contd)Example Query
21
Interface Concept (Contd)Publish-Subscribe
Service
22
Interface Concept (Contd)Publish-Subscribe
Service

• Publisherresponsible for data issuance.
• Subscriberresponsible for receiving published
  data and making available to applications.
• DataReaderfacade to subscriber.
• DataWriterfacade to publisher.
• Topicassociates a name, data type and QoS to
  data itself
• Allows subscribers to unambiguously refer to
  publications.
• Datacommon base from which all
  published/subscribed data is derived.
• Domain Participantrepresents the local
  membership of the application in a domain
• A domain conceptually links all publishers and
  subscribers.

23
Interface Concept (Contd)Example Publish
24
Interface Concept (Contd)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