유니버설미들웨어를 적용한 AP는 위성시스템 체계종합에서 분류한 단위모듈을 기준으로 Bundle Context간의 상호작용 프로세스를 기초로 한다. 이때 객체인 Bundle Context에서 Interface를 XML로 가상화하여 실행주체인 Activator로 동작시킨다. 유니버설미들웨어상의 Bundle Context와 Activator는 이기종 시스템간의 확장성을 제공하고 위성개발의 복잡한 시스템체계를 사용자 중심의 개념별 Layer로 분리할 수 있다. 하드웨어 Layer에서 드라이버를 Bundle Context화하여 재활용 할 수 있다.

Activator는 응용서비스의 조합과 융합방식으로는 구성한 시스템인터페이스, 통신프로토콜의 표준화와 모듈화의 실행 주체이다[5]. 즉, 시스템인터페이스와 통신 프로토콜을 동적으로 모듈화 하는 방식의 가상화가 가능하다. 이 과정에서 위성시스템 내부의 표준인터페이스를 Message로 처리하면 모듈화가 용이하다. Message 처리방식은 AP상에서 외부의 응용서비스와 통신 프로토콜간의 전송 과정에서 외부시스템의 모듈과 상호 공유한다.

<그림 1>은 Dynamic Module로 동작하는 공유모듈인 Shared Module간의 상호작용을 나타내고 있다. AP상의 공유 형태에 따라서 내부 및 외부의 Application을 통합할 때 필요한 서비스 명세서 규칙을 3^rd Party와의 규칙을 정의하고 처리방식을 설계해야 한다. 관련하여 <표 1>에서는 위성서비스에 적용한 명세서의 사례로 AP에 영향을 미치는 주요 파라미터들이다.

이 명세서를 서비스모듈에 탑재하기 위해서는 응용서비스 관리가 필요하다. Application Launcher는 표준서비스와 인터페이스를 통해 관리와 추적을 수행한다. Bundle Context에 등록된 저장소인 Registry 정보를 참조하여 Tracker와[6] 내부인터페이스의 명령어 송수신 Commander와 모듈의 자원관리 정보를 제공한다.

이 Tracker 모듈은 AP에서 Tracking 기능으로 전체시스템의 하드웨어와 서비스 모듈의 이력을 알 수 있다. 이를 응용하면 모듈에 구성된 부품의 도입 과정 뿐만 아니라 개발모듈의 연관성, 단계별 테스트 정보, 위성 발사 과정의 데이터 취득정보를 알 수 있다[7].

<그림 2>는 응용서비스를 탑재한 AP인 SAP는 기초적인 툴로 구현하여 적용한 실행화면을 나타내고 있다.

SAP는 향후 수요자의 요구 서비스의 사례를 발굴하여 테스트하고 평가할 있도록 구성한 프로그램이다. 수요자 요구서비스 발굴은 플랫폼상의 Service Registry에 등록된 정보에 따른 Bundle Context의 시스템 자원을 재활용 할 수 있도록 서비스를 깨우거나 중지시키는 방식에 기초를 두고있다.

위성사전개발과 발사 후 운영을 위한 데이터 분석의 경우 표준화 모듈인 Dynamic Module과 Instance를 공유한 Shared Module로 이기종간의 동적 자원을 공유하며 유기적으로 처리할 수 있다[8]. <그림 3>에서는 동적 모듈의 Instance에 대한 Registry, Inventory의 상호작용을 나타내고 있다.이 구조는 위성 내부 하드웨어 모듈과 응용서비스를 구성하는데 필요하다.

Dynamic Module의 상호작용으로 서비스의 Register, Connection, Find & Install과 Share & Management로 모듈의 연관성을 부여한 Activator 서비스를 적용할 수 있다.

또, Dynamic Module은 유니버설미들웨어에서 동작하는 기본 단위로서 그 기능은 Service Registry와 해당 Registry에 등록된 서비스를 분류하게 된다. Registry에 축적된 서비스목록은 Inventory간의 시나리오 기반의 상호작용 정책의 정의에 필요하다. 새로운 채널을 개패하고, Inventory 분류를 위해 XML을 통해 외부시스템과의 채널 개패방식을 정리하여 하드웨어기기와 모듈간의 Instance를 공유한다.

모듈 Instance는 Private Interface방식의 하나인 Private Message로 Application Launcher를 동작 정책에 표준화된 GUI Application 확인을 위한 Tracker와 Commander를 제공한다. AP에 탑재된 대상에게 Resource 변경사항을 적용할 수 있도록 처리한다. Event Handler^*와 Tracking Agent는 Mark Up Language에 작성된 명세서를 참조하여 서비스를 공급한다.

이러한 방식으로 복잡한 하드웨어설계과정과 성능테스트, 개발단계별로 다른 환경에서 수행되는 실시간 시뮬레이션, 인터페이스 적용결과, 시스템의 통합과 모듈의 확장성을 제공하여 개발과 운영과정에서의 효율성을 증가시킨다. 또한, 운영목적에 따른 구현 방법은 유니버설 미들웨어상의 동적모듈인 API^** 설계를 통해 개발 자원의 배포와 중복사용을 제거하고 시스템자원을 재활용할 수 있다.

결과적으로 동적서비스모듈화와 공유모듈설계 요구사항을 다음과 같이 정리할 수 있다. 첫째, 위성시스템의 다양한 하드웨어기반의 Interface들을 표준화하고 Protocol을 배포 가능한 단위모듈로 설계하여야 한다. 둘째, 위성시스템에서 제공하는 기존의 기능에 대해 유니버설미들웨어의생명주기 형태로 동적모듈 각각의 Instance에 적용요소를 서비스목적에 따라 분류하여야 한다.

Dynamic Application Platform(이하, DAP)는 동적모듈의 서비스 순환구조와 공유모듈의 재사용 프로세스와 시스템을 지원한다. 이때 시스템의 안정성 보장을 위해서 Application Instance별로 Thread 기반의 Concurrent Evaluation으로 측정하여 검증하였다. 시스템 측정범위는 CPU, Memory, Swap영역인 로컬 Storage System모듈과 DAP에서 동작하는 서비스 모듈이 존재하는 네트워크 Inventory 영역을 대상으로 구분하여 측정한다. 이때 AP의 Use-Case별로 Workload와 TPS^* 측정값의 변화를 고려하여 시스템을 설계한다.

시스템 변수에 앞서 설계한 Private Message 모듈과 Public Protocol 모듈을 적용할 경우에 안정성을 평가하여 설계에서 반영한다[9-10].

다음으로 위성시스템의 운용과 분석단계에서 필요한 다수서비스의 시나리오 연계에 대핸 DAP의 상태를 측정하였다.

<그림 4>에서는 서로 다른 이기종의 하드웨어 기기를 구성할 경우를 가정하여 Private Message로 Java에서 지원하는 Remote Method Invocation으로 실행한 화면이다. Private Interface의 각각 다른 Bundle Context간에 Message를 전송하여 수신확인 과정을 구현하고 측정한 결과를 각각 나타내고 있다.

<표 2>에서는 Private Message를 적용한 내부 Application에서 Message를 처리하여 로그와 JMeter로 측정한 번들의 결과를 나타내고 있다.

Application Launcher에서 GUI Tracker의 TPS Load 계산식은 (1)에서 나타내고 있다. 이 식에서 NL^**, ReqDuration^***, RespTime^****으로 TPS Workload의 예상 TPS와 실행 TPS값을 비교 제시하고 있다.

Dynamic Module의 경우에는 응답시간에 따라 호출간격을 제어해야 하며 (2)와 같이 Think Time을 가변적으로 적용한다. 호출간격은 절댓값을 산정하여 측정하는데 기준시간에 대한 임의지정상수인 30을 ReqDuration로 지정하였다.

결과적으로 식(1)과 (2)를 토대로 <표 2>의 데이터를 참고하여 ReqDuration을 기준으로 Run AP Preview에서의 Run Application Time을 추가한 값을 계산한다. 따라서, TPS는 (3)에서와 같이 62.5가 된다.

<그림 5>와 <표 3>은 Private Message를 적용한 Application Commander방식의 공유모듈 실행 측정 결과를 나타내고 있다. 또한, <표 3>의 데이터 TPS는 (4)에서 52.6 TPS로 측정되었다.

외부 AP와 연동은 위성시스템의 서비스에서 제공하는 데이터의 정확성과 분석단계의 복잡성으로 구분하였다. 외부에서 제공하는 취득데이터를 실시간으로 해석하고 분석단계와 직접 적용할 경우 개발시간을 단축할 수 있다. 또, 데이터의 해석결과에 대해 다수의 응용서비스를 대상으로 모델링하고 비교한다면 분석 결과의 정확성을 향상시킬 수있다. OnTology^*와 연계할 경우 외부시스템을 네트워크로 연동하여 분석하는데 효과적이다. 이는 DAP의 모듈과 Instance를 선택적으로 운영할 수 있다는 점이 중요하다[11].

외부시스템 구성은 다양한 자원을 공급하고 다수의 사용자가 서비스를 요구할 경우에 대응할 수 있는 시스템으로 발전할 수 있다. 그 사례로 SAR^*의 영상데이터 분석, 천문데이터, 우주의 관측데이터로 제3의 클라우드 서버와 실시간 연동으로 결과물의 신뢰성과 시간을 절약할 수 있다[12]. 데이터 맵과 형태와 구성법은 요구정보에 대해 데이터 교환규칙을 정의하여 Dynamic Web 3.0기반의 XML을 통해 외부서버의 Module과 연동하는 방식이다.

<그림 6>과 식(5)에서는 제3의 외부시스템으로부터 연동할 수 있는 Application을 로드하여 연동대상이 되는 서버의 Bundle Context 목록을 나타내고 있다. <표 4>에서는 선택된 Bundle Context에 대한 네트워크 트래픽처리와 TPS 사용자원 측정결과를 나타내고 있다.

<표 5>는 서론에 제시한 DAP으로 설계할 경우에 적용모듈에 대한 파라미터이다. 앞서 설명했던 Public Protocol을 사용한 <표 1>의 서비스 명세서 이면서 파라미터의 고려사항을 나타내고 있다.

그 외에도 Private Interface방식을 활용하여 지원하는 ACME^** 커맨드를 통해 커널 시스템 내부의 명령어와 Application을 관리하도록 하여 시스템의 안정성을 제공하였다[13].

결과적으로 External Application System 구성을 위한 위성서비스 설계의 시스템요구조건은 Plug-In Command Type을 n×NoMsg.의 선형조건으로 나타낼 수 있다. 이에 대한 시스템자원의 안정성은 52.6 TPS를 기준으로 내부시스템인 Internal Application Type에 대해 n×NoInt.으로 추측할 수 있다.

즉, 식(6)에서 시스템자원의 Workload는 62.5 TPS를 기준으로 Dynamic Service Platform에 대해 External Application Type은 n×No.Pcl.으로 계산할 수 있다. 이 조건을 토대로 파라미터를 적용하지 않을 경우에 비해 선형모델링 Traffic 비용으로 AP를 구성할 경우 n×NoInt.대비 n×No.Pcl.에 대해 0.09로 예측하여 기존 시스템 구축 자원을 재활용 하여 설계할 수 있다[14].