논문 2012-49-10-27
UML 기반 점검 프로그램 설계 방법에 관한 연구
( A Study on Architecture of Test Program based UML )
김 병 용*, 장 정 수**, 반 창 봉**, 이 효 종***, 양 승 열*****
( ByoungYong Kim, JungSu Jang, ChangBong Ban, HyoJong Lee, and SeungYul Yang )
요 약
본 논문에서는 하드웨어 장비의 성능 및 기능을 검증하기 위한 방법으로 시험장비와 하드웨어 장비간의 연동시험을 하기 위한 점검 프로그램 설계 방법을 제안한다. 제안하는 점검 프로그램은 장비 스트레스를 최악의 조건에서 기능을 검증하여 사 전에 고장 유무를 확인하고 수리함으로써, 비행체에 탑재하여 발생하는 고장률을 최소화하는 방안이다. 그리고 UML을 이용하 여 객체 지향적으로 소프트웨어를 설계함으로써 다른 장비에 쉽게 적용할 수 있다. 점검 프로그램은 Architecture package와 Hardware package로 구성되어 있다. Architecture package는 시스템 관리, 로그분석, 메시지 수신 및 분석하는 역할을 한다.
시스템 관리에서 사용하는 메시지는 점검하기 위한 정보를 정의하고, 정의된 메시지는 이더넷으로 시험장비와 송수신한다.
Hardware package는 점검해야 하는 하드웨어 및 시스템 관련 하드웨어를 관리하는 역할을 한다. 점검해야 하는 하드웨어는 내부 점검과 송수신 점검으로 구별되어 있다. 내부 점검은 하드웨어 자체적으로 점검하여 그 결과를 시험장비로 전송하는 방 법이다. 송수신 점검은 통신디바이스 점검으로써 데이터를 전송하거나 수신하여 점검하는 방법이다. 모든 점검은 병렬적으로 점검함으로써 최악의 조건에서 장비의 고장유무를 확인한다. 시험한 결과는 약 1시간 동안에 디바이스들은 적게는 482번에서 많게는 15003번 점검하는 것을 확인하였다. 점검 프로그램은 하드웨어 장비의 신뢰성을 검증하는 환경/EMI 시험에 사용한다.
Abstract
This paper propose interacting test programming methods between test equipment and hardware unit to verify function and performance of the hardware unit under test. Proposed test program can minimizes the risk of failures when the unit is mounted on the aircraft by testing and verifying the unit under the worst stress condition. Also, Object oriented design using UML make it easy to apply in other equipments. Test program consists of architecture package and hardware package. Architecture package is in a role for system management, log analysis, message receiving and message analysis.
Messages that are used by system management define messages for testing and defined messages is sent and received to test equipment through Ethernet. Hardware package is in a role for hardware management that is needed to be tested and is related to a system. Hardware to be tested is divided into internal test and transmission test. Internal test inspects hardware itself and reports the test results to the test equipment. Transmission test inspects communication device by sending or receiving data. All kinds of test is done in the worst condition of the test unit executing in parallel. Each device is tested at least 482 times and at most 15,003 times about one hour. Test program is utilized in hardware reliability test like as environmental test or EMI test
Keywords: UML(Unified Modeling Language), Test Program, Hardware, Architecture, Ethernet
* 정회원, ㈜바이엠 기술연구센터 (ByM R&D Lab.)
** 정회원, LIG 넥스원 항공연구센터 (LIG Nex1 Avionics R&D Lab.)
*** 정회원, 한국과학기술원 로봇공학과 (Department of Robotics, KAIST)
****
정회원, 국방과학연구소 제7기술연구본부 (Agency for Defense Development)
접수일자:2011년7월14일, 수정완료일:2012년9월13일
Ⅰ. 서 론
최근 CPU의 성능이 급속도로 발전함으로써 다양한 하드웨어 장비가 개발되고 있다. 하드웨어 장비의 개발 은 하드웨어의 고장유무를 파악하는 점검 프로그램도 함께 개발된다. 기존의 점검 프로그램은 순차적으로 데
그림 1. 시험장비와 하드웨어 장비간의 연동 구성도 Fig. 1. Interface of test equipment and hardware.
이터를 통신 디바이스로 송수신하여 하드웨어를 점검하 는 방법이다. 하지만 기존의 방법과 같은 하드웨어 점 검은 최상의 조건에서 하드웨어를 점검하는 것이다. 최 상의 조건에서 하드웨어 점검은 비행체에 탑재하기 전 에 사전에 고장을 확인하지 못하고, 비행체에 탑재하여 고장이 발생하는 경우가 많다. 따라서 이런 점을 개선 하기 위해서 본 논문에서는 모든 점검을 병렬적으로 처 리함으로써 최악의 조건에서 하드웨어 장비를 점검함으 로써 비행체에 탑재하여 발생하는 고장률을 최소화하는 방안이다. 또한 제안한 점검 프로그램은 Hardware package 부분만을 수정하여 다른 장비에 쉽게 적용할 수 있도록 구조적으로 프로그램을 설계하였다[1]. 그림 1 은 시험장비와 하드웨어 장비간의 연동 구성도이다.
본 논문의 구성은 다음과 같다. Ⅱ장에서는 점검 프 로그램에 탑재되는 하드웨어 장비에 대하여 기술하고, 제 Ⅲ장에서는 하드웨어 장비를 점검하기 위한 시험장 비에 대하여 기술한다. Ⅳ장은 하드웨어 장비에 탑재되 는 점검 프로그램에 대하여 기술한다. Ⅴ장은 개발한 점검 프로그램의 성능에 대한 실험을 기술하고, 마지막
Ⅵ장에서는 결론을 끝으로 논문을 마친다.
Ⅱ. 하드웨어 장비
본 장에서는 제안하는 점검 프로그램을 탑재하는 하 드웨어 장비에 대해 소개한다.
1. 개 요
하드웨어 장비는 무인정찰기에 탑재되어 비행관리 및 임무관리 등을 수행하는 핵심 장비이다[2]. 그림 2는 점검 프로그램이 탑재되는 하드웨어 장비 형상이다.
그림 2. 하드웨어 장비 형상
Fig. 2. Hardware Equipment Configuration.
2. 구 성
점검 프로그램을 탑재하는 하드웨어 장비는 SBC (Single Board Computer). IOA(Input Output Assemble) #1, #2, PSM(Power supply Module), 1553 PMC(PCI Mezzanine Cards)로 구성되어 있다.
하드웨어 장비는 그림 3과 같이 고속 데이터 전송을 위한 PCI express 직렬 버스와 표준 인터페이스를 적용 한 개방형 구조의 VPX(Versatile Performance Switching : VITA 46) 표준을 적용하여 개발한 하드웨 어의 구성도이다.
그림 3. 하드웨어 장비의 구성도
Fig. 3. Hardware Equipment Functional Diagram.
Ⅲ. 시험장비
본 장에서는 하드웨어 장비를 점검하기 위한 시험장 비에 대해 소개한다.
1. 개 요
시험장비는 하드웨어 장비를 점검하기 위한 장비로 써 하드웨어 장비로 메시지를 제어하고, 디바이스로 데 이터를 송수신하는 장비이다. 그림 4는 하드웨어 장비 를 점검하기 위한 시험장비 형상이다.
그림 4. 시험장비 형상
Fig. 4. Test Equipment Configuration.
2. 구 성
시험장비는 운용노트북과 RT(Real-Time) 장비로 구 성되어 있다. 시험장비는 그림 5와 같이 PXI(PCI eXtentions for Instrumentation) 기반 백플레인으로 하 드웨어를 구성하였다.
그림 5. 시험장비의 구성도 Fig. 5. Test Equipment Diagram.
3. 기 능
시험장비는 초기상태 확인, 기능점검, 수락시험, 환경 /EMI(Electro Magnetic Interference)시험을 제공한다.
가. 하드웨어 장비의 초기 상태 확인
초기 상태 확인은 그림 6과 같이 PBIT(Power Built In Test), 디버깅 포트 확인, 버전 정보를 점검한다.
PBIT는 하드웨어 장비의 내부 기능에 대한 자체 점 검을 한다. 디버깅 포트 확인은 SBC에 있는 RS232, RS422, Ethernet을 점검한다. 버전정보 확인은 하드웨 어 장비의 펌웨어, FPGA(Field-Programmable Gate Array), TP, RT 장비의 소프트웨어, 운용노트북의 소 프트웨어 버전을 확인한다. 그림 7은 하드웨어 장비의
그림 6. 초기 상태 확인의 개념도
Fig. 6. Initial State Check Conceptual Diagram.
그림 7. 초기화 상태의 GUI 화면 Fig. 7. Initial State GUI.
초기화 상태를 확인하는 GUI(Graphical User Interface) 화면이다.
나. 하드웨어 장비의 기능점검
기능점검은 그림 8과 같이 하드웨어 장비의 고장유
그림 8. 기능점검 개념도
Fig. 8. Function Test Conceptual Diagram.
그림 9. 기능점검 GUI 화면 Fig. 9. Function Test GUI.
무를 개별적으로 점검한다.
그림 9는 하드웨어 장비의 기능 점검을 확인하는 GUI 화면이다.
다. 환경/EMI 시험
환경/EMI 시험은 그림 10과 같이 수락, 간이 기능, 충격/가속도, EMI 시험으로 구성되어 있다. 환경/EMI 시험은 하드웨어의 신뢰성을 검증에서 장비의 고장유무
그림 10. 환경/EMI 시험 개념도
Fig. 10. Environmental/EMI Test Conceptual Diagram.
그림 11. 수락시험 GUI 화면 Fig. 11. Acceptance Test GUI.
그림 12. 간이 기능시험 GUI 화면 Fig. 12. Simplified Function Test GUI.
그림 13. 충격/가속도 시험 GUI시험
Fig. 13. Mechanical Shock / Acceleration Test GUI.
그림 14. EMI 시험 GUI 화면 Fig. 14. EMI Test GUI.
를 점검한다.
그림 11은 하드웨어 장비의 수락시험을 확인하는 GUI 화면이다. 수락시험은 환경 및 EMI 시험을 하기 전과 후에 장비의 고장유무를 확인한다.
그림 12는 하드웨어 장비의 간이 기능시험을 확인하 는 GUI 화면이다. 간이 기능시험은 악조건인 환경에서 하드웨어 장비가 정상적으로 운용되는지를 확인한다.
그림 13은 하드웨어 장비의 충격/가속도 시험을 확인 하는 GUI 화면이다. 충격/가속도시험은 충격/가속도의 환경에서 하드웨어 장비가 정상적으로 운용되는지를 확 인한다.
그림 14는 하드웨어 장비의 EMI 기능시험을 확인하 는 GUI 화면이다. EMI 기능시험은 EMI 환경에서 하드 웨어 장비가 정상적으로 운용되는지를 확인한다.
Ⅳ. 점검 프로그램
본 장에서는 개발한 하드웨어 탑재되는 점검 소프트
웨어를 위한 점검 메시지를 정의하고, 하드웨어 장비와 시험장비 간의 점검 메시지 전송방법을 기술하고, 마지 막으로 점검 프로그램의 소프트웨어 설계 구조를 기술 한다[3～5].
1. 점검 메시지 정의
점검 메시지는 시험장비와 하드웨어 장비 간에 이더 넷을 통해 점검하기 위한 메시지를 정의하였다. 점검 메시지는 TP 메시지, ACK 메시지, Result 메시지, Discrete 메시지, Init 메시지로 구성된다.
가. TP 메시지
TP 메시지는 시험장비에서 하드웨어 장비로 전송하 는 데이터이다. TP 메시지의 패킷 포맷은 다음과 같다.
○ Board_Select : SBC, PMC, IOA#1, IOA#2, PSM - 000 : 초기화 시험
- 001 : SBC - 010 : PMC - 011 : IOA#1 - 100 : IOA#2 - 101 : PSM
- 110 ~ 111 : Not used
○ Test_Packet : TP, Result, Ack, Discrete, Init - 000 : TP Message
- 001 : Result Message - 010 : Ack Message - 011 : Discrete Message - 100 : Init Message - 101 ~ 111 : Not used
○ Test_Select : 초기화, 송신, 수신, 내부, BIT 점검 - 000 : 초기화 시험
- 001 : 송신 점검 - 010 : 수신 점검 - 011 : 내부 동작 점검 - 100 : BIT 점검 - 101 ~ 111 : Not used
○ Communication_Select : 환경, RS-232, RS-422, PCI, Ethernet, NVRAM, 메모리, RTC, TFFS, 1553Bus, CCDL, I2C, Watchdog, UART, Discrete, ARINC-429
- 00000 : 환경시험 BIT 시험 - 00001 : RS-422(SBC) - 00010 : Ethernet - 00011 : PCI - 00100 : NVRAM - 00101 : 메모리 - 00110 : TFFS - 00111 : 1553 - 01000 : CCDL - 01001 : I2C - 01010 : Watchdog - 01011 : RS485 - 01100 : RS422 - 01101 : RS232 - 01110 : ARINC-429 - 01111 : Discrete - 10000 : PSM
- 10001 ~ 11111 : Not used ○ Channel_Select : 채널 선택
- 00000000 : 모든 채널에 대해 점검 - 00000001 : 1번 채널에 대해 점검 …
- 11111111 : 255번 채널에 대해 점검 ○ Configuration_Size : 통신하기 위한 설정 값에 대한 크기를 byte 단위로 알려주는 필드 ○ Configuration(n) : 통신하기 위한 설정 값을 정의되어 있는 필드
- baud rate, parity, speed 등
○ Send_Recv_Data_Size : 송수신하는 데이터의 크기를 byte 단위로 알려주는 필드
○ Send_Recv_Data : 송수신하는 데이터를 알려주는 필드
○ Packet_Size : 전체 패킷의 크기를 알려주는 필드
(1) ARINC-429 Configuration(n)
ARINC-429 Configuration(n)은 ARINC429의 설정 값을 알려주는 필드로 다음과 같다.
○ Parity : 31비트를 패리티 또는 데이터 - 0 : 31비트를 패리티로 사용 - 1 : 31비트를 데이터로 사용
○ Parity_Type : 패리티를 ODD 또는 EVEN - 0 : ODD 패리티
- 1 : EVEN 패리티
○ Speed : 전송속도를 High 또는 Low - 0 : HIGH 속도 (100kbps)
- 1 : LOW 속도 (12.5kbps)
○ SDI_Filter : SDI의 필터링 기능 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Label_Filter : Label 필터링 기능 사용여부 - 0 : 비활성화
- 1 : 활성화
○ SDI : 수신할 SDI이 설정 - 0 ~ 3의 값을 설정
○ Label_Number : 라벨의 설정해야 하는 갯수 - 0 ~ 255의 값을 설정
○ Label(n) : 라벨 값을 설정 - 0 ~ 255의 값을 설정
○ Special_Label* : 특정 라벨 값을 설정 - 0 ~ 255의 값을 설정
○ Int_Overflow : RX Overflow 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Special : RX Speical label 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Underflow : RX Underflow 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Frame : Rx Frame error 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
* Special_Label : 특정 라벨을 설정하고 설정된 특정 라벨이 수신이 되면 인터럽트 및 상태확인에서 특정 라벨 수신여부를 알려주는 기능
○ Int_Parity : RX Parity error 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Water_Level : RX Water Level** 인터럽트 사용여부
- 0 : 비활성화 - 1 : 활성화
○ Int_Tx_Overflow : Tx Overflow 인터럽트 사용여부
- 0 : 비활성화 - 1 : 활성화
○ Int_Tx_Water_Level : Tx Water Level 인터럽트 사용여부
- 0 : 비활성화 - 1 : 활성화
○ Tx_Water_Level : Tx 채널의 Water Level를 설정 - 0 ~ 128의 값을 설정
○ Rx_Water_Level : Rx 채널의 Water Level를 설정 - 0 ~ 128의 값을 설정
(2) UART Configuration(n)
UART Configuration(n)은 UART(RS-232, RS-422, RS-485)의 설정 값을 알려주는 필드로 다음과 같다.
○ Baud_rate : 전송속도를 설정 - 00000 : 9600 bps
- 00001 : 19200 bps - 00010 : 38400 bps - 00011 : 57600 bps - 00100 : 115200 bps - 00101 ~ 00111 : Not used ○ Data_Bit : 데이터의 길이를 설정 - 00 : 5 bit
- 01 : 6 bit - 10 : 7 bit - 11 : 8 bit
○ Stop_Bit : Stop 비트를 설정
** Water Level : FIFO의 일정 기준을 설정하는 기능
- 0 : 1 bit - 1 : 1.5 or 2 bit
○ Parity : 31비트를 패리티 또는 데이터로 사용여부 - 0 : 31비트를 패리티로 사용
- 1 : 31비트를 데이터로 사용
○ Parity_Type :패리티를 ODD 또는 EVEN로 선택 - 00 : EVEN
- 01 : ODD
- 10 : STICK Parity logic 0 - 11 : logic 1
○ Tx_Water_Level : Tx 채널의 Water level를 설정 - 0 ~ 255값을 설정
○ Rx_Water_Level : Rx 채널의 Water level를 설정 - 0 ~ 255값을 설정
○ Int_Overflow : Rx Overflow 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Underflow : Rx Underflow 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Parity : Rx Parity 에러 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Frame : Rx Frame 에러 인터럽트 사용여부 - 0 : 비활성화
- 1 : 활성화
○ Int_Break_Con : Rx Break condition 인터럽트 사용여부
- 0 : 비활성화 - 1 : 활성화
○ Int_Water_Level : Rx Water level 인터럽트 사용여부
- 0 : 비활성화 - 1 : 활성화
○ Int_Tx_Overflow : Tx Overflow 인터럽트 사용여부
- 0 : 비활성화 - 1 : 활성화
○ Int_Tx_Water_Level : Tx Water level 인터럽트 사용여부
- 0 : 비활성화
- 1 : 활성화
(3) Discrete Configuration(n)
Discrete Configuration(n)은 Discrete의 설정 값을 알 려주는 필드로 다음과 같다.
○ Select_OPENGND_28VOPEN : 28V/OPEN 또는 OPEN/GND을 선택
- 00000000 : OPEN/GND - 00000001 : 28V/OPEN
- 00000011 : OPEN/GND, 28V/OPEN (All Test)
(4) 1553B Configuration(n)
1553B Configuration(n)은 MTL-STD-1553 Bus의 설정 값을 알려주는 필드로 다음과 같다.
○ Mode : RT, BC, MT 모드를 선택 - 0000 : RT
- 0001 : BC - 0010 : MT
- 0011 ~ 1111 : Not used ○ Bus : A, B 버스를 선택 - 0000 : A
- 0001 : B
- 0010 ~ 1111 : Not used ○ RT Address : RT 주소를 설정 ○ Sub Address : Sub 주소를 설정 ○ Word count : Word의 개수를 설정
나. ACK 메시지
ACK 메시지는 시험장비에서 점검 준비가 완료되었 다고 하드웨어 장비로 알려주는 데이터이다. ACK 메시 지의 패킷 포맷은 다음과 같다.
○ 상위 3바이트는 전송받은 TP 메시지와 동일한 값 이 설정하고 Test_Packet 필드를 TP 메시지
(0b000)에서 ACK 메시지(0b010)로 변경 ○ Ack_Signal
- 170(0xAA) : 시험장비에서 각 장비의 설정 완료 되어 수신가능을 표시
- 085(0x55) : 시험장비에서 모든 장비의 설정 완 료되어 수신가능을 표시
- 238(0xEE) : 임무컴퓨터에서 시험 소프트웨어 종료을 표시
○ Packet_Size : 전체 패킷의 크기를 알려주는 필드
다. Result 메시지
Result 메시지는 하드웨어 장비에서 점검한 결과를 시험장비로 알려주는 데이터이다. Result 메시지의 패 킷 포맷은 다음과 같다.
○ 상위 3바이트는 전송받은 TP 메시지와 동일한 값 이 설정하고 Test_Packet 필드를 TP 메시지 (0b000)에서 Result 메시지(0b001)로 변경 ○ Test_Result_Size : 임무컴퓨터에서 점검한 결과
를 시험장비에 보내주기 위한 패킷의 크기를 byte 단위로 알려주는 필드
○ Test_Result(n) : 비트 단위로 0과 1을 정의하여 하 드웨어 장비에서 점검한 결과를 표시하는 필드 - 1 : 점검결과 불량
- 0 : 점검결과 양호
○ Packet_Size : 전체 패킷의 크기를 알려주는 필드
라. Discrete 메시지
Discrete 메시지의 패킷 포맷은 다음과 같다.
Discrete 메시지는 시험장비에서 Discrete를 전송했다고 하드웨어 장비로 알려주는 데이터이다.
○ 상위 3바이트는 전송받은 TP 메시지와 동일한 값 이 설정하고 Test_Packet 필드를 TP 메시지 (0b000)에서 Discrete 메시지(0b011)로 변경
○ Ack_Signal
- 170(0xAA) : 시험장비에게 디스크리트 송신하 였음을 표시
○ Packet_Size : 전체 패킷의 크기를 알려주는 필드
마. Init 메시지
Init 메시지는 하드웨어 장비의 PBIT(Power Built In Test) 결과와 버전 정보를 시험장비에 알려주는 데이터 이다. Init 메시지의 패킷 포맷은 다음과 같다.
○ 상위 3바이트는 전송받은 TP 메시지와 동일한 값 이 설정하고 Test_Packet 필드를 TP 메시지 (0b000)에서 Init 메시지(0b100)로 설정한다.
○ Result_Size : 초기화의 점검 결과의 크기 ○ Result : 초기화의 점검 결과 및 버전 정보 ○ Packet_Size : 전체 패킷의 크기를 알려주는 필드
2. 점검 메시지 전송방법
점검 메시지 전송방법은 크게 초기화 점검, 내부점검, 송신점검, 수신점검으로 구분한다.
가. 초기화 점검 방법
초기화 점검 방법은 그림 15와 같이 시험장비에서 TP 메시지를 하드웨어 장비에 전송한다. 하드웨어 장 비는 PBIT와 버전정보를 확인하고, 그 결과를 시험장 비에 전송한다. 시험장비는 Init 메시지를 수신하고 PBIT와 버전정보를 화면에 전시한다.
그림 15. 초기화 점검의 메시지 전송 방법
Fig. 15. Message Send Methode for Initialization Test.
나. 내부 점검 방법
내부 점검 방법은 그림 16과 같이 시험장비에서 TP 메시지를 하드웨어 장비에 전송한다. 하드웨어 장비는 내부 기능을 점검하고, 그 결과를 시험장비에 전송한다.
시험장비는 Result 메시지를 수신하고 그 결과를 화면 에 전시한다.
그림 16. 내부 점검의 메시지 전송 방법
Fig. 16. Message Send Method for Internal Test.
다. 송신 점검 방법
송신 점검 방법은 그림 17과 같이 시험장비에서 TP 메시지를 하드웨어 장비에 전송한다. 하드웨어 장비는 해당하는 디바이스로 데이터를 송신한다. 시험장비는 디바이스로 데이터를 수신하고 TP의 데이터와 비교한 결과를 화면에 전시한다.
그림 17. 송신 점검의 메시지 전송 방법
Fig. 17. Message Send Method for Sending Test.
라. 수신 점검 방법
수신 점검 방법은 그림 18과 같이 시험장비에서 TP 메시지를 하드웨어 장비에 전송한다. 하드웨어는 데이 터를 수신할 준비를 하고 준비가 완료되면 시험장비로
그림 18. 수신 점검의 메시지 전송 방법
Fig. 18. Message Send Method for Receiving Test.
ACK 메시지를 송신한다. 시험장비는 ACK 메시지를 수신하면 해당하는 디바이스로 데이터를 송신한다. 하 드웨어 장비는 해당하는 디바이스로 데이터를 수신하고 TP 메시지의 데이터와 비교를 하여 그 결과를 시험장 비로 송신한다. 시험장비는 Result 메시지를 수신하고 그 결과를 화면에 전시한다.
3. 점검 프로그램의 소프트웨어 설계 구조
소프트웨어 설계 구조는 UML 기반으로 하여 구조적 으로 설계하였다[6～7]. 점검 프로그램은 Architecture package와 Hardware package로 구성되어 있다.
가. Architecture package
Architecture package는 메시지를 저장하는 CMDQueue 클래스, 시험장비와 메시지 통신을 제어하 는 CommUnit 클래스, 로그를 기록하는 Logger 클래스, 메시지를 처리하는 SBC 클래스, 점검해야 하는 항목을 가지고 있는 Unit 클래스가 있다. CMDQueue 클래스는 시험장비로부터 전송된 TP 메시지를 저장하는 큐이다.
CommUnit 클래스는 시험장비에서 이더넷으로 전송된 TP 메시지를 수신하고 분석한다. CommUnit 클래스는 데이터를 수신하기 위한 Task를 가지고 있다. Logger 클래스는 점검 프로그램에서 발생하는 로그를 파일로 기록한다. SBC 클래스는 CommUnit 클래스에서 저장 한 TP 메시지를 획득하여 해당하는 Unit 클래스를 확 인하고, 해당하는 Unit을 처리한다. SBC 클래스는 TP 메시지를 처리하기 위한 Task를 가지고 있다. Unit 클
그림 19. 내부 SBC의 OMD Fig. 19. OMD of Internal SBC.
그림 20. SBC와 Unit 클레스 간의 관계 OMD Fig. 20. OMD Relation Between SBC and Unit Class.
그림 21. Log system의 OMD Fig. 21. OMD of Log system.
래스는 점검해야 항목을 저장한다. Architecture package에서의 OMD(Object Model Diagram)은 내부 SBC, SBC와 Unit 간의 관계, Log System이 있다. 내 부 SBC의 OMD는 그림 19와 같이 SBC 클래스에서 CMDQueue의 객체를 사용한다. 그리고 SBC의 클래스 는 Logger 클래스를 사용하여 로그를 분석한다.
SBC와 Unit 간의 관계 OMD는 그림 20과 같이 SBC 클래스에서 Unit 클래스의 객체 포인터를 사용한다. 그
리고 CommUnit 클래스는 Unit 클래스를 상속받아 사 용한다.
Log system의 OMD는 그림 21과 같이 Logger 클래 스에서 ILog 클래스의 객체 포인터를 사용한다.
나. Hardware package
Hardware package는 메시지를 송수신하기 위한 Ethernet 클래스, SBC를 처리하는 xxxxSBC 클래스, 각각의 디바이스를 처리하는 클래스들이 있다.
(1) Ethernet 클래스
Ethernet 클래스는 그림 22와 같이 TCP 소켓을 초기 화하고, 초기화가 완료가 되면 메시지를 수신 대기한다.
시험장비로부터 메시지를 수신하고 메시지를 분석하여 CMDQueue에 저장한다. 이더넷으로 들어온 메시지는 여러 개의 메시지를 수신할 수 있기 때문에 재분석을 통하여 한 개의 TP 메시지로 처리한다. TP 메시지를 저장하면 xxxxSBC 클래스로 이벤트를 전송하여 xxxxSBC 클래스를 처리하도록 한다.
그림 22. Ethernet 클래스의 Statechart Fig. 22. Statechart of Ethernet Class.
(2) xxxxSBC 클래스
xxxxSBC 클래스는 그림 23과 같이 Ethernet 클래스 로부터 CMDQueue에서 TP메시지를 획득하고, 이벤트 를 수신한다. 획득한 TP 메시지에 따라 디바이스 클래 스를 처리하고, 이벤트가 들어올 때까지 대기한다.
그림 23. xxxxSBC 클래스의 Statechart Fig. 23. Statechart of xxxxSBC Class.
(3) 디바이스를 처리하는 클래스
디바이스를 처리하는 클래스는 점검하는 디바이스 클래스, Run, Send, Recv로 구성된다. Run 클래스는 그 림 24와 같이 자체 점검을 수행하고, 그 결과를 시험장 비로 Result 메시지를 송부한 후 종료한다.
Send 클래스는 그림 25와 같이 TP메시지의 데이터 의 값에 따라 해당하는 디바이스로 데이터를 송신한 후 종료한다.
그림 24. Run 클래스의 Statechart Fig. 24. Statechart of Run Class.
그림 25. Send 클래스의 Statechart Fig. 25. Statechart of Send Class.
Recv 클래스는 그림 26과 같이 시험장비로 Ack 메 시지를 송신하고 해당하는 디바이스로 데이터를 수신한 다. 수신된 데이터와 TP 메시지의 데이터 값과 비교한 결과를 Result 메시지로 송부한 후 종료한다.
Hardware package에서의 OMD는 Test Unit과 SBC 의 Architecture package가 있다. Test Unit OMD는 그 림 27과 같이 Architecture package의 Unit 클래스와 디바이스 클래스의 관계를 나타낸다. 디바이스 클래스 들은 Unit 클래스를 상속받아 사용한다.
SBC의 Architecture OMD는 그림 28과 같이 xxxxSBC 클래스와 디바이스 클래스의 관계를 나타낸 다. xxxxSBC는 디바이스 클래스의 객체 포인터를 사 용한다.
그림 26. Recv 클래스의 Statechart Fig. 26. Statechart of Recv Class.
그림 27. Test Unit의 OMD Fig. 27. OMD of Test Unit.
그림 28. SBC Architecture의 OMD Fig. 28. OMD of SBC Architecture.
Ⅴ. 실 험
본 장에서는 하드웨어 장비에 개발한 점검 프로그램 을 탑재하여 시험장비와 연동한 시험 결과를 분석하고, 신뢰성 검사를 위한 환경 및 EMI 시험의 적용한 사례 를 분석하였다. 점검 프로그램은 표 1과 같은 항목을 점검하였다.
점검 프로그램의 안정성 검증 확인은 하드웨어 장비 에 점검 프로그램을 탑재하여 시험장비와 연동 시험을 약 1시간 동안 수행하였다. 약 1시간 동안 점검 결과는 그림 29와 같이 최소 482번에서 최대 15003번 점검하 였다.
각 각의 점검 항목들은 독립적인 Task를 가지고 동 작함으로써 하드웨어 장비의 디바이스들을 병렬적으로 점검한다. 따라서 점검 항목들은 점검 횟수가 다르게 점검한다. 그림 30은 점검하고 있는 상태에서의 Task들
구분 점검 항목 채널
1 RS485 송수신 : 4 2 RS422 송수신 : 4 3 RS232 송수신 : 4 4 ARINC429 송수신 : 6 5 Discrete 송신 : 25, 수신 : 54
6 CCDL 송수신 : 2
7 Ethernet 송수신 : 1 8 M1553B 송수신 : 4
9 WDT 내부
10 I2C 내부
11 Memory 내부
12 PCI 내부
13 TFFS 내부
14 NVRAM 내부
표 1. 점검 프로그램의 점검 항목표 Table 1. Test List Table for Test Program.
그림 29. 약 1시간 동안 점검 결과 Fig. 29. Test Results for about 1 hour.
의 상태를 보여준다.
점검 프로그램은 환경/EMI 시험과 같은 하드웨어 장 비의 신뢰성을 검증하는데 연동프로그램을 사용하였다
[8]. 환경시험은 MIL-STD-810G와 MIL-HDBK-217F 규격에 따라 온도 습도 복합, 고온저장, 저온저장, 충격, 진동 시험을 수행하였다[9～10]. 그림 31은 충격 시험의 점검 결과이다.
EMI시험은 MIL-STD-461F와 MIL-STD-464A 규
그림 30. Task 상태 Fig. 30. Task status.
그림 31. 충격시험의 점검결과 화면 Fig. 31. Mechanical Shock Test Results.
그림 32. EMI 시험에서 하드웨어 고장 결과 화면 Fig. 32. Hardware Failure on EMI Test.
격에 따라 EMC/EMI 시험을 수행하였다[11～12]. 그림 32 는 EMI 시험의 RS106에서 장비의 이상이 발생한 결과 화면이다.
하드웨어 장비는 케이블의 신호선에 특정 주파수를 인가하여 RS232와 CCDL 통신 디바이스에 고장이 발 생하였다. 연동 프로그램은 EMI시험에서 고장이 발생 한 것과 같이 어떤 디바이스가 고장이 발생했는지를 알 수 있다.
Ⅵ. 결 론
본 논문에서는 하드웨어 장비의 성능 및 기능을 검증 하기 위한 방법으로 시험장비와 하드웨어 장비간의 연 동시험을 하기 위한 점검 프로그램 설계 방법을 제안한 다. 점검프로그램은 점검항목마다 각각의 Task를 가지 고 있어서 하드웨어장비의 디바이스를 병렬적으로 점검 한다. 그리고 UML를 사용하여 구조적으로 설계함으로 써 Hardware package 부분을 수정하여 다른 장비에 적용하기 쉽게 설계를 하였다. 점검 프로그램은 하드웨 어 장비의 고장유무를 확인한 것 외에도 하드웨어 장비 의 신뢰성을 검증하는 환경/EMI 시험에도 사용한다.
참 고 문 헌
[1] Z. Deming, L. Bin, R. Lian, “The Domain- specific Software Architecture of Avionics Testing System,” IEEE Digital Avionics System,
Oct. 2000.
[2] 반창봉, 양승열, “무인정찰기용 임무컴퓨터 하드웨 어 개발,” 한국항공우주학회 춘계학술발표회, 744-747쪽, 2010년 04월.
[3] 문성태, 양승열, 이재억, “임무 컴퓨터의 하드웨어 통합 시험을 위한 테스트 소프트웨어 설계,” 한국 항공우주학회 추계학술발표회, 566-569쪽, 2007년 11월.
[4] 문성태, 양승열, 이재억, “임무컴퓨터의 하드웨어 시험을 위한 테스트 소프트웨어 개발,” 한국항공우 주학회 추계학술발표회, 562-565쪽, 대한민국, 2008 년 11월.
[5] 주정민, 허문범, 남기욱, “UML기반의 GNSS 보강 시스템 성능평가용 시뮬레이터 소프트웨어 설계”, 한전자공학회 하계종합학술대회 제 31권 제 1호, 1213-1214쪽, 2008년 6월.
[6] 민현석, “UML로 Embedded System 프로그래밍 하기 Rhapsody in C++(Ver 7.x),” (주)다한테크, Telelogic Korea.
[7] H. Ishikawa, K. Watanabe, “An Object-Oriented Design for Origami Activities in UML”, 대한전 자공학회 ITC-CSCC, 94-95쪽, 2007년 7월.
[8] 조동식, 나성웅, “로켓 탑재를 위한 영상 송수신장 치 개발”, 대한전자공학회, 전자공학회논문지-TC, 제46권 제2호(통권 제380호), 60-65쪽, 2009년 2월.
[9] “Environmental Engineering Considerations and Laboratory MIL-STD-810G,” Oct. 2008.
[10] “Reliability Prediction of Electronic Equipment MIL-HDBK-217F,” Dec. 1991.
[11] “Requirements for the Control of Electromagnetic Interference Characteristic of Subsystems and Equipment MIL-STD-461F,” Dec. 2007.
[12] “Electromagnetic Environmental Effects Requirements for Systems,” Dec. 2002.
저 자 소 개 김 병 용(정회원)
2006년 광운대학교 컴퓨터공학과 학사 졸업.
2008년 광운대학교 컴퓨터공학과 석사 졸업.
2008년～2011년 LIG 넥스원 선임연구원.
2011년～현재 ㈜바이엠 CEO.
<주관심분야 : 영상신호처리, 영상압축, 영상통신, 컴퓨터 비젼, 임베디드 시스템>
장 정 수(정회원)
2006년 명지대학교 통신공학과 학사 졸업.
2005년～현재 LIG 넥스원 선임연구원.
<주관심분야 : 영상처리, 신호처 리, 제어시스템>
반 창 봉(정회원)
2000년 중앙대학교 전기전자제어 공학부 졸업.
2002년 중앙대학교 전자전기 공학부 석사 졸업.
2003년～현재 LIG 넥스원 수석연구원.
<주관심분야 : 컴퓨터, 신호처리>
이 효 종(정회원)
2008년 University of Michigan, Ann Arbor 기계공학과 학사 졸업.
2010년 University of Michigan, Ann Arbor 기계공학과 석사 졸업.
2010년～현재 KAIST 로봇공학과 박사과정.
<주관심분야 : System dynamics, 생체모방로봇, 로봇제어, 통신, 신호처리>
양 승 열(정회원)-교신저자 1991년 충남대학교 전자공학과
학사 졸업.
1996년 충남대학교 전자공학과 석사 졸업.
1993년～현재 국방과학연구소 선임연구원.
<주관심분야 : 임베디드 하드웨어/소프트웨어>
