제목 : PHM Architecture Design Of Flight Control System Based On MBSE
저자 : Qingyi Zhang; Bo Jing; Fang Lu; Shenglong Wang

요약

Abstract
비행 컨트롤 PHM 시스템의 현재 문제점은 표준화되어있지 않고, 완성도가 낮다. 본 연구에서는 모델 기반의 시스템 엔지니어링을 통해 비행 컨트롤 PHM 아키텍처의 디자인 과정을 표준화한다. 또한 PHM 시스템 아키텍처 모델을 완벽한 기능과 합리적인 구조를 MBSE를 기반으로 구축한다. 진보된 PHM 기술은 비행 컨트롤 시스템에서 통합되는데, PHM 아키텍처의 기능적 구조 기초를 포함한다. MBSE를 기반한 PHM 아키텍처의 비행 컨트롤 시스템 디자인은 PHM 아키텍처가 급격한 업데이트와 정보 공유, 디자인 문제를 미리 예측하고, 일의 효율을 증가시킨다.

Introduction

MBSE(Model Based System Engineering)은 디지털 모델링 방법론으로 시스템 아키텍처 솔루션의 모델로 주변 이해관계자들을 시스템에 통합하며, 각종 기계장치, 효과적인 요구사항과 정확한 delivery를 통합한다. MBSE는 군수 산업에서 매우 유용하게 사용중이며, 항공산업과 아들ㄴ 필드에서 효과적인 디자인과 확실한 로직에 의해 사용된다. 2019년에, SysML 1.6 국테 표준 규격이 채택되어서, Rockwell Collins, 보잉, 록히드마틴이 모델 기반의 요구사항 엔니지어링을 통해 제품의 MBSE 구축 방법론이 대두되기 시작했다. 중국에서 MBSE의 적용은 잘 일어나지 않았다. 아직 MBSE 툴은 자동화 레벨이 매우 낮다. 시스템 디자인 툴 체인은 MBSE의 적용은 중국 내에서 아직 이론적 리서치만 이루어지고 있다. 따라서 성숙한 MBSE 소프트웨어를 통한 제품 생산 적용을 이뤄내는 것이 어렵다. 몇몇 국제 상황을 고려하여 소프트웨어 리소스는 중국에서 이용가능하지 않기 때문에, 이는 MBSE의 제한 사항이 되고 있다.

Model-based systems engineering

A. SysML system modeling language

SysML (System Modeling Language) 는 소프트웨어 엔지니어링에서 표준화된 그래픽 모델링 언어이다. 이는 시스템 스펙, 디자인, 분석, 검증 프로세스를 수행할 수 있다. 이는 UML(unified modeling language)의 부분으로, UML2.0은 서로 다른 언어를 통합하기 위해 SysML이 재구성되어 표준화되었다. SysML은 시스템 요구 사항을 3가지로 나누어 기능을 다음과 같이 세분화한다.

B. OOSEM modeling method

OOSEM(Object Oriented System Engineering Methodology) 모델링 방법론은 2000년에 SysML의 답다운 모델 기반의 방법론에 사용된다. 시스템 로직 분해에 기반하여, 각 시스템 모듈별로 분석이 진행된다. OOSEM 방법론으로 구축된 시스템 모델은 높은 유연성을 가지고 있고, 재사용이 가능하다. 이를 방법론은 요구사항 분석, 시스템 요구사항 정의, 논리 아키테거의 정의와 디자인 아키텍처 합성 과정으로 나뉘어진다.
본 연구에서는 PHM 시스템 아키텍처를 OOSEM모델링 방법론을 적용하여 아키텍처 디자인의 솔루션을 제공하고 PHM 요구사항을 만족한다.

Design flow of PHM architecture of flight control system based on OOSEM

A. Analyze stakeholder needs

태스크 레벨에서 이해관계자들의 요구사항을 분석 및 결정해야 한다. 이를 통해 기능적 요구사항에 대한 현재 시스템에서 존재하는 한계 사항을 기능적 요구사항을 PHM 아키텍처에 대해서 확장할 수 있다.

a. Limitations of PHM architecture in the current flight control system

PHM시스템의 비행 컨트롤 시스템 아키텍처는 아직 성숙하지 않아서, 현재 존재하는 4가지 BIT에 의존한다. BIT는 비행 컨트롤 시스템으로 현재 비행 컨트롤 컴퓨터는 합리적인 기능을 포함하지 않기 때문에 아직은 센서 수집을 통해 이것이 fault인지를 보고 결과적으로 모든 가능한 fault의 경우의 수를 고려하기 때문에 유지보수비용 코스트가 늘어나고 mission dispatch 율이 높아진다.
현재 PHM 아키텍처의 작동 도메인 FCS-PHM은 비행 컨트롤 컴퓨터의 PHM 모듈로 Fault diagnosis 와 fault isolation만 진행되기 때문에 정보로 인한 예측과 유지보수에 필요한 의사결정을 수행할 수 없다.

b. Specify task requirements

비행 제어 시스템의 PHM 시스템 아키텍처 태스크 요구 사항은 미래에 시스템 fault 가능성을 분석하고, 예방 조치를 취하기 위해 상태를 모니터링해야 한다. 또한 전반적인 health management와 주요 구성 요소 요구사항에 대해서 텍스트로 캡처하여야 한다.

c. Measure of Effectiveness (MOE)

MOE는 미션 수준 성능을 반영하며, 비행 제어 시스템의 PHM 아키텍처 효과를 측정하는 데 사용한다. 이를 통해 이해관계자의 요구 사항을 충족하며 시스템 설계 분석의 전반에 걸쳐 솔루션 계획, 선택 및 최적화가 진행되어야 한다.

d. Define the future domain model

비행 제어 시스템의 PHM 아키텍처 운용 도메인은 최상위 모듈 구조로 나타낸다.

B. Analysis of PHM architecture requirements of flight control system

PHM 아키텍처의 요구사항을 분석하는 것은 블랙 박스 모델을 통해 시스템 요구사항을 결정한다. 시나리오 스터디를 통해 모든 아키텍처와 연관된 케이스들을 시스템이 어떻게 외부 시스템과 상호작용하는지,그리고 이해당사자들과의 모델을 어떻게 인식하는지에 대해서 고려하여 미션 목표를 달성할 수 있는지 분석한다.

a. Defining a task scenario

태스크 시나리오를 정의하기 위해 미션 시나리오가 정의된다. 이는 활동 다이어그램으로 나타나서 액션은 액티비티 파티션을 통해 수행된다.

b. Define the system context

시스템 문맥 다이어그램은 외부 시스템, 이해관계자 및 내부 물리 환경 강의 상호 작용을 보여준다. 외부시스템과의 인터페이스 뿐만 아니라, 미션 시나리오에 참여하는 다른 이해관계자까지 포함한다. 내부 모듈 프레임워크는 운용 도메인 모듈로 나타나며, 이의 구성 요소는 비행 제어 컴퓨터 및 관련 인원들을 포함한다.

c. Defining the system state Machine

상태 머신은 PHM 아키텍처가 언제 특정 상태에 진입하는지, 특정 상태에서 특정 작업을 수행하는 방법을 지정한다. 감시 조건은 특정 입력 값, 현재 상황 또는 다른 조건등에 대한 감시 조건들로 지정되어 트리거가 된다면 모듈은 현재 상태에서 빠져나와 다음 상태로 이동하게 되고 다음 상태에 대한 액티비티가 수행된다.

C. Defining the logical Architecture

논리 아키텍처는 물리 아키텍처의 추상화로써 시스템 기능을 수행할 때 제약을 가할 필요가 없다. 블랙박스 시스템 요구 사항과 물리 아키텍처 사이의 중간 수준의 추상 아키텍처로서, 설계 팀이 요구 사항과 기술적인 변경의 영향을 관리하는 데 도움이 된다.
PHM 아키텍처 모듈의 별도 하위 클래스는 논리 및 물리 분해와 대응하여 생성된다. FCS-PHM 논리 모듈은 비행 제어 시스템의 PHM 아키텍처 모듈의 하위 클래스로서, 모든 특성을 상속하고 비행 제어 시스템 PHM 아키텍처의 물리 모듈도 비슷한 방식으로 물리적 구성 요소로 분해된다. FCS-PHM 논리 모듈의 모든 작업은 활동 다이어그램 방법을 통해 구현되며, 제어 시스템 PHM 아키텍처의 각 작업이 논리 디자인 과정에서 활동을 통해 관련 기능을 수행할 수 있도록 한다.
센서는 현장 데이터를 감지하고 데이터 유도 관리 프로세스와 관련된 데이터를 생성하고 데이터를 로그에 저장한다. 수집된 값은 정상 값과 비교하여 결함을 확인한다. 비행 제어 컴퓨터는 전송된 결함을 요약하고 다음 상태 조정을 수행하며 결함 정보를 저장 및 경보상태를 알린다.

D. Comprehensive alternative physical architecture

논리 아키텍처는 기능에 따라 분석이 가능하지만, 물리 아키텍처는 성능, 신뢰성 및 보안을 기반으로 분석이 가능하다. 기능적 논리의 완성에는 하나 이상의 물리 컴포넌트가 필요하다. 따라서, 논리 컴포넌트와 물리 컴포넌트 간의 관계는 일대일 혹은 일대 다가 된다.

a. Defining the logical architecture of Nodes

노드는 구성 elements의 기능, 제어 등을 나타내며 물리적 위치를 기반으로 구성 요소 데이터를 저장하는 고정, 혹은 이동 장치이다. OOSEM(Ontology for Object-Oriented Systems Engineering Methodology)에서 각 노리 노드는 논리 컴포넌트의 컬렉션으로 나타나며, 물리 노드는 특정 위치에 있는 물리 컴포넌트의 집합이 된다. 즉, PHM 아키텍처의 데이터베이스는 여러 사이트 노드에 분산되게 된다.

b. Defining the Physical Architecture of Nodes

FCS-PHM 논리 아키텍처에서 각 노드의 논리 컴포넌트를 기반으로 물리 컴포넌트가 각 노드에 할당된다. 이를 통해 비행제어 시스템의 PHM 노드 물리 구조를 구성하며, 성능 신뢰성 및 보안을 기반으로 물리 컴포넌트에 할당이 이루어진다. 이를 통해 물리 아키텍처를 설계하게 된다.

E. Optimize and evaluate alternatives

대안을 최적화하고 평가하는 과정은 분석 문맥을 정의하고, 각 분석에 해당하는 매개 변수 제약조건을 포착하며 수행된다.

a. Define the analysis context

모듈 정의 다이어그램을 사용하여 각 분석 프로세스를 진행한다.

b. Capture constraints in parameter diagrams and perform engineering analysis

매개 변수 그래프는 매개 변수를 바인딩하여 모델의 설계 및 분석 프로세스를 결합한다. 매개 변수 다이어그램은 함수의 매개 변수를 비행 제어 시스템 PHM 아키텍처의 구체적인 속성에 바인딩하는데, 매개 변수의 입력 출력 간 구성요소와의 관계를 제약하는데 사용된다. 이를 통해 제약 조건을 분석하게 된다.

F. Managing requirements traceability

a. Managing requirements updates

어떤 경우에는 각 블랙 박스 요구 사항 특성에 대응하는 새로운 텍스트가 정의되어야 한다. 요구 사항 텍스트를 명확히 한 뒤, 요구 사항 관리 도구는 모델링 도구를 통해 업데이트가 필요한 요구 사항을 동기화한다.

b. OOSEM supports system integration and verification

OOSEM에서 시스템 통합 및 검증 과정은, 케이스를 통해 요구 사항 다이어그램을 결합하여 시스템 요소 및 구성 요소 수준에서 어떻게 요구 사항이 검증되는지를 보여준다. 테스트 케이스 실행 중에 실제 결함 응답 및 예쌍 응답을 대조하여 시스템이 원하는 응답을 제공할 수 있는지 확인하게 된다.

IV.SUMMARY

OOSEM 방법론을 기반으로 비행 제어 시스템의 PHM 아키텍처의 작업 분석을 수행하고 MBSE 모델을 구축하여 다음과 같은 문제를 해결했다.
1. 이해관계자의 요구에 기반하여 작업 주체의 활동을 정의하여, 사용자 플랫폼이 어떤 기능을 달성해야하는지에 대한 문제를 해결하였다.
2. 요구 분석을 기반으로 비행 제어 시스템의 PHM 아키텍처의 시스템 작업 및 시스템 능력을 제안하였다. 시스템을 실현하기 위해 시스템 기능을 정의하고 기능 할당을 수행하였다. 이를 통해 시스템이 어떤 기능을 실현해야 하는지에 대한 문제를 해결하였다.