Ⅰ. 서 론

1. 개요

HILS란 Hardware In The Loop Simulation의 약자로 실시간 시뮬레이션을 통해 시스템을 시험 및 검증하는 기술을 뜻한다. 실제 환경에서 사용하기 전 HILS를 통해 오류를 검출하여 미연에 사고를 예방할 수 있고, 사 전 시험을 통하여 다양한 시뮬레이션 환경에서의 테스트 진행이 저렴한 비용으로 가능하다는 장점이 있다.

교통신호 평가시스템 HILS는 교통신호시스템을 검증하기 위해 연구개발이 진행되었다. 실제 환경에서 사 용되는 교통신호센터를 시험 및 검증하기 위해 교통신호제어기와 도로 환경을 모사할 수 있는 시뮬레이터인 VISSIM을 사용하여 교통신호 센터 검증을 진행하였다. VISSIM은 실제 도로환경에 시험 환경을 적용하여 가 상의 교차로와 신호등을 구현하고 신호등기정보를 전달받아 가상의 교통상황을 재현한다. LCS는 가상의 교 통신호 제어기로, 교통신호센터로부터 신호현시정보를 전달받아 1초단위로 신호등기정보를 생성하여 VISSIM으로 전달하는 기능을 갖는다. HILS를 통해 교통신호센터와 LCS(Local Controller Simulator), VISSIM 이 유기적으로 통신하며, 시스템 시험 및 검증을 실제 환경에서 적용하기 전에 진행 할 수 있다.

2. 기존연구

기존 연구는 주로 가상의 환경 안에서 시뮬레이션을 진행하거나 교통신호제어기 하드웨어에 직접 연결하 여 평가하는 등의 연구가 진행되어왔다. 미국에서는 우주항공 및 방위산업 분야에서 HILS를 개발하여 신호 제어기 성능검사 목적으로 평가시스템을 이용 중에 있다. 국내에서는 2000년도에 도로교통공단에서 제어기 성능검사 목적으로 CID(Controller Interface Device)를 개발하여, 현재는 실시간 교통제어시스템, 대중교통 우 선신호, 트램 신호제어 등의 효과평가용으로 발전하고 있다(Jung, 2001). 또한, 긴급차량 우선 신호제어시스템 등 여러 가지 시뮬레이션이 필요한 시험들이 있다(Hong, 2012). 보통의 시험들은 교통신호제어기 하드웨어와 직접 연결하여 동작하는 형태로 필요 교차로 수만큼 교통신호제어기가 필요하다는 단점이 있다. 본 연구에 서는 시뮬레이션를 진행하기 위한 제어기를 각각 1:1로 매칭하는 형태에서 실제 제어기 사용시의 한계를 극 복하고자 연구를 진행하였다. 제어기를 모사하는 하드웨어 시스템에 여러 개의 제어기를 집적하여 렉 형태 로 제작하는 연구를 진행하였다.

Ⅱ. LCS 설계∙제작

LCS설계는 PC에서 동작하는 윈도우 환경의 응용프로그램 형태와 임베디드 환경에서 리눅스를 통해 동작 하는 두 가지 형태로 설계가 진행하였다. 소량의 교차로는 PC를 통해 시뮬레이션 진행이 가능하지만, 다수 의 교차로의 경우 PC를 통해 시뮬레이션 동작시키기에는 무리가 있다. 그리하여 임베디드 환경의 연구개발 을 통해 안정성 향상과 큰 규모의 테스트 환경을 구현하고자 하는 것이 목적이다. 소프트웨어 개발은 C, C++, C#, Java, HTML, 파이썬등 언어 중에서 파이썬 언어를 선택하여 개발하였다. 파이썬 언어는 고급 프로 그래밍 언어로 인터프리터식 언어이다(Wikipedia, 2019). 파이썬은 윈도우와 임베디드 환경 모두 적용이 가능 하며 이식성이 뛰어나기 때문에 윈도우 환경에서 우선적으로 개발하였으며, 개발된 소프트웨어를 바탕으로 임베디드 환경에도 적용 할 수 있도록 수정을 진행하였다. 통신 규격은 경찰청에서 배포한 교통신호제어기 표준규격서(Korea Police Agency, 2018)의 프로토콜을 참고하여 설계하였다.

1. 윈도우 PC 환경에서의 LCS

교통신호센터 및 VISSIM 시뮬레이터와 연계하는 LCS 개발 및 시험을 용이하게 진행하기 위해 PC 선정은 노트북으로 진행하였다. 시험을 진행한 노트북의 사양은 <Table 1>과 같다.

큰 용량의 시험 환경이 아닌 작은 용량의 시험 환경에서는 윈도우 PC로도 교차로를 모사하는 LCS를 실행 시킬 수 있다. 한 개의 윈도우 PC에서 다수의 LCS를 실행하여 교차로를 모사하였다. LCS의 실행개수가 증 가함에 따라 CPU에 부하를 가중하기 때문에 최대 실행수량의 제한이 필요하였으며, 처음 실행수량 제한파 악은 CPU 부하시험으로 진행하기로 하였다. 윈도우 PC에서 실행 가능한 최대 수량을 결정하기 위해 파이썬 으로 개발된 LCS를 한 개씩 실행하며 최대 실행수량을 결정하였으며, 시험결과는 <Table 2>과 같다.

CPU 부하테스트 결과 5개의 교차로까지 정상적으로 모사를 할 수 있는 것으로 파악되었으며, 6개 이상 실행 시 CPU 사용량이 100%에 도달하여 LCS의 끊김 현상이 있는 것으로 파악되었다. 그리하여 임베디드 환경이 구축되기 이전 PC버전에서 HILS를 구동 시 윈도우 PC 1대당 LCS 5개씩 실행하기로 결정하였으며, 시험 환경의 교차로 수가 19개 이므로 윈도우 PC 4대가 필요하다는 결론이 나왔다. 3대의 윈도우 PC에서는 5개의 LCS를 실행하여 구동하였으며 1대의 윈도우 PC에서는 4개의 LCS를 실행하여 총 19개의 교차로를 모 사하는 시스템을 구현 완료하였다. 윈도우 PC에서 5개의 LCS를 실행 시 화면은 <Fig. 1>과 같으며, 전체 시 험 환경을 실행한 사진은 <Fig. 2>와 같다.

2. 임베디드 환경에서의 LCS

1) SOM 사양

SOM(System on Module)을 선정하기 위하여 자료조사를 진행하였다. 결과적으로 선정된 DART-6UL은 산 업용 온도 사양을 준수하는 최소사양 리눅스 SOM으로, 신뢰성을 기대해야 하는 상황으로서는 유일한 방안 으로 판단하였다. DART-6UL은 성능 및 옵션을 선택하여 주문할 수 있으며, LCS에 사용하기 알맞은 사양은 <Table 3>과 같다.

선정된 SOM에 리눅스 YOCTO를 설치하여, 파이썬을 통해 프로그램을 구현한다.

2) LCB 제작

LCB(Local Controller Board)는 48V DC전원을 공급받아 동작하며 LCB에 SOM 8개를 구동할 수 있도록 제 작이 되었다. 보드의 이더넷 포트를 통해 외부 이더넷과 연결이 되면 1GBit 허브칩이 내장되어 있어 각 SOM에 이더넷을 연결한다. 또한 두 번째 이더넷 포트를 통해 외부에 다시 이더넷을 연결하여 주는 기능을 갖는다. <Fig. 3>과 같이 외부에는 전원을 확인 할 수 있는 램프와 각각의 SOM의 동작 상태를 알 수 있는 램프가 표출된다. 이더넷 연결을 위한 이더넷 포트 2개와 리셋을 위한 스위치 또한 전면부에 위치한다. SOM 은 LCB와 커넥터를 통해 연결이 되기 때문에 탈부착이 가능하여 제품 AS에 유리하다는 장점이 있다.

3) LCP 제작

<Fig. 4>의 LCP(Local Controller Power)는 LCB에 전원을 주기 위한 보드로 전원케이블을 통해 220V AC를 공급받아 48V DC로 전환한다. 전환된 48V DC는 LCBP(Local Controller BackPlane)를 통해 LCB로 전달된다. 또한 외부 전원이 끊기더라도 LCB의 RTC(Real Time Clock) 전원을 공급하기 위한 배터리 장치가 내장되어 있어 단시간 정전 시 시간값이 틀어지지 않도록 하는 기능을 갖고 있다.

4) LCBP 제작

<Fig. 5>의 LCBP는 16개의 LCB와 2개의 LCP를 동작시키기 위한 보드라고 할 수 있다. 전면부에는 각 보 드를 연결하기 위한 커넥터부가 일정한 간격으로 나열되어 있고, 후면부에는 연결된 보드의 SOM 디버그 내 용을 볼 수 있는 포트와, CAN통신이 가능한 포트가 나열되어 있다. 디버그 포트를 통해 각 SOM의 상태를 확인 할 수 있으며, 제어 또한 가능하도록 설계하였다.

Ⅲ. 동작의 비교 평가

두 가지 환경 모두 설계를 진행하여 비교평가를 진행하였으며, 각 시스템의 장단점을 도출 할 수 있었다. 비교평가를 위하여 교통신호센터를 대신하여 데이터 송신 및 수신 로그 데이터를 산출 할 수 있는 서버가 필요하였으며, 다수의 클라이언트가 접속 할 수 있는 멀티스레드 서버를 파이썬을 통해 프로그래밍 하였다. 데이터의 내용 및 시간을 로그로 저장하여 응답 지연속도 및 송수신 확률평가를 진행하였다.

1. 응답 지연시간 평가

교통신호제어기는 1초 단위로 동작을 진행하며 교통신호센터와 1초 단위로 상태정보를 주고받는다. 교통 신호제어기에서 상태정보 패킷을 주고받는 것은 매우 중요하며 동작이 이루어지는 것을 판단할 수 있는 척 도가 되기 때문에 이를 평가 대상으로 선정하였다. 평가용 멀티스레드 서버에서는 1초 단위로 상태정보를 요청하는 패킷을 전송 후, 송신 받을 때까지의 응답 지연시간을 도출하였다.

윈도우 PC 버전의 LCS는 PC 1대를 기준으로 1세트부터 8세트까지 1세트씩 늘려가며 1시간 단위로 시험 을 진행하였다. <Fig. 6>부터 <Fig. 13>은 PC 환경에서 LCS 지연시간 평가 결과 그래프이다. 가로축은 데이 터 번호를 뜻하며, 세로축은 해당 데이터의 지연시간을 나타낸다. 단위는 마이크로초(μs) 이며. 시험 데이터 를 보면 데이터마다 지연시간의 차이가 나타나는 것을 볼 수 있다. 이는 운영체제의 특성으로 상황에 따라서 차이가 나타나는 것을 볼 수 있다.

시험결과 LCS를 5개 이하 실행 시 볼 수 없었던 1초 이상 지연되는 데이터가 6개 이상 실행 시 발생하는 것을 알 수 있다. 6개 실행 시부터 운영체제의 부하로 인하여 3초 이상 지연되는 데이터까지 바로 볼 수 있 으며 이는 1초에 한번 씩 교통신호센터와 송수신을 진행해야하는 상황에서 치명적일 수 있다. <Table 4>는 1 초 이상 지연된 데이터의 수와 LCS실행 수에 따른 지연시간의 평균을 나타낸다. 본 연구 초기에 CPU(Central Processing Unit) 부하시험을 통해 5개 까지 구동이 가능하다는 내용과 6개 이상 실행 시 평균 지연시간도 급 증한 것을 시험을 통해 수치상으로 확인한 것이다. 이를 통해 윈도우 PC 1대의 환경에서는 5개 이하로만 실 행이 가능함을 입증하였다.

임베디드에서의 LCS는 LCBP, LCP, LCB 전체가 결합되어 동작되는 시스템을 뜻한다. LCB의 각각의 SOM 에 리눅스 OS가 탑재되어 동작하며 파이썬으로 구현된 소프트웨어로 동작한다. 각각의 SOM에서 하나의 프 로그램만 동작시키기 때문에 다수의 LCS를 실행하려면 해당하는 수만큼 SOM을 LCB에 연결하여 동작시키 면 된다. LCB 한 개당 SOM 8개를 연결시킬 수 있기 때문에 보드 한 개당 8개의 교차로 시뮬레이션이 가능 하다. 각 데이터는 1시간 단위로 측정한 결과로 <Fig. 14>부터 <Fig. 17>는 리눅스 환경에서 LCS 지연시간 평가 그래프이다. 윈도우 PC에서와 같이 가로축은 데이터 번호를 뜻하며, 세로축은 해당 데이터의 지연시간 을 나타낸다. 단위는 마이크로초(μs) 이다.

리눅스 OS(Operating System)에서는 지연시간이 나타나는 구간이 일정하게 나타났으며, 이는 OS 특징으로 해석된다. 윈도우 PC버전과는 다르게 하나의 OS에서 하나의 프로그램만 동작시키므로 실행 개수를 증가시 키며 시험하는 방법 대신 횟수를 증가시켜 시험하는 방식으로 검증하였다. 최대 응답 지연시간이 600ms를 넘지 않는 것을 확인 하였으며, 안정적으로 OS가 동작하는 것을 데이터를 통해 알 수 있다. <Table 5>과 같 이 4번의 시험을 통해 응답 지연시간이 1초를 넘기는 데이터는 발생하지 않음을 검증하였고, 임베디드 환경 에서의 평균 응답 지연시간은 안정적으로 동작함을 알 수 있었다.

2. 패킷 송수신 확률 평가

응답 지연시간보다 더 중요한 사항이 패킷데이터 응답 확률이다. LCS는 상태정보를 요청하는 패킷을 전 달받으면 상태정보 패킷을 송신하여야 한다. 송수신 확률이 줄어들수록 데이터의 신뢰성이 떨어지게 된다. 이를 검증하기 위한 테스트를 진행 하였으며 결과는 <Table 6>, <Table 7>와 같다.

<Table 6>을 보면 6개의 LCS를 실행하였을 때부터 데이터 패킷에 대한 신뢰도가 100%미만으로 내려가는 것을 확인 할 수 있다. 7개 실행할 때는 15개의 패킷에 대하여 응답하지 못하였으며, 8개 실행할 때에는 23 개의 패킷에 대하여 응답하지 못하였다. 데이터를 보면 점차 패킷 송수신에 대한 신뢰도가 떨어지는 것을 볼 수 있다. 데이터의 응답지연 뿐만 아니라 데이터 패킷 송수신에서 또한 5개 이하로 실행해야 한다는 사실을 알 수 있는 항목이다. <Table 7>와 같이 리눅스에서 시험한 결과를 보면 임베디드 환경에서는 안정적으로 동 작하는 것을 시험을 통해 알 수 있다.

Ⅳ. 결론 및 향후 연구과제

1. 결론

본 연구는 교통신호센터를 평가하기 위한 시스템인 LCS에 대해 연구를 진행하였다. 윈도우 환경에서와 리 눅스 환경에서의 비교와 앞으로의 확장 가능성에 대한 평가를 진행하였으며, 평가의 결과는 다음 내용과 같 다. 윈도우 환경에서는 6개 이상 LCS를 실행하면 응답 지연시간이 급증하게 되고, 1초 이상의 데이터 패킷의 지연이 발생하기 시작한다. 또한 데이터 패킷의 손실이 발생하는 시점이라는 사실도 시험을 통해 증명하였다. 시험결과에 따라 윈도우 PC에서는 최대 5개의 LCS를 실행 할 수 있다. 수량의 한계가 있음에 따라 큰 용량의 테스트 베드를 모사하기엔 필요한 수만큼 고가의 PC가 추가적으로 필요하기 때문에 부적절하다. 임베디드 리 눅스 환경의 LCS에서는 큰 용량의 테스트 베드에 사용하기 용이하다. LCB하나에 8개의 SOM이 들어가며 하 나의 쉘프에는 16개의 LCB가 연결된다. 따라서 쉘프 하나당 128개의 교차로를 모사할 수 있으며 하프렉 하나 에 3개의 쉘프가 들어갈 수 있다. 하프렉 하나가 총 384개의 교차로를 모사할 수 있는 용량이 완성되는 것이 다. 이와 같이 완성된 결과는 렉 형태의 LCB안에 각각의 1GBit 허브칩이 동작하여 SOM의 수를 증가시키더라 도 패킷응답율의 시험결과는 동일하게 나타났다. 시스템을 구성하기 위한 LCB, LCP, LCBP, SOM등 주변장치 들이 필요하다는 단점이 있지만 77대의 윈도우 PC로 시뮬레이션 하는 것과 같은 용량이다. 이를 통해 소규모 의 도시에서 현장에 적용하기 전 시험하고 싶은 시뮬레이션을 사전에 해볼 수 있는 환경이 완성 된 것이다.

2. 향후 연구과제

본 과제에서 진행한 연구에서는 하나의 LCB에 8개의 SOM을 연결 할 수 있었다. SOM을 8개 이상으로 연 결 하거나 각 SOM에서 두 개 이상의 교차로를 모사 할 수 있다면 더욱더 집약된 형태의 환경이 꾸며질 것 으로 보인다. LCS에 옵션보드를 추가할 수 있는 기능을 확장하여, 앞으로 인공지능 개발에 따른 확장성 있 는 보드와 연계할 수 있는 연구개발이 필요하다.