1

An Approach to Intra-Vehicular Data Registration and Management

Presented by

Mr. William PritchettDCS Corporation

1330 Braddock PlaceAlexandria, VA 22302

wpritche@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.

Map DisplayAnd

Presentation

TerrainServices

AutonomousMobility

MMU

DataLoader

DataLoader

DataLoader

Vector/Raster DataDTED DataFeature Data

Vector/Raster DataDTED DataFeature Data

Vector/Raster DataDTED DataFeature Data

4

Background (Cont’d)

• Need– Common architectural approach to populate,

disseminate, and distribute commonly used/interpreted system data in an implementation independent manner.

Map DisplayAnd

Presentation

TerrainServices

AutonomousMobility

MMU

DataLoader

Vector/Raster DataDTED DataFeature Data

DataRegistration

and Mgmt

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)

Drivers

Hardware

- Common Support Apps- Common Support Apps - System Services- System Services - Resource Access Services- Resource Access Services - Physical Resources- Physical Resources

Controls and Displays

SpeechRec

API

EmbeddedGraphics A

PIGraphics

EngineOpenGL X

DisplayMgmt

API

Inp DevMgmt

API

3DAudio

API

Controls and Displays

SpeechRec

API

SpeechRec

API

EmbeddedGraphics A

PIGraphics

EngineOpenGL X

EmbeddedGraphics A

PIGraphics

EngineOpenGL X

DisplayMgmt

API

DisplayMgmt

API

Inp DevMgmt

API

Inp DevMgmt

API

3DAudio

API

3DAudio

API

OperatingEnvironment A

PIRTOSPOSIX OSEK

Data Control and DistributionData Registration

& ManagementData

Engine

API

? ?

OperatingEnvironment A

PIRTOSPOSIX OSEK

OperatingEnvironment A

PIRTOSPOSIX OSEK

Data Control and DistributionData Registration

& ManagementData

Engine

API

? ?

Power MgmtPowerMgmt

API

Power MgmtPowerMgmt

API

PowerMgmt

API

Computing and Knowledge ResourcesStationMgmt

API

Inst API

Diag API

Computing and Knowledge ResourcesStationMgmt

API

StationMgmt

API

Inst API

Inst API

Diag API

Diag API

ThreatMgmt

API

Survivability

SurvDec Aid

API

ArmorMgmt

API

SignatureMgmt

API

CMMgmt

API

CrewProtect

API

ThreatMgmt

API

ThreatMgmt

API

Survivability

SurvDec Aid

API

SurvDec Aid

API

ArmorMgmt

API

ArmorMgmt

API

SignatureMgmt

API

SignatureMgmt

API

CMMgmt

API

CMMgmt

API

CrewProtect

API

CrewProtect

API

TerrainServices

API

TerrainServices

API

MappingServices

API

MappingServices

API

SharedServices

SAServices

API

SAServices

API

Dec AidServices

API

Dec AidServices

API

Virt EnvServices

API

Virt EnvServices

API

Mobility

AutNavDec Aid

API

LocalizeServices

API

PropMgmt

API

AutoMgmt

API

AuxAuto

API

Pos/Nav API

Mobility

AutNavDec Aid

API

AutNavDec Aid

API

LocalizeServices

API

LocalizeServices

API

PropMgmt

API

PropMgmt

API

AutoMgmt

API

AutoMgmt

API

AuxAuto

API

AuxAuto

API

Pos/Nav API

Pos/Nav API

DistFires

API

Lethality

FiresMgmt

API

BallisticKernel

API

LauncherMgmt

API

MunitionMgmt

API

TargetMgmt

API

FCDec Aid

API

TargetSensing

API

DistFires

API

DistFires

API

Lethality

FiresMgmt

API

FiresMgmt

API

BallisticKernel

API

BallisticKernel

API

LauncherMgmt

API

LauncherMgmt

API

MunitionMgmt

API

MunitionMgmt

API

TargetMgmt

API

TargetMgmt

API

FCDec Aid

API

FCDec Aid

API

TargetSensing

API

TargetSensing

API

ISR

SurvMgmt

API

IntelMgmt

API

ReconMgmt

API

ISRDec Aid

API

ISR

SurvMgmt

API

SurvMgmt

API

IntelMgmt

API

IntelMgmt

API

ReconMgmt

API

ReconMgmt

API

ISRDec Aid

API

ISRDec Aid

API

C3

TacticalC3

API

C3Dec Aid

API

BattlefieldVis

API

MissionMgmt

API

C3

TacticalC3

API

TacticalC3

API

C3Dec Aid

API

C3Dec Aid

API

BattlefieldVis

API

BattlefieldVis

API

MissionMgmt

API

MissionMgmt

API

RoboticAccess

API

RoboticAccess

API

SMIToolkit

API

SMIToolkit

API

IETMs API

MissionRehearsal

API

Training API

EngServices

API

Service &Support

T&E API

IETMs API

IETMs API

MissionRehearsal

API

MissionRehearsal

API

Training API

Training API

EngServices

API

EngServices

API

Service &Support

T&E API

T&E API

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

Publish Subscribe Services

Persistent Storage Services

17

Interface Concept (Cont’d)Persistent Storage Service

PersistenceManagerFactory

getPersistenceManager() : PersistenceManager

Query

close()execute()declareParameters()declareVariables()setOrdering()

Collection

add()clear()getIterator()isEmpty ()remov e()contains()size()toArray ()equals()

+returns

PersistenceManager

close()getExtent() : ExtentisClosed() : BooleannewQuery () : QuerymakePersistent()currentTransaction() : Transaction

+creates +returns

Iterator

hasNext() : BooleangetNext() : PersistentDataremov e()

+nav igates ov er

PersistentData

0..*0..*

Extent

close()closeAll()getCandidateClass() : PersistentDatagetPersistenceManager() : PersistenceManagerhasSubclasses() : Booleaniterator() : Iterator

+returns

+nav igates ov er

0..*0..*

Transaction

start()commit()rollback()isActive()

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

App : PersistenceManagerFactory

: PersistenceManager

: Track : Transaction

getPersistenceManager( )

currentTransaction( )

makePersistent( )

start( )

Initialize( )

commit( )

20

Interface Concept (Cont’d)Example Query

App : PersistenceManagerFactory

: PersistenceManager

: Query : Collection : Iterator

getPers istenceManager( )

getExtent( )

newQuery( )

execute( )

getIterator( )

hasNext( )

getNext( )

close( )

21

Interface Concept (Cont’d)Publish-Subscribe Service

Publisher

create_datawriter()enable()

Subscriber

create_datareader()enable()

DataWriter

write()dispose()enable()

**

Topic

createAction()enable()

1

*

1

* DataReader

enable()create_readcondition()read_w_condition()

**

*

*

*

*

Data

Domain Participant

create_publisher()create_subscriber()create_topic()

Pub Sub Item

**

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

: DataWriter : Publisher : Topic : Domain Participant

App

create_publisher( )

enable( )

create_topic( )

enable( )

create_datawriter( )

enable( )

write( )

24

Interface Concept (Cont’d)Example Subscribe

: WaitSet : ReadCondition

: DataReader : Subscriber : Domain Participant

create_subscriber( )

enable( )

create_datareader( )

enable( )

create_readcondition( )

attach_condition( )

wait( )

read_w_condition( )

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