Middleware Requirements

1
The Ship as an Open Architecture Enterprise

• Middleware Requirements
• R. Bernstein / L. Daws
• Lockheed Martin MS2

2
Does This Idea Make Sense?

• Similarities of Ship to Enterprise
• Providing a valuable service at an affordable
  cost
• Depending on efficient information flow
• Customers, partners, suppliers
• Internal operations, information system
  operations
• Comprising stove-piped legacy systems working in
  concert (often with difficulty)
• Pushed by customer and business partners to
  provide better interoperation
• Attempting to keep up with technological change
• Always seeking lower-cost solutions
• Managed for best effectiveness like any other
  system of people and equipment

3
A Warship Is Not A Typical Enterprise

• Employs myriad, open niche technologies
• Mechanical, electrical, communication, computing,
  networking (many built only for military use)
• Military sensors weapons
• Demands a broad range of performance
• Requires some level of high availability
  robustness
• Executes diverse changing missions
• Operates in adverse conditions far from a
  maintenance facility
• Carries people into harms way

4
Ship/Enterprise Common Problems

• Rapidly evolving underlying technology
• HW/System Architectural evolution
• OS Middleware complexity
• Increasing application functional complexity
• Interoperability with unforeseen systems
• Quality of Service (QoS) demands
• Sharp peaks in load
• 24x7 Availability
• Remote troubleshooting correction

A Modern Warship Exhibits These Same Requirements
5
Its an Organic System of Objects

• Radio Comms Links
• Electronic Warfare

Sensors

• Combat Info Center

Weapon Systems
HME Power and Propulsion
Computing Resources

• Crew
• Crew Services

Weapons Stores
Interconnect and Distribution Systems (Power,
Cabling, Water, Data, etc.)
6
Things to Model/Monitor/Control

• Hull, Mechanical Electrical Systems
• Crew Services
• Training
• Office automation
• Computing Resources
• Processing nodes
• Routers, switches
• Storage Media
• Software

• External Sensors
• Radars, Sonars, IFF, EWS
• Weapons
• Guns, Missiles, Torpedoes, Launch Systems
• Communication Gear
• Navigation Equip
• Motion, Depth, GPS
• Time Sources (GPS)

7
Uses of Information Aboard Ship

• Operations
• Safe navigation
• Mission planning execution
• Traffic monitoring (air, surface, subsurface)
• Threat detection, identification, evaluation
• Weapon engagement planning
• Weapon deployment and evaluation
• Readiness Maintenance
• Readiness testing (often online)
• Fault isolation, evaluation, repair
• Training
• Exercise crew in all operational scenarios
• Logging
• Record keeping of normal and combat actions

8
Real-Time Spectrum
Performance of the shipboard functions span
real-time spectrum
9
When Performance is Critical

• Performance Failures
• Control loop closure time not met
• Computer fails
• Network fails
• Consequence if not rectified
• Lose missile or miss target
• Lose ship!!!

• MISSILE CONTROL LOOPS
• Until missile is within self-guidance range
• Take radar measurement of planes position
• Compute missile guidance command
• Send missile guidance command

• While missile is in flight
• Collect missile health status
• Check for acceptable/safe performance
• If performance erroneous
• Destroy missile

System Failures Are Serious
10
Unfolding Future System Architecture Adapted
from DARPA IXO ARMS/PCES BAA Presentation, by
Doug C. Schmidt
The DoD envisions a new generation of embedded
system architectures technologies to
simultaneously control multiple quality of
service (QoS) properties improve software
development quality/productivity
Applications
Applications
Endsystem
Endsystem
11
Future Ship/Enterprise Architecture

• Embedded and Hard-Real-Time capabilities limited
  to small portion of ships architecture
• Number of capabilities are non-real-time in
  nature
• Provide for ease of continual update in war
  fighter capabilities while minimizing need for
  full system-level reintegration certification
• No single level of performance requirements will
  be applied to all shipboard capabilities
• Uniform QoS across real-time spectrum

RT and Non RT Capabilities Must Interoperate
12
Middleware Requirements

• Data centric communications
• Many-to-Many data distribution
• Dynamic association
• Ability to provide receive data anonymously
• Reliable and Unreliable data transmission
• Scalability flexibility
• Security
• Authentication / password / id
• Multi-language support (C/Java)

13
Middleware Requirements (cont)

• Interoperability
• Cross language C / Java / Ada
• CORBA Java / JMS
• Cross vendor
• Deterministic behavior
• Latency while under load
• Resource utilization
• Resource management QoS control
• Access performance statistics and notification of
  state / condition changes

14
Plans / Strategy

• Utilize commercial middleware capabilities
• Apply standards where they exist
• Influence development of new or existing
  standards where they dont exist or inadequately
  address needs
• Leverage Publish / Subscribe design pattern and
  capabilities to support middleware /
  communication needs (i.e OMG DDS)
• Adopt Model Driven Architecture (MDA) UML as
  unifying modeling framework

15
Current Pub / Sub Developments

• Object Management Group
• Data Distribution Service (DDS) for Real-Time
  Systems
• OMG adopted final specification in May 2003
• DDS addresses RT and non-RT market needs
• Products soon to be available (early 2004)
• Following efforts of three vendors RTI, THALES
  Naval Netherlands (Splice), and OIS
• Java Community Process
• Java Messaging Service (JMS)
• Standardized by Java Community Process (JCP)
• JMS addresses commercial and internet markets
• Widely support
• Implemented over existing commercial pub/sub
  products

16
Future Plans

• Conduct market survey / identify vendors and
  products (JMS and DDS)
• Identify products that support both RT and non-RT
  applications
• Assess standards
• Assess user base
• Identify feature / services support (security,
  multi-language support, )
• Evaluation / Performance analysis
• Identify currently available benchmarks define
  and develop new benchmarks
• Work closely with customer
• Possible environments to perform evaluation
  include Solaris, Linux/RT Linux, and LynxOS

17
Future Plans (cont)

• Additional area of investigation includes
  bridging between JMS/Java and DDS
• DDS support for Java
• Cross environment interoperability
• Cross vendor interoperability
• Work with standards organizations, vendors and
  customer
• Evaluation of existing future vendor
  capabilities
• Adherence to existing standards
• Promotion / development of new standards required
  to meet future needs (CORBA MDA)