Dynamic Reconfigurable Integrated Management and Monitoring System for Naval Ship Combat Management System Bup-Ki Min', Hyeon Soo Kim', Seunghak Kuk 2,

Slides:



Advertisements
Similar presentations
1 Aspects of IEEE P1471 Viewpoints in Unified Modeling Language (UML) Manzur Ashraf, BRAC University Humayra Binte Ali, Dhaka University Md.Mahfuz Ashraf,
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design 1.
Chapter 2 Software Processes (1/2) Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
SWE Introduction to Software Engineering
Network Management Overview IACT 918 July 2004 Gene Awyzio SITACS University of Wollongong.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Unit 231 Software Engineering Introduction to SWE What is SDLC Phases of SDLC.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Rheeve: A Plug-n-Play Peer- to-Peer Computing Platform Wang-kee Poon and Jiannong Cao Department of Computing, The Hong Kong Polytechnic University ICDCSW.
CORBA Case Study By Jeffrey Oliver March March 17, 2003CORBA Case Study by J. T. Oliver2 History The CORBA (Common Object Request Broker Architecture)
1 ITC242 – Introduction to Data Communications Week 12 Topic 18 Chapter 19 Network Management.
Unit 191 Introduction to Software Engineering The objective of this section is to introduce the subject of software engineering. When you have read this.
© Copyright Eliyahu Brutman Programming Techniques Course.
Lecture Nine Database Planning, Design, and Administration
Course Instructor: Aisha Azeem
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
Status on Coexistence proposals Antonio de la Oliva UC3M.
Chapter 10 Architectural Design
Research on cloud computing application in the peer-to-peer based video-on-demand systems Speaker : 吳靖緯 MA0G rd International Workshop.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Chapter 9 Database Planning, Design, and Administration Sungchul Hong.
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
 Cloud computing  Workflow  Workflow lifecycle  Workflow design  Workflow tools : xcp, eucalyptus, open nebula.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
Lecture 2 TCP/IP Protocol Suite Reference: TCP/IP Protocol Suite, 4 th Edition (chapter 2) 1.
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
Web services: Why and How OOPSLA 2001 F. Curbera, W.Nagy, S.Weerawarana Nclab, Jungsook Kim.
Agent-based Device Management in RFID Middleware Author : Zehao Liu, Fagui Liu, Kai Lin Reporter :郭瓊雯.
An Introduction to Software Architecture
Software Architecture Framework for Ubiquitous Computing Divya ChanneGowda Athrey Joshi.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Chapter 14 Part II: Architectural Adaptation BY: AARON MCKAY.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Chapter 6 Architectural Design.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
SCALABLE EVOLUTION OF HIGHLY AVAILABLE SYSTEMS BY ABHISHEK ASOKAN 8/6/2004.
Summary of Distributed Computing Security Yifeng Zou Georgia State University
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
Framework for MDO Studies Amitay Isaacs Center for Aerospace System Design and Engineering IIT Bombay.
Information Technology Needs and Trends in the Electric Power Business Mladen Kezunovic Texas A&M University PS ERC Industrial Advisory Board Meeting December.
8:15 AM Tuesday September 15, 2009 Karl Frank, Point of Contact for Constellation Projects Validating Integration Requirements Diagrams for illustrative.
Distributed database system
CSC480 Software Engineering Lecture 10 September 25, 2002.
O.C.E.A.N Open Computation Exchange and Auctioning Network.
Integration of Workflow and Agent Technology for Business Process Management Yuhong Yan. Maamar, Z. Weiming Shen Enterprise Integration Lab.Toronto Univ.Canada.
Design of On-Demand Analysis for Cloud Service Configuration using Related-Annotation Hyogun Yoon', Hanku Lee' 2 `, ' Center for Social Media Cloud Computing,
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Essential Customization for Moodle Adoption in School Jeong Ah Kim', SunKyun Park 1 ' 2 Computer Education Department, Kwandong University, KOREA
A Framework with Behavior-Based Identification and PnP Supporting Architecture for Task Cooperation of Networked Mobile Robots Joo-Hyung Kiml, Yong-Guk.
Advanced Science and Technology Letters Vol.46 (Mobile and Wireless 2014), pp University Dedicated Next.
Providing web services to mobile users: The architecture design of an m-service portal Minder Chen - Dongsong Zhang - Lina Zhou Presented by: Juan M. Cubillos.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
ISC321 Database Systems I Chapter 2: Overview of Database Languages and Architectures Fall 2015 Dr. Abdullah Almutairi.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Distributed Systems Architectures Chapter 12. Objectives  To explain the advantages and disadvantages of different distributed systems architectures.
Design Review.
The Improvement of PaaS Platform ZENG Shu-Qing, Xu Jie-Bin 2010 First International Conference on Networking and Distributed Computing SQUARE.
Storage Virtualization
Model-Driven Analysis Frameworks for Embedded Systems
Design and Implementation
واسط كاربري هوشمند Intelligent User Interface
Design.
From Use Cases to Implementation
Presentation transcript:

Dynamic Reconfigurable Integrated Management and Monitoring System for Naval Ship Combat Management System Bup-Ki Min', Hyeon Soo Kim', Seunghak Kuk 2, Chumsu Kim 2 1 Dept. of Computer Sc. & Eng. Chungnam National University {bkmin, 2 Agency for Defense Development {shkuk, Abstract. In the existing naval combat system, management work is done inde- pendently on subsystems that make up the whole system. Since, however, the naval combat system is a large-scale distributed system made up of subsystems on the diverse heterogeneous environments, it is extremely difficult to integrate and manage as a single entity all subsystems. Therefore a new method is re-quired to manage effectively all subsystems. The new method should consider characteristics such as the heterogeneous environments, distributed systems, dynamic changes to the system configuration, and so on. In this paper, the ar-chitecture of an integrated management system is designed and implemented. The system provides various services to control and monitor each of subsystems. Furthermore, the system has capabilities that can construct the configuration of the system dynamically. 1 Introduction The naval combat system is an automated combat system with integrated command and armament features, designed to provide optimal combat capabilities. The naval combat system is made up of various subsystems, each of which is responsible for performing different functions, including detection, control, and combat. The overall functionality of the system is given by the combination of the functionalities of these subsystems [1]. However, subsystems of the naval combat system may be inde- pendently developed by different companies. In this case, management of these sub- systems has to be dependent on the particular implementation. Therefore, each sub- system had to have its own management system, different from the rest. For a single environment system, it would be easy to integrate the subsystems or manage them in an integrated way. It is, however, not easy to do so for the naval combat system, as it is made up of heterogeneous subsystems. Therefore, a method is needed to effectively maintain and manage data generated in subsystems of the naval combat system (made up of heterogeneous systems in a distributed environment) under a single integrated management system. In this paper, architecture of the integrated management and monitoring system is defined using information models and a layered way. The sys- Session4A403

tern provides various services to the user to control and monitor each of subsystems. Furthermore, the system has capabilities that can accept dynamic changes to the con- figuration of the naval combat system. 2 Related Work Research on a system that manages all subsystems of a naval combat system in an integrated way has just recently got underway. Past management systems for a naval combat system managed each of subsystems independently. They could not show all subsystems in a single integrated way [2]. The paper [3] proposes a monitoring method for P2P-based distributed systems. In this paper, monitoring is done in the following way: a system called P2PMonitor is implemented and a module called Alerters is added to each subsystem so that the generated events are delivered to P2PMonitor. Note that in this paper, monitoring is done only on P2P applications that actually exist in the host. As the size of the system gets bigger and as the number of applications that need to be managed in a single host increase, Alerter needs to be extended. Moreover, there isn't a method proposed for management or monitoring in the case that applications are added in heterogeneous environments other than the P2P system. The paper [4] proposes an integration meth- od and a control mechanism for heterogeneous distributed systems. In the paper, poli- cies for assembling various heterogeneous distributed systems are proposed, as well as a control delivery method called Law-Governed Interaction. Although the paper [4] focuses on system integration, our paper places the focus on both system integration and management. To this end, integrated management based on information models is performed. 3 Necessity of Integrated Management System for Naval Combat System Combat systems installed on ships are huge and assembled on a variety of computing platforms. Research on management techniques and system monitoring for deploying and controlling countless applications to be used in a combat system, made up of hundreds to thousands of pieces of equipment, is still in early stages. In this paper an integrated management system based on information models is developed. The use of information models allows collection and maintenance of data from diverse subsys- tems that make up the naval combat system. Furthermore, the data are combined via services of various types. 4 Information Model The integrated management system for the naval combat system proposed in this paper performs controlling and monitoring based on information models, which ex- 404 Computers, NetWorks, Systems, and Industrial Appications

tract only the independently needed data regardless of the hardware platform or the type of software. IMMS-CMS Fig. 1. Mapping between the Information Model and the Actual System Fig. 1 shows the mapping between the information model and the system hardware and the running software being managed. Information models of the integrated man- agement system are made up of the following: Application Model, which contains information of the actually running process; Application Specification Model, which contains information of applications that are not running; Hardware Information Model, which contains hardware information; and Application Deployment Model, which contains deployment information about on which hardware the application is running. Based on these pieces of information, information on the entire hardware and software running on the naval combat system can be maintained and managed. 5 IMMS-CMS As the purpose of the integrated management system for the naval combat system implemented in this paper is the management and monitoring of subsystems that make up the naval combat system, it is called IMMS-CMS (Integrated Management and Monitoring System for Combat Management System). 5.1 IMMS-CMS System Architecture In this chapter, the architecture for the implementation of IMMS-CMS is proposed (see Fig. 2). The architecture was designed in a way suitable for managing multiple systems that exist in diverse distributed environments under a single system. To this end IMMS- CMS is made up of different layers, each responsible for a specific kind of task. In addition, various services were made that use information models, so that services can be provided to the user in an effective way. The client layer is where various services are provided to the user from the IMMS-CMS. In the service layer, various pieces of information about diverse software and hardware are provided to the user in the form of services. In the management layer, software and hardware systems managed by the IMMS-CMS are managed in a substantial way. The information model layer maintains information of hardware and software systems managed by the Session 4A 405

IMMS-CMS. This layer is realized by the information model stated in Section 4. The communication layer provides communication functions with the host computer being managed. Using various communication methods according to the type of the inter- face of the communication layer, control and monitoring data are exchanged between the IMMS-CMS and the host. User Interface Module Client Application Service Layer Fig. 2. IMMS-CMS System Architecture 5.2 Information Model Construction Scenario for IMMS-CMS The IMMS-CMS builds the information model using the hardware specification and the application specification received from the host computers. Those specifications can be changed due to the situation of the participating hardware and/or applications. When receiving the specifications from the hosts, the configuration manager cre- ates/deletes/updates some classes related to the specifications and adjusts the relation- ships between the changed classes and the affected classes in the information model dynamically. Construction method of the information model is as follow: 1-3: When the host starts, it sends a discovery message to IMMS because it wants to register itself and applications deployed on itself. Once it receives the response mes- sage from IMMS, it sends the hardware specification and the application specification to IMMS. 4: At first, the IMMS builds the entire information model according to the received specification. The next time, however, it creates, deletes, or updates some parts in the information model and incorporates those changes into the model. 5-7: The IMMS generates some classes which keep the static information and the dynamic information about the host. If those classes are created successfully, these changes should be reflected to the user interface, too. 8-13: The sequences show the construction processes of the information model for applications deployed on the host. Information Model La er Application Logical H/W Information Model Model Component ystem opo ogres pp 'cation Querying Service Control Service System Application Monitoring Service Information Service Management Layer,-. SiVi System Management Logical HAN Mango wet LW Logging — Monde Module Module : 406 Computers, Networks, Systems, and Industrial Appications

Ikarinterfara goss karailscaex rnnflosA.Manzoer P.45, 49nhrfnen Host.delnterfan. Fig. 3. Sequence Diagram for Constructing Information Model 6 Conclusions As the size of the naval combat system gets bigger and as a number of subsystems are installed, it is increasingly becoming more important to manage each of the subsys- tems in an integrated way. Such a large-scale naval combat system is not made up of a single system but rather of various heterogeneous subsystems. Therefore, a standard- ized integrated management system is needed to effectively manage them. In this paper, an integrated management system for the naval combat system is implemented, called IMMS-CMS, which uses information models for hardware and software being managed in the naval combat system. As the information models are managed in a way independent of the actual system, they are not affected by heterogeneous envi- ronments and an integrated management can be done for all subsystems in the naval combat system. Acknowledgement This research was supported by Agency for Defense Development. (Contract No. UD090017KD) References 1.Cihat Eryigit, A. S Uyar, "Integrating Agents into Data-Centric Naval Combat Manage- ment Systems", 23rd International Symposium on Computer and Information Sciences, pp.1-4, OMG, "Application Management and System Monitoring for CMS Systems", Serge Abiteboul, Bogdan Marinoiu, Pierre Bourhis, "Distributed Monitoring of Peer-to-Peer Systems", International Conference on Data Engineering, Naftaly H. Minsky, Victoria Ungureanu, "Law-Governed Interaction: A Coordination and Control Mechanism for Heterogeneous Distributed System", ACM Transactions on Soft-ware Engineering and Methodology, Vol.9, pp , 2000 Session 4A 407