Development of Korean UCS Architecture and Service Design for GCS Standardization

GCS 공통화를 위한 한국형 UCS 개발 및 서비스 설계

Abstract

The use of unmanned aerial vehicles is rapidly increasing in order to effectively utilize limited manpower and minimize casualties on the battlefield. The requirements for ground control equipment vary depending on the operating concept and environment of the unmanned aerial system, but there are still common requirements. However, the lack of standardized system configurations to meet these common requirements makes it difficult to reuse common functions, leading to continuous acquisition costs. To solve this problem, this paper develops a Korean version of the UCS model using the UCS architecture. Furthermore, after designing elements related to service development not specified in the architecture (such as framework, communication middleware, service structure, etc.), we develop a Boilerplate to enhance developers' work efficiency based on this. The results of this study will serve as a foundation for effectively and economically carrying out the development of ground control equipment for unmanned aerial systems.

한정된 병력을 효율적으로 활용하고 전장에서의 인명 피해를 최소화하기 위해 무인 항공기의 사용이 급격히 증가하고 있다. 무인 항공 시스템의 운용 개념과 환경에 따라 지상 통제 장비의 요구사항이 달라지지만, 여전히 공통적인 요구사항이 존재한다. 그러나 이러한 공통 요구사항을 만족시키기 위한 시스템 구성이 표준화되지 않아, 공통 기능의 재활용이 어려워져 지속적으로 획득 비용이 발생하는 문제가 있다. 이 문제를 해결하기 위해 본 논문에서는 UCS 아키텍처를 활용하여 한국형 UCS 모델을 개발하였다. 또한 아키텍처에서 명시하지 않은 서비스 개발과 관련된 요소(프레임워크, 통신 미들웨어, 서비스 구조 등)를 설계한 후, 이를 기반으로 개발자들의 업무 효율성을 향상시키는 보일러플레이트를 개발하였다. 본 연구의 결과는 무인 항공 시스템의 지상 통제 장비 개발을 효과적이고 경제적으로 수행할 수 있는 기반이 될 것이다.

Ⅰ. 서론

전장에서 한정된 병력을 활용하여 효율적인 임무 수행과 인명 피해를 최소화하기 위해 무인 항공기의 사용이 급속도로 증가하고 있다. 이러한 무인 항공기들은 무인 항공 시스템(UAS; unmanned aerial system)의 구성 요소로 구성되어 있으며, 무인항공기(UAV; unmanned aircraft vehicle), 데이터링크 장비, 임무 장비, 지상 통제 장비(GCS; ground control segment)로 구성된다[1].

무인 항공 시스템의 운용 개념 및 환경에 따라 지상 통제 장비의 요구사항이 다르지만, 그럼에도 지상 통제 장비가 가져야 하는 공통된 요구사항이 존재한다[2]. 그러나 이러한 공통된 요구사항을 충족하기 위한 시스템 구성이 표준화되지 않아 공통 기능의 재활용이 어려워, 획득 비용이 지속적으로 발생하는 문제가 있다.

미국에서는 이러한 문제를 해결하기 위해 2009년부터 미국방부의 지원 하에 통제장비의 아키텍처를 공통화하여 지상통제장비의 소프트웨어 기능 단위의 상호 운용성을 확보하는 UCS(unmanned system control segment) 아키텍처를 제정하였다. 이 아키텍처는 SAE Aerospace AS-4 UCS 위원회가 현재까지 관리하고 있다[3]. UCS 아키텍처는 모듈식으로 확장 가능한 개방형 시스템을 위한 아키텍처이다. 지상 통제 장비를 구성하는 소프트웨어를 개발할 수 있도록 지상통제체계의 기능을 분해 및 정의하고 서비스의 상호운용성을 확보하였다. 한국형 UCS 모델 및 아키텍쳐 또한 개방성을 보장하기 위해 개발과 관련된 요소(개발 언어, 프레임워크, 통신 미들웨어 등)에 대한 제한을 두지 않는다. UCS 아키텍처는 UML 모델의 형태로 UCS 아키텍처의 구조와 내용을 배포하고 있다.

한국에서 위와 같은 UCS 아키텍처를 기반으로 지상통제 장비를 개발하기에 어려움이 존재한다. 그 어려움은 다음과 같다. 첫째, UCS 아키텍처는 무인 항공 시스템의 지상통제 장비 뿐 아니라 해상, 지상 등 다양한 무인 시스템의 지상통제 장비를 다루고 있어, 그 양이 방대하고 모두 적용하기 어렵다. 둘째, 한국형 무인기의 운용에 필요한 개념 일부가 부족하다. 셋째, UCS 표준에서 사용하는 데이터 모델과 한국형 표준 프로토콜의 형식이 상이하여 사용이 어렵다.

본 논문에서는 이를 극복하기 위해 한국형 UCS 아키텍처를 제안한다. 또한 아키텍처에 명시되지 않은 서비스 개발과 관련된 요소들을 설계하였다.. 프레임워크, 통신 미들웨어, 서비스 구조 등을 설계 하였으며, 이를 기반으로 개발자들의 업무 효율성 향상을 위한 보일러플레이트를 구성하였다.

논문의 구성은 다음과 같다. 2장에서 UCS 아키텍처에 대하여 설명한다. 3장에서는 UCS 아키텍처를 기반으로 생성한 한국형 UCS 아키텍처 모델에 대하여 설명한다. 4장에서는 표준에서 제공하지 않은 개발에 필요한 요소들을 설계 한 뒤, 이를 이용하여 구성한 보일러플레이트에 대하여 설명한다.

Ⅱ. UCS 아키텍처

UCS는 UCS 아키텍처는 무인 항공 시스템의 지상 통제 장비를 위한 상호 운용 가능한 소프트웨어 개발 규칙을 정의한 표준이다. 이 아키텍처는 무인 항공기를 위해 처음 정의 되었지만 현재는 항공기뿐만 아니라 모든 무인 시스템(항공, 해상, 지상) 에서 다루도록 확장되었다. 이 표준은 무인 시스템의 아키텍처에 대한 일관되고 체계적인 접근 방식을 장려하기 위해 4가지 산업 표준을 채택하였다. OMG 사의 SoaML, UML, ISO/IEC 42010, Open Group SOA Ontology 를 따른다. UCS 아키텍처 표준은 여러 라이브러리로 구성되어있다. 그림 1은 라이브러리에 대한 구성을 보여준다.

그림 1. UCS 아키텍처 라이브러리 형상 항목

Fig. 1. Library Configuration Items of UCS Architecure.

2-1 Architecture description (AS6512)

Architecture description (AS6512)은 최상위 시리즈로, 아키텍처에 대한 관심 시스템, 이해 관계자, 시스템 관심사 및 근거를 설명하고 이에 대한 관점(viewpoint), 모델 종류, 뷰 모델 그리고 그들의 대응 관계를 설명한다. Architecture description은 크게 Architecture decision과 Architecture view로 구성된다.

Architecture decision은 아키텍처를 설명하기 위해 결정된 요소로 아래와 같이 3가지 요소를 가지고 있다.

1) System use case model : Use case 는 사용자의 관점에서 시스템의 행위를 모델링 한 것으로, 해당 아키텍처에서는 요구사항을 기반으로 상위 Use case를 도출하였으며, 하위 수준의 Use case로 분해하여 상세화하였다. 이를 통해 UAS(unmanned aerial system) 임무를 수행하는데 필요한 비즈니스 목표를 공유할 수 있으며, 이에 맞춰 개발자가 소프트웨어를 개발한다면 기능적으로 역할과 책임이 명확히 분리된 소프트웨어를 설계할 수 있어 확장성 및 재사용성이 향상될 수 있다.

2) Platform independence : 해당 아키텍처는 MDA(Model Driven Architecture)를 사용하여 플랫폼에 종속되지 않고 소프트웨어를 개발할 수 있도록 하였다. PIM(platform independent model), PSM(platform specific model)을 사용하여 모델을 표현하였다. PIM은 기술에 종속적이지 않은 모델이며, 특정 시스템 또는 플랫폼에서 발생할 수 있는 문제는 PSM에 묘사한다. 이를 통해 다양한 개발 플랫폼을 사용할 수 있어 유지 관리 용이성과 플랫폼에 대한 확장 가능성이 보장된다.

3) Domain-based partitioning approach : 해당 아키텍처는 보다 쉬운 탐색과 이해를 제공하기 위해 주제별로 전문 지식을 도메인으로 분할하였다. 총 6개의 도메인으로 정의되어 있으며 각 도메인은 표 1에 설명되어 있다. 이를 통해 개발자 간의 UCS에 대한 공통적인 지식 공유가 가능해지며, 사용하는 용어와 개발하는 기능이 공통화 되어 각 개발품들의 상호 운용성이 향상된다.

표 1. 도메인 종류 및 설명

Table. 1. Types of Domains and Descriptions.

Architecture view는 시스템 관심사의 관점에서 시스템의 아키텍처를 표현한 산출물이다. 해당 아키텍처는 크게 3가지의 view로 구성된다.

1) Version description document : 개정된 UCS 아키텍처의 구성 항목과 이에 대한 업데이트 요약을 담고 있다.

2) Architectural model and ICD: 4개의 package와 2개의 configuration item 으로 구성되어 있다. package는 기능 요구사항, 참가자의 역할, 서비스 인터페이스, 데이터, 제약 조건을 설명한다. configuration item은 사용자가 package로 작업하는데 도움이 되는 항목으로 use case trace와 ICD(Interface Control Document)로 구성되어 있다.

3) Conformance specification : UCS product의 conformance 요구사항을 확립하기 위한 사양으로, UCS product service description, application program interfaces, architecture description, product test artifacts등에 대한 내용이 기술 되어있다.

2-2 Architecture model (AS6518)

Architecture model(AS6518)은 UCS 아키텍처 모델에 대한 사용자 가이드이다. UCS 아키텍처 모델은 AS6512 문서에 자세히 설명된 UCS 아키텍처의 구조와 내용을 표현하는 모델이다. 문서에는 UCS 아키텍처 모델의 내용과 구성을 요약하고, 모델을 사용하기 위한 방법과 도구가 설명되어 있다. UCS architecure 모델은 Sparx enterprise architect 15 기반 UML 모델 파일로 표준 배포되어 있다. UCS 아키텍처 모델은 system use case model, conceptual model, logical model을 비롯한 여러 요소로 구성된다. 이러한 모델은 시스템의 요구 사항, 구조 및 기능에 대한 포괄적인 보기를 제공하고 일관되고 효과적인 설계 및 구현을 보장하는 데 도움이 된다. 아래 그림 2는 아키텍처 모델의 구조다.

그림 2. UCS 아키텍처 모델 구조

Fig. 2. Structure of UCS Architecure Model.

1) System use case model

GCS의 요구사항 및 상호 작용이 식별되어 있는 모델이다. 요구사항과 시스템의 상호작용이 use case, aactivity 다이어그램의 형태로 시각적으로 표현되어 있으며, 각 다이어그램에 대한 텍스트 설명이 함께 제공된다. GCS의 요구사항을 체계, 도메인, 서비스, 행위의 순으로 4단계로 계층적으로 정의 하였다. use case를 계층적으로 구성함으로서 복잡한 시스템을 구조화하여 나타낼 수 있어 이해 관계자들의 향상된 커뮤니케이션, 증분 개발, 이슈의 분리 등 다양한 장점이 있다.

(1) L0 use case - 체계 단위 요구도

GCS 관점의 UAS 요구사항으로, 추상적으로 시스템이 달성해야하는 주요 목표를 중점으로 작성되어있다. 이해관계자가 자세한 상호작용이나 기능에 얽매이지 않고 전체 시스템의 목표를 이해할 수 있도록 한다. 예시로는 ‘비행체 통제’가 있다.

(2) L1 use case - 도메인 단위 요구도

체계 요구사항을 기반으로한 GCS 의 요구사항으로, 사용자와 UCS, 외부 시스템 간의 상호작용에 중점을 두고 묘사하였다. 예시로는 ‘비행체 이륙’이 있다.

(3) L2 use case - 서비스 단위 요구도

독립 가능한 단위 기능을 식별한 요구사항으로, 외부 환경이 아닌 UCS 내부 작동에 중점을 두고 시스템의 구성요소와 이들간의 상호작용을 설명한다. 예시로는 ‘이륙 준비’가 있다.

(4) L3 use case - 행위 단위 요구도

재활용 가능한 하위 기능을 식별한 요구사항으로, 시스템 내의 구성요소를 이루는 하위 구성요소간의 세부적인 상호 작용에 중점을 두고 설명한다. 기능에 필요한 입/출력, 데이터 형식, 통신 프로토콜 및 기타 구현 세부 정보도 담겨 있다. 예시로는 ‘가용 무인기 리스트업’이 있다.

2) Conceptual model & logical model

conceptual model은 UCS의 주요 구성 요소에 대한 추상적인 표현을 제공한다. 구현에 대한 세부 사항이 아닌 시스템 내부의 구조와 구성 요소간의 관계를 중점으로 설명한다. 블록 다이어그램, 데이터 흐름 다이어그램 또는 도메인 모델과 같은 그래픽 표현이 포함되며 주요 개념 및 관계에 대한 텍스트 설명도 포함되어 있다. logical model은 conceptual model을 기반으로 구체화된 모델로 UCS 의 구성요소와 이들의 인터페이스 그리고 데이터 흐름에 대한 설명을 담고 있다. 구성 요소의 기능적 및 비기능적 요구 사항을 지정하고 사용할 표준화된 통신 프로토콜 및 데이터 형식을 정의한다. UML 다이어그램과 SysML 다이어그램으로 표현되며, 설계 의도를 명확하게 하기 위한 텍스트 설명을 포함한다.

Conceptual model과 logical model은 service model, message model, data model로 구성된다. 아래 그림 3은 service model, message model, data model의 관계를 나타낸 그림이다.

그림 3. Service, Message, Data 모델의 관계도

Fig. 3. Relation of Service, Message and data model.

(1) Service model : 서비스별로 외부에 제공하는 기능(Operation)과 서비스의 기능 구현을 위해 사용하는 다른 서비스의 기능을 요청-응답 형태로 명세한다.

(2) Message model : 데이터 모델에 정의된 클래스를 필드로 갖는 클래스 형태로 서비스 기능의 요청-응답(API)을 정의하는 모델

(3) Data model : 메시지 모델의 attribute를 구성하는 표준화된 자료 구조로, 메시지 모델 확장 시 사용 가능하도록 무인항공체계의 전반적인 정보를 포함하는 표준 공통모델을 사전화하여 정의한다.

Ⅲ. 한국형 UCS 아키텍처 모델

2장에서 설명한 UCS 아키텍처 모델의 구성은 시스템의 요구 사항, 구조 및 기능에 대한 포괄적인 보기를 제공하고 일관되고 효과적인 설계 및 구현을 보장하는 데 도움이 된다.

그러나 UCS 아키텍처를 한국 무인기 환경에 그대로 적용하기에는 여러 어려움이 있다. 첫째, UCS 아키텍처는 무인 항공 시스템의 지상통제 장비 뿐 아니라 해상, 지상 등 다양한 무인 시스템의 지상통제 장비를 다루고 있어, 그 양이 방대하고 모두 적용하기 어렵다. 둘째, 한국형 체계 임무계획 처리 기능, 한국형 무인기체계 연동 기능 등 한국형 무인기의 운용에 필요한 개념 일부가 부족하다. 셋째, UCS 표준에서 사용하는 데이터 모델과 한국형 표준 프로토콜의 형식이 상이하여 사용이 어렵다.

이러한 어려움을 극복하기 위해 UCS 아키텍처를 기반으로 한국형 UCS 아키텍처를 개발하였다. 한국형 UCS 아키텍처는 UCS 표준 아키텍처에 실체화를 위한 프레임워크 모델을 추가 구성하고 한국형 표준 프로토콜을 통해 한국형 무인기 체계와 연동 가능하도록 데이터 모델과 인터페이스 모델을 확장하였다. 한국형 UCS 표준 모델은 다음과 같은 모델을 포함한다[2].

3-1 시스템 요구사항 모델

UAS를 통제하기 위한 지상통제 시스템에 대한 일반적인 요구사항을 추상화하고 계층 구조의 participant(서비스)로 분해 정의 한다. participant와 actor(외부, 서비스) 간의 상호 작용을 식별하고 연동 절차가 명세 되어 있다. 한국형 UCS 아키텍처는 UCS 표준의 시스템 요구사항 모델을 그대로 상속하며, 다양한 무인기 연동 프로토콜을 동적으로 수용할 수 있도록 동적 프로토콜 변환 서비스를 추가하였다.

동적 프로토콜 변환 서비스를 추가함으로 지상통제 체계와 무인기 체계 간에 adaptation layer를 구성하여 무인기연동 프로토콜과 지상통제 체계간의 종속성을 추가로 감소 시켰다.

3-2 아키텍처 모델

서비스 지향 아키텍처를 구현하기 위한 연동 요구사항을 명세하고 있다. conceptual model과 logical model로 나누어 서비스 모델, 메시지 모델, 데이터 모델이 포함되어 있다.

1) Service model

서비스별로 외부에 제공하는 기능과 서비스의 기능 구현을 위해 사용하는 다른 서비스의 기능을 함수 형태로 명세하고, 기능 호출을 위한 요청-응답 인터페이스를 명세 한다. 한국형 UCS 모델은 한국형 지상통제장비의 기능처리를 위해 dynamic airspace(전장 환경 정보 획득 기능), mission planning(한국형 무인기 체계 임무계획 처리 기능), primary mission control(한국형 무인기체계 연동 기능) 등 도메인에 속하는 서비스의 기능을 확장하였다.

2) Message model

서비스 기능의 요청-응답(API)을 정의하는 모델을 데이터 모델을 필드로 갖는 클래스 형태로 명세 한다. 한국형 UCS 모델은 한국형 표준 프로토콜과의 호환성을 위해, primary mission control(한국형 프로토콜 기반 비행통제 및 부체계 연동), sensor product PED(한국형 영상 프로토콜 처리), mission planning(한국형 임무계획 처리) 등 도메인에 속하는 메시지에 한국형 표준 프로토콜 처리를 위한 필드를 추가하였다.

3) Data model

메시지 모델 확장 시 사용 가능하도록 무인항공체계의 전반적인 정보를 포함하는 표준 공통모델을 사전화하여 정의하고 있다. 한국형 UCS 데이터 모델은 한국형 표준 프로토콜에 맞춰 필드를 추가 정의 하였다.

3-3 프레임워크 모델

한국형 UCS 아키텍처는 지상통제 소프트웨어 개발을 가속화하기 위하여 개발 아키텍처를 추가로 정의하고 프레임워크화 하였다. 아래 그림 4는 프레임워크 모델의 구성도이다.

그림 4. 프레임워크 모델 구성도

Fig. 4. Framework Model Structure.

1) 상호연동 프로토콜 모델

한국형 표준 프로토콜을 모델화하여 한국형 UCS 아키텍처에 포함 시켰다. 이를 위하여 한국형 표준 프로토콜 명세파일을 UML 도구 및 MDA 프로세스에서 이용 가능하도록 변환 도구를 프레임워크화 하였다.

2) 프레임워크 개발 모델

한국형 표준 UCS 모델을 이용하여 서비스 공급자를 개발하거나, 서비스 소비자를 개발 할 때, 모델기반으로 설계를 진행 하고 해당 개발자가 관심 있는 내용만 참조 할 수 있도록 개발 단위별 표준을 적용한 모델파일을 생성할 수 있도록 프레임워크 도구를 개발 하였다. 이를 기반으로 개발 코드를 자동으로 생성할 수 있다. 이를 통해 개발자들이 모델에 정의된 내용을 수동으로 코드로 작성하지 않아도 되어 사람의 실수를 방지하고, 개발 시간을 단축 할 수 있다. 또한 개발자는 비즈니스 로직 개발에만 집중적으로 시간을 쏟으면 되기 때문에 전반적인 GCS 개발에 생산성을 향상 시킬 수 있다.

Ⅳ. 서비스 설계

UCS 아키텍처에서는 서비스의 역할과 인터페이스는 정해져 있지만, 이 인터페이스를 어떻게 수행할지, 프레임워크 통신 미들웨어 등 개발과 관련된 요소는 정의되어 있지 않다. 본 장에서는 서비스 개발에 필요한 요소들을 설계하였다.

4-1 MSA

앞서 설명한 바와 같이, UCS 아키텍처는 서비스 기반 아키텍처(SOA; service-oriented architecture)를 기반으로 설계 되었으며, 한국형 UCS 아키텍처에서는 SOA의 한 형태인 마이크로서비스 아키텍처(MSA; microservices architecture)를 적용하였다. MSA의 주요 특징 중 하나는 서비스 간의 경계가 명확하게 정의되어 있어 독립적으로 개발 및 배포가 가능하다는 것이다[4]. 도메인 간의 경계가 명확하고 독립적으로 개발이 가능하기 때문에 이 접근법이 UCS 아키텍처에 적합하다고 판단하였다. MSA를 사용함으로써 얻을 수 있는 장점은 중앙 집중식 구성 요소에 의존하지 않고 개발이 가능하다는 것이다. 전체 시스템이 하나의 단위가 아니라 서비스별로 독립적으로 배포할 수 있기 때문에, 전체 시스템에 영향을 주지 않고 개별 서비스를 변경하거나 업데이트하면서 유지보수 작업을 효율적으로 수행할 수 있다.

4-2 미들웨어

UCS 아키텍처에서 서비스 간의 직접적인 상호작용이 필요한 경우 동기식 통신이 사용되며, 서비스간의 주기적으로 이루어지는 데이터 공유에는 비동기식 통신이 사용된다. 본 아키텍처에서는 동기식 통신에는 RESTful API(representational state transfer application programming interface)를, 비동기식 통신에서는 DDS(data distribution service)를 적용하였다. UCS 아키텍처는 메시지 기반 통신 방식을 채택한다. 그럼에도 불구하고 요청/응답 방식인 RESTful API를 적용하였는데, 그 이유는 아래와 같다[5].

1) 플랫폼 독립적: RESTful API는 다양한 플랫폼 및 프로그래밍 언어 간의 상호 작용을 용이하게 한다.

2) 간단하고 명확한 구조: RESTful API는 간단한 구조를 가지고 있어 개발자가 쉽게 이해하고 구현할 수 있다.

3) 확장성: RESTful API는 쉽게 확장할 수 있어서 새로운 기능이나 서비스를 추가하기에 용이하다.

이러한 특징으로 서비스간의 결합도가 낮아져 MSA에 적합하며, Restful API는 엄격하게 메시지 기반이 아니지만 메시지 형식을 사용하여 프로그램 간에 통신하기 때문에 UCS 아키텍처의 설계를 따를 수 있어 적합하다고 판단하였다.

비동기식 통신은 주로 요청이 아닌 데이터 공유의 목적으로, 응답이 필요 없다. RESTful API는 요청-응답 모델로 모든 요청에는 응답이 존재하며, 비동기식 통신을 RESTful API를 사용하게 되면, 응답이 필요하지 않은 경우에도 요청/응답 과정을 거치면서 클라이언트와 서버 모두 자원을 사용한다. 이는 전체 시스템의 자원 사용 효율성이 저하(서버 부하, 네트워크 오버헤드, 불필요한 응답 처리 등)되는 원인이 될 수 있다.

본 아키텍처에서는 위와 같은 자원 낭비를 막기 위해 비동기식 통신에 한하여 DDS를 사용하고자 한다. DDS는 실시간 데이터 공유 및 효율적인 통신을 가능하게 하는 게시-구독 방식을 따른다. DDS 는 아래와 같은 장점이 있어 실시간성이 필요한 주기적 메시지 송수신에 적합하다[6].

1) 게시-구독 모델: DDS는 게시-구독 통신 모델을 따르므로 게시자는 구독자의 확인을 기다리지 않고 데이터를 보낼 수 있다.

2) 분리: DDS의 게시-구독 모델은 데이터 생산자와 소비자를 독립적으로 분리할 수 있다. 이는 생산자와 소비자사이에 긴밀한 결합이 없어 시스템의 유지 관리성과 확장성을 향상시킬 수 있다.

3) 실시간 성능: DDS는 실시간 시스템용으로 설계되었으며 서비스 품질(QoS) 매개변수를 제공한다. 이를 이용해 통신 오버헤드를 최소화하면서 주기적인 메시지를 적시에 전달할 수 있다.

4) 동시성: DDS는 여러 게시자와 구독자가 응답을 기다리지 않고 동시에 통신할 수 있다. 이는 특히 병렬 처리 수준이 높은 시스템에서 시스템 성능 및 응답성을 향상시킬 수 있다.

4-3 서비스 요청 처리 구조

앞서 설계한 미들웨어를 통해 서비스에 요청이 들어온 경우, 이를 처리하는 구조를 mediator 패턴과 pipeline 패턴을 적용하여 설계하였다[7].

1) Mediator 패턴

Mediator[8]는 중재자, 조정자라는 뜻을 가진 단어이다. 단어의 뜻과 유사하게 객체 간의 관계를 중재하고 관리하는 역할을 한다. Microsoft 에서도 권장하는 패턴으로 요청을 수신하는 객체와 요청을 처리하는 객체 사이에 mediator를 두어 서로 직접적으로 요청과 응답을 주고받지 않고 연동할 수 있도록 하는 구조이다. 이 구조는 그림 5와 같이 객체 간의 통신 관계를 간결하게 만들 수 있어 느슨한 결합(Loosely coupled)을 가능하게 한다. 또한, 객체간의 의존성을 줄여 유지보수가 보다 원활하게 이루어 질 수 있도록 한다.

그림 5. Mediator 패턴 적용 전, 후 비교

Fig. 5. Comparison before and after applying the Mediator. design pattern.

2) Pipeline 구조

파이프라인 구조는 각 단계가 특정 작업 또는 기능을 나타내는 일련의 처리 단계를 구성하는 디자인 패턴이다[9]. 이 구조에서 데이터는 한 단계의 출력이 다음 단계의 입력이 되는 상호 연결된 과정을 통해 전달된다. 데이터가 순차적으로 파이프라인을 통해 흐르므로 각 단계에서 미리 결정된 순서대로 데이터를 처리할 수 있다. 따라서 각 단계별로 모듈화가 가능하며, 모듈별로 오류를 격리하여 유지 보수를 용이하게 한다.

3) 서비스 요청 내부 처리 구조

앞서 설명한 mediator 패턴과 pipeline 패턴을 이용하여 요청을 처리하는 과정을 controller, validator, handler로 총 3단계를 거쳐서 처리되도록 분리하였다.

1) Controller : 클라이언트 요청 수신

2) Validator : 클라이언트 요청에 대한 검증 수행

3) Handler : 클라이언트 요청에 대한 처리

mediator를 통해 각각의 파이프라인 단계 간의 통신 관계를 분리하여 서로에게 미치는 영향성을 줄일 수 있다. 이러한 분리를 통해 단계 별로 로직 변경 시 타 단계에 영향을 미치지 않고 변경 가능해져 보다 개발과 유지 보수를 용이하게 한다.

추가적으로 단계 간 캡슐화를 통해 파이프라인의 단계를 쉽게 추가, 수정 또는 제거하여 시스템 요구 사항 또는 워크로드의 변경 사항을 수용할 수 있다. 즉 파이프라인 패턴과 중재자 패턴의 결합을 통해 모듈성과 확장성을 향상시킬 수 있다.

4-4 보일러플레이트 자동 생성

UCS 아키텍처에서는 서비스에 구현되어야 하는 기능이 정의되어 있으며, 서비스의 기능마다 동일한 파이프라인 단계를 거치게 설계하였다. 따라서 본 아키텍처를 기반으로 GCS를 개발하는 개발자는 유사하거나 동일한 코드를 반복적으로 작성해야한다.

본 논문에서는 반복적인 코드 작성을 생략하여 개발의 효율성을 향상시키기 위해 보일러플레이트 코드를 자동으로 생성하는 프로그램을 만들었다. 보일러플레이트(Boilerplate)란 개발자가 프로젝트에서 반복적으로 사용하는 표준적인 코드를 의미한다. 보일러플레이트 코드는 기본적인 구조나 기능을 제공하며, 개발자가 프로젝트에 맞게 적절한 수정을 가하여 사용할 수 있다. 보일러플레이트 코드를 자동 생성함으로써 개발 시간을 단축하고, 일관성을 유지하며, 개발자가 중복되는 작업을 수행하는 것을 피할 수 있다.

보일러플레이트 코드는 서비스에서 사용하는 공통 기능과 함께 3-2 절에서 생성한 서비스 인터페이스 클래스를 입력으로 받아 기능별로 3-5절에서 설계된 처리 구조를 담았다. 보일러플레이트의 기본 구조는 아래 그림 8과 같이 구성되어 있다. 총 5개의 계층으로 이루어져 있다.

그림 6. BoilerPlate 구조

Fig. 6. Structure of BoilerPlate.

1) .NET core: 애플리케이션의 기본 프레임워크를 제공하는 계층으로, .NET core를 사용한다. 이전에 닷 넷 프레임워크(.net framework) 기반으로 개발된 라이브러리를 호환하기 위해 보일러플레이트는 .Net core를 기반으로 한다.

2) 통신 미들웨어: 이 계층은 통신 프로토콜, 데이터 전송, 메시지 처리, 네트워크 보안 등과 같은 통신 관련 기능을 담당한다. 이를 통해 서로 다른 시스템 간의 데이터 교환 및 통신을 원활하게 구현할 수 있다. 3-4절에서 설명한 미들웨어 관련 코드들이 포함된다.

3) 공통 기능 : 이 계층은 애플리케이션 전반에 걸쳐 공통적으로 사용되는 기능을 구현한 클래스들로 구성된다. 이러한 클래스들은 데이터베이스 접근, 로깅 등의 공통 기능을 제공하며, 애플리케이션의 일반적인 작업을 지원한다.

4) 비즈니스 로직 : 이 계층은 애플리케이션의 비즈니스 로직을 구현하는 클래스들로 구성되어 있다. 각 클래스는 특정 도메인 지식에 관련된 기능을 수행하며, 이를 통해 애플리케이션의 핵심 역할을 구현한다. 3-3절에서 생성한 서비스 관련 코드와 4-3절에서 설계한 요청 처리 구조가 포함된다.

5) 사용자 인터페이스(UI): 이 계층은 애플리케이션의 사용자 인터페이스를 구현한다. mandatory 는 아니며, optional로 포함할지 말지 선택할 수 있다. 서비스가 GUI(graphic user interface) 가 필요한 경우에 사용되는데, Blazor와 Syncfusion을 통한 HTML을 기반으로 한 페이지 UI 컴포넌트를 지원한다.

Ⅳ. 결론

본 논문에서는 무인 항공 시스템의 지상 통제 장비에 대한 공통된 요구사항에 대하여 개발된 소프트웨어의 재사용성을 높이고자, UCS 아키텍처를 활용하여 한국형 UCS 모델을 생성하였다. 추가적으로, 아키텍처에 명시되지 않은 서비스 개발과 관련된 요소들을 설계하였다. 프레임워크, 통신 미들웨어, 서비스 구조 등을 고려하여 개발자들의 업무 효율성을 향상시키는 보일러플레이트를 구성하였으며, 앞서 생성한 한국형 UCS 모델의 도메인 정보를 반영하여 코드를 자동으로 생성한다.

이러한 연구를 통해 무인 항공 시스템의 지상 통제 장비 개발에 대한 표준화와 재사용성을 높이는데 기여할 수 있다. 이는 프로젝트 간의 코드와 구성 요소의 재활용을 가능하게 하여, 유사한 기술의 반복적인 개발 문제를 해결하고 획득 비용을 절감할 수 있다. 본 연구의 결과는 무인 항공 시스템의 지상 통제 장비 개발을 효과적이고 경제적으로 수행할 수 있는 기반이 될 것이다.