9LV Mk4. Use of DDS for system integration. June, 2007 Thomas Jungefeldt. Saab Systems

Transcription

1 9LV Mk4 Use of DDS for system integration June, 2007 Thomas Jungefeldt Saab Systems

2 Saab s capabilities Aviation Sensor Systems Electronic Warfare Simulation and Training Support Solutions Weapon Systems Signature Management Command and Control Communication Unmanned Systems Space

3 9LV Ship projects (Mk3e & Mk4) HMS Flyvefisken Denmark HMAS ANZAC Australia Hamina Finland HMNZS Te Kaha New Zeeland HMS Gotland Sweden OHJV Rauma Finland PNS Tariq Pakistan Ban Yas Class UAE HMS Göteborg Sweden HMS Stockholm Sweden HMS Absalom Denmark RNO Al Bushra Oman HMS Skjold Norway HMS Niels Juel Denmark Visby Class Sweden

4 Simple Naval CMS

5 Important Customer requirements Adaptable to new threats. Adaptable to new tasks. Affordable. Advanced functions. Best of breed.

6 Architectural goals Open Architecture / Open Standards Standards that are widely used, consensus based, published and maintained by recognized industry standards organizations (The Open Systems Joint Force, US DoD). Service oriented Support modular system design with low coupling High degree of runtime configuration Rapid integration. Reuse across platforms and domains. Leverage civil investments. Easy to upgrade (functionality and performance) Rapid capability insertion Rapid technology insertion. Facilitate cooperation and competition (open market).

7 Mk4 approach to OA Comply with defined standards Apply modular design and low coupling. Apply design patterns to isolate areas where standards are missing Use existing SW (Mk3e or COTS) in these areas Await standards Define and publish key interfaces using open standards and a formal semantic/syntactic model. To ensure openness / flexibility. To enable use of MDD. To enable runtime configuration / consistency check. Apply design patterns with plug-able translators (data brokers) between data models Used well established concepts (e.g. j-messages) as a basis for information models

8 Interface management Key interfaces should be identified. Put under control early in the system life cycle. Characteristic of key interfaces: Common boundaries between system modules. Provide access to critical data, information, services. Key interfaces are defined syntactic and semantically (information model) using standardized formal language (e.g OWL).

9 Modular design principles Self containment Cohesiveness Encapsulation High binding Fully Mk4 Compliant Module Data P-S Status P-S Ctrl R-R I/F Spec R-R

10 Typical Modules Sensor (e.g. radar, sonar) (control). Director Missile (e.g. SSM, SAM) control. Platform sensor control Gun control. C3 functions Data link processor (I/f) DFE (Data Fusion Engine). ADC (Air Defense coordination). MTD (Main Tactical Display). JMTB (Java MMI Tool Box). General Services. Etc.

11 9LV Modular System Structure Flexibility in configuration Low project risk Enables incremental system growth

12 Basic System building blocks COE Common operating Environment. Enterprise Bus. Functional Modules. Functional Module Enterprise bus Functional Module HW+OS Middleware Programming Language COE HW+OS Middleware Programming Language COE

13 Common operating environment An virtual execution environment for applications. Defined by open standards (IEEE, IETF, ANSI). Stable over time. Enables: Reuse / portability of modules. Heterogeneous systems. Rapid technology insertion. Enhance life-cycle supportability. Mitigate the risks associated with technology obsolescence. Mitigate the risk of a single source of supply over the life of a system.

14 Enterprise bus Provides the information highway that interconnects the modules in the system. Built on Publish-Subscribe (OMG DDS). All interfaces are defined in standardized formal languages. All interface definitions are available online in the system. Four distinct classes of interface are supported: Business data (publish-subscribe). Control (request-response). Status / State (publish-subscribe). Interface specifications (request-response). Enables NCW and rapid capability insertion

15 A P P L I C A T I O N IP Network A d a p t o r A p p l i c a t i o n COE A d a p t o r Enterprise BUS (Middleware) M F C COE COE COE G e n e r a l S e r v i c e s W e b s e r v i c e s Enabling easy integration

16 Design guidelines Use DDS features as much as possible Use Content Based Addressing when possible (for group addressing) Use DDS Instances to differentiate between object of same class Limit number of topics Design messages with placeholders for extensions Specialize / extend messages though XML part Use partitions to isolate subsystems internals Use domains to create virtual systems e.g. for mixed mode simulation

17 Design guidelines cont. No special provisions for HMI Avoid complex protocols on top of DDS Use stateless interfaces whenever possible Design for general case and specialize Model request-response on to of DDS Start with model and include requirements Generate artifacts from model

18 Model driven development A single high level information model is used to generate Interface specifications Interface code XML descriptions of services UML models IDL Test code

19 Experiences Pros Good set of features Facilitates low coupling Facilitates interface specifications Facilitates integration Cons IDL has limited expressional power for interface contract Poor IDL support for versioning and backward compatible extensions Null values not supported Transition from message to data centric thinking is sometimes hard

20 ?