Distributed Application Development in CORBA in ISHM

1
Distributed Application Development in CORBAin
ISHM

• Sathya Bandari
• Mar 31, 2005

2
Table of Contents

• ISHM
• Goals of ISHM Systems
• Health Management Technology
• Highly Integrated System Components
• Tri-Reasoner Integrated Vehicle Health Management
  System
• Distributed and Heterogeneous Computing
• CORBA Features
• CORBA Success stories
• ISHM and CORBA
• G2 and CORBA
• Summary
• References
• Q A

3
Goals Of ISHM System

• To detect and understand critical failures early
  enough to respond and avoid the most serious
  consequences
• To reduce the activity required of Mission
  Control Center
• To reduce the vehicle house-keeping by flight
  crews
• To reduce the amount of training
• To streamline the ground processing

4
Health Management Technology

• Flight-critical failure detection and
  annunciation
• Fast real-time detection and diagnosis
• Deterministic diagnosis
• Probabilistic analysis and prognosis
• Up-datable and re-configurable detection,
  diagnosis and prognosis
• System of systems architectures to manage health
  consistently across the program

5
Highly Integrated System Components

• Advanced Smart Sensors
• Diagnostic Prognostic Software for Sensors
• Sub-reasoning Systems
• System level Managers
• Advanced on-board Mission
• Ground based Mission
• Maintenance Planners

6
The Tri-Reasoner Integrated Vehicle Health
Management System
Objective 1.To reduce operational
costs. 2.Increase Performance 3.Organize the
components into an architecture within the
IVHM system
7
Tri-reasoner Algorithms

• Anomaly Detection the mechanism of
  characterizing the basic line performance and
  identifying the deviations from the base line
• It can be off-nominal behavior including
  incipient, intermittent or active.
• A failure event is a sub-category of an anomalous
  event.
• An Active Failure It is off nominal behavior of
  the air vehicle that displays unintended
  functionality.
• Diagnostic Reasoner The function of the air
  vehicle diagnostic system to construct the
  integrated perspective and Isolate the fault
  sources. The algorithm that performs these tasks
  is diagnostic Reasoner.
• Prognostic It is the abilityu to asses the
  current health of a part and predict into the
  future its health for a fixed time horizon
  inorder to perform condition based maintainence
  (CBM).

8
(No Transcript)
9
Generic Representations of Failure Model,Sensors
and HM Technologies
Legend Sensor (S) Anomaly Algorithms (A)
Prognostic Algorithms (P) Diagnostics
Algorithms (D) Failure Mode (FM) Effects
of failure Modes
10
Health State Stakeholders
System health state information is vital for
keeping the crew safe.
System Health State

• Root cause of failure
• Impact of failure
• Precursors to failure
• Critical to failure

Logistic Systems
Informed Flight crew
Mission Planning and Scheduling
Procedure Management system
Informed Mission operations
Vehicle Management System
Ground Operations
11
Component Life

• Component health monitoring system focuses on
• Nominal condition
• Anomaly Condition
• Between two extremes.

Component Life 100 healthy to 100 failed.
12
Prognostic Challenges

• Prognostic Reasoner Concentrates on where the
  component health lies and what fault location
  we are on?
• A Fault Its a known off nominal condition.
• Novel Fault Is unknown
• off nominal condition.

What curve are we on? Where are we on the curve?
13
ISHM Activity Model

• Health State Determination
• Monitor, detect, and isolate faults to
• identify root-cause failures with
• diagnostics and prognostics
• 2. Mitigation
• Assess impact of failures and mitigate
• to minimize impact to mission.
• 3. Repair
• Perform activities to repair failed
• component and return system to nominal
• state.
• 4. Verification
• Perform activities to verify that repair
• Effectively returns system to nominal
• state.

1
2
ISHM system
4
3
14
Distributed and Heterogeneous Computing

• Definition
• The computing network in a single organization
  may consist of different platforms (Unix,
  Windows, Mainframes etc) and different software
  technologies running different applications. But,
  most of these tools/components need to interact
  with each other to perform complex operations.

15
Hidden Complexities

• Inherent Complexity
• 1. Latency
• 2. Reliability
• 3. Partitioning
• 4. Ordering
• 5. Security

• Accidental Complexity
• 1. Low level APIs
• 2.Poor debugging tools
• 3. Algorithmic decomposition
• 4.Continuous re-invention.

16
Enter the CORBA

• CORBAs solution to Distributed computing
  problems
• Simplifies Application Networking Higher level
  integration than un- typed TCP byte-streams.
• Supports Heterogeneity Middleware enables
  application to be independent of transports,
  Operating System, hardware, Language and
  implementation details.
• Similar to Object Oriented Language
  Encapsulation, interface inheritance,
  Polymorphism and exception handling.
• Higher-level Distributed Object Collaboration
  CCM, J2EE and CORBA services

17
CORBA - Introduction

• Enables components to work in a distributed
  system by providing
• Programming Language independence
• Platform independence
• Network transparency
• Architecture transparency

18
CORBA Features

• OMG Interface Definition Language
• Language Mappings
• Operation invocation and dispatch facilities
• Object Adapters
• Inter- ORB protocol

19
Object Management Architecture

• Application Objects These are applicable only to
  a given application. Developed the application
  team.
• CORBAServices These are services available to
  all CORBA applications, these are provided by
  CORBA vendors. Examples Naming Service, Trading
  Service, Life Cycle Service and Event Services
  etc.
• CORBAFacilities These services are applicable
  to a group of applications. E.g. Banking
  Services, HealthCare services etc.

20
Object Model

• Client issues a request.
• The Object replies back upon
• request.
• The client does not care where
  
• the object is - ORB deals with it.
• The client knows what messages it
  can send, because the object has interface
  specified in CORBA IDL

Object
1
2
Client
21
CORBA Architecture

• Stubs are a client-side
• invocation mechanism
• Skeletons are the server-side interface for
  requests.
• CORBA takes care of passing requests from the
  client to wherever the object (server) is
  implemented.
• An object adapter is something that supports
  various styles of object implementations.

22
Stub, Skeleton ORB Network
Client Platform

• Stubs and skeletons are
• intermediate adapter b/w client and Server
  and the ORB.
• Client side generates a
• mapping called STUB
• Server side generates a mapping called
  SKELETON.

Server platform
Server
Client
Stub
Skeleton
ORB
23
CORBA - Remote invocations

• This diagram illustrates communication between
  client and server within a local and different
  ORBs.

24
CORBA - Method invocations
Object1
Object2
ORB1
ORB2
Client1
Stub1
Skeleton1
25
Portable Object Adapter

• Activated object found in the POA s Active
  object map (AOM).
• No AOM or id not in AOM
• Current object knows
• What id is requested.

26
G2 Gateway - Introduction

• G2 Gateway bridge/interface
• To achieve two-way communication between dynamic
  external processes and G2 applications.
• Examples of external systems
• DBMSs, PLCs, SCADA systems
• DCSs, C/C, Java, MATLAB programs, etc.

27
G2 Gateway Application - Components

• G2 Gateway Application Major steps
• Create and Configure G2 KB objects to communicate
  with a bridge processes.
• Create one or more executable Gateway bridges.
• A single G2 KB can communicate with one or more
  bridges
• But, a single G2 KB object can communicate with
  only one bridge.
• A single bridge can communicate with one or more
  G2 KBs

28
Building a G2 Gateway Application

• Create a GSI Interface
• Instance of class gsi-interface
• Edit attribute to specify bridge process
• A GSI interface is created automatically when a
  G2 Gateway bridge initiates a connection to G2 by
  calling the API function gsi_initiate_connection()
  .
• Create a GSI Variable for each data point
• Define a class that includes gsi-data-service as
  one of the super classes
• Create separate instances of above class, one for
  each data point corresponding to external system

29
Building a G2 Gateway Application (continued)

• Create a remote G2 procedure
• Create G2 procedures that the G2 Gateway bridge
  can call as remote procedures.
• Declare each G2 procedure by calling
  gsi_rpc_declare_remote() from G2 Gateway user
  code
• Create a local G2 procedure
• Create a G2 local procedure for each remote
  procedure defined above.
• Declare each local G2 procedure by calling
  gsi_rpc_declare_local() from G2 Gateway user code

30
Building a G2 Gateway Application (continued)

• Create a GSI Message Server
• Define a new class that includes the G2 mixin
  class gsi-message-service as a direct superior
  class.
• To send a text message to the G2 Gateway bridge,
  a G2 KB runs an Inform action on the message
  server.
• G2 Gateway bridge process, you must complete the
  callback gsi_receive_message() to receive the
  message from G2 Gateway user code.

31
Building G2 Gateway Application (Continued)
Creating a bridge

• G2 Gateway libraries of network-oriented API
  functions that can perform following tasks
• Establishing and maintaining the communications
  link
• Receiving requests to send values to data points
  in the external system from the G2 knowledge base
  and calling appropriate user code functions to
  handle the requests.
• Sending data to G2 at the request of the G2
  Gateway user code.

32
Building G2 Gateway Application Creating a
bridge (Continued)

• User code This processes G2 requests and reacts
  to events in external systems.
• User code includes
• gsi_main.h Header file provided by Gensym that
  must be included in all user code files.
• gsi_main.c It is a C source code file provided
  by Gensym containing a sample of the main()
  routine from which G2 Gateway is started. This
  file can be modified to suit application needs.
• gsimmain.c This is a C source code file provided
  by Gensym that performs special initializations
  required only on Windows platforms when building
  a windows application, and then calls the main()
  function that you define in the gsi_main.c file.
• skeleton.c This file contains callback
  functions. G2 Gateway invokes each callback
  function automatically in response to a
  particular network event.

33
Building G2 Gateway Application Creating a
bridge (Continued)

• To build the G2 Gateway bridge executable image
• Complete callback functions in the skeleton.c
  file provided with G2 Gateway.
• Modify or replace the main() routine in the
  gsi_main.c source code file as needed.
• Write and declare G2 Gateway functions that G2
  can call as remote procedures.
• Compile user code and link it with the G2 Gateway
  libraries and with any libraries of external API
  functions required.

34
G2 and CORBA

• To build a CORBA application with G2
• Create one or more CORBA IDL files to describe
  the CORBA interfaces needed by the application.
• Compile the CORBA IDL files into G2 object
  definitions and methods, using the G2 CORBALink
  compiler.
• Write the client and server application logic.
• CORBA support in G2
• g2orb - Provides runtime support for G2
  CORBALink.
• g2idl - Contains the IDL compiler.

35
G2 and CORBA

• Integrate G2 CORBALink by
• Merging the developers knowledge base (KB)
  module, named g2idl, into G2 application. This
  module includes g2orb.
• Making the g2idl and g2orb modules required
  modules of G2 application.

36
Aerospace Application

• The Rockwell Science Center Palo Alto Laboratory
  (RPAL), a branch of the Rockwell Science Center,
  designed Sheet application was a success but they
  were not satisfied by the overall performance of
  their project and looking forward for a
  middleware Architecture that can interface
  different programming languages in their design
  sheet. They work for solving complex systems such
  as aircraft, launch vehicles, and defense
  systems. The application uses constraint
  management techniques, symbolic mathematics and
  robust equation solving capabilities to represent
  conceptual models in the form of mathematical
  equations.
• Solution The Franz Inc.s Allegro ORBlink a
  CORBA conformant LISP ORB was available and
  solved all their problems. The benefit of CORBA
  and Allegro ORBlink benefits the developers to
  choose any programming language that best meets
  the Objectives of the application.

37
Government

• NASA's Goddard Space Flight Center needed a GUI
  system which should work on multiple platforms,
  should be able to communicate with the server via
  Intranet and Internet, and to communicate with
  the server running behind the firewall, and
  maintain high performance for high-load data
  transfer. These requirements forced NASA to
  rethink their system architecture.
• SolutionThe CORBA solution met all the client
  requirements, provided a foundation for a
  platform-independent distributed object
  architecture. It also saved an enormous amount of
  development time. Having settled on a CORBA
  solution, they are in search of emerging CORBA
  vendors

38
Chemical / Petrochemical

• Schlumberger Oilfield Services, one of the
  worlds largest oil service companies. The
  Seismic Reservoir Evaluation segment is itself a
  fully integrated geophysical company
  participating in the global search for oil and
  gas. The Triology system includes navigation
  systems, source emitting systems emitting
  pressure waves into the upper layers of the
  earths crusts and data acquisition and quality
  control systems. It was a necessity to
  communicate all these systems in a reliable
  manner considering performance.
• Solution Schlumberger project composed of shared
  data between several different legacy systems as
  well as with new applications developed from
  scratch. Opting for an object-oriented solution,
  CORBA was the natural choice for the environment,
  which consists of a mix of UNIX workstations and
  PCs with applications written in both C and
  Java .

39
Limitations and Dependency

• Programming language support IDL is a
  "least-common denominator" language. It does not
  fully exploit the capabilities of programming
  languages to which it is mapped, especially where
  the definition of abstract types is concerned.
• Dependencies
• 1.TCP/IP is needed to support the CORBA-defined
  inter-ORB interoperability protocol (IIOP).
• 2. Most commercial CORBA ORBs rely on C as
  the principal client and server programming
  environment. Java-specific ORBs are also
  emerging.

40
References

• OMGs CORBA site - http//www.omg.org/gettingstart
  ed/corbafaq.htm
• CORBA site - http//www.corba.org/index.htm
• Advanced CORBA Programming by Michi Henning and
  Steve Vinoski - Addison-Wesley Professional
  Computing
• http//accl.grc.nasa.gov/IPG/CORBA/NPSS_on_NASA-IP
  G/sld012.htm
• Gensym G2 Gateway Bridge Developers Guide
• Gensym G2 CORBA link users Guide.

41
Question and Answers

• Thank You