고속전철 차량간 구성변화의 능동적 적응을 위한 통신규약에 ... · 2010-10-16 · a) Electrical Short Distance(ESD) RS485표준에 따라 차동 전송되는

工學碩士學位論文

고속전철 차량간 구성변화의 능동적 적응을 위한

통신규약에 관한 연구

A study on adaptable configuration protocol

for high speed electric railway vehicles

2003 年 2 月

仁荷大學校大學院

自動化工學科

韓在文


고속전철 차량간 구성변화의 능동적 적응을 위한

통신규약에 관한 연구

A study on adaptable configuration protocol

for high speed electric railway vehicles

2003 年 2 月

指導敎授朴宰賢

이 論文을 工學碩士學位論文으로 提出함

仁荷大學校大學院

自動化工學科

韓在文


本論文을 韓在文 의 工學碩士學位論文으로 認定함

2003年 2月

主番

副番

委員

I

요 약

최근 전동차량을 위한 분산제어 시스템으로 도입되고 있는 TCN(Train

Communication Network)은 차량이 분리되거나 재결합될 때 변화를 능동적

으로 인식하고, 열차 네트워크의 재구성을 지원한다. 다양한 차량구성의

변화와 상호 운용성 확보하기 위한 열차 재구성 기법은 차량구성이 변화되

는 경우에 사용된다. 이때 차량 네트워크를 구성하고 있는 노드들은 차량

구성 변화에 대한 정보와 각각의 노드상태에대한 정보를 공유하게 된다.

계층구조로 이루어진 TCN에서는 게이트웨이 역할을 수행하는 노드에서 차

량간의 정보전달 작업이 수행됨으로써, 데이터의 교환이 가능해 진다.

본 논문에서는 네트워크 상태의 변화에 의해 변경된 네트워크 노드의 재

구성 시, 주기적인 데이터와 비 주기적인 데이터의 전송을 보장할 수 있는

노드간 정보전달 작업과 정보전달을 위한 리스트의 갱신을 지원하는 열차

재구성 정보전달 통신규약을 제안하고자 한다. 이 통신규약을 이용하게 되

면 차량의 구성이 완료됨과 동시에 전동차량에서 제공되는 기능들을 시간

적인 지연없이 사용할 수 있고, 전동차량의 운전자가 차량의 운행전 점검

시 차량의 상태를 운전실에서 모니터를 통하여 시각적으로 확인할 수 있게

된다.

II

Abstract

Recently, The TCN (Train Communication Network) as the distributed

control systems for electric vehicles, which is the international standard of the

intra vehicle communication, actively recognizes variations and supports

reconfigurations of the train network when a vehicle is separated or

recombined. The technique of reconfiguration to take variety and

interoperability of a vehicle constitution is used when the vehicle constitution

is changed. At the time, each node making up vehicle network shares the

information about the variation of vehicle constitutions and the state of nodes.

In the hierarchical TCN structure, an exchange of data becomes available as a

work to transmit information between components is performed at the node

playing a role of gateway.

This thesis proposes a protocol to transmit the information of the train

reconfiguration. The protocol gives an application to renew a list for

transmitting information and to perform the transmission that can guarantee

periodic and non-periodic data transmission between nodes when the network

nodes changed by a variation of the network state are reconfigured. If use

this protocol, can use functions that are offered in the electric railcar at the

same time that composition of vehicles is completed without delay. And when

driver of the electric railcar inspect before running of vehicles, can confirm

state of vehicles visually through monitor in driver's room.

III

제목 차례

1 서론 .................................................................................................................... １

1.1 연구 배경 .................................................................................................. １

1.2 연구 내용 및 논문 구성.......................................................................... ２

2 TCN (TRAIN COMMUNICATION NETWORK)........................................ ３

2.1 MVB(MULTIFUNCTION VEHICLE BUS)의 특성 및 기능........................... ４

2.1.1 MVB의 물리적인 특성 ................................................................... ５

2.1.2 데이터 전송 ...................................................................................... ７

2.2 WTB(WIRE TRAIN BUS)의 특성 및 기능............................................. １０

2.2.1 WTB의 물리적인 특성 ............................................................... １２

2.2.2 데이터전송을 위한 프레임구조 ................................................ １６

2.2.3 전동차 통신 네트워크 재구성 .................................................. ２２

2.2.4 열차 재구성의 조건 .................................................................... ２５

3 능동적 변화적응 프로토콜 구현방법 ...................................................... ３１

3.1 능동적 변화적응 프로토콜의 필요성................................................ ３２

3.2 INAUGURATION DATA 영역의 활용방법................................................ ３２

3.2.1 Frag field ........................................................................................ ３２

3.2.2 Port_count field .............................................................................. ３３

3.2.3 Port_inform field ............................................................................ ３４

3.2.4 CRC (Cyclic Redundancy Check) .................................................. ３５

3.3 능동적 변화적응 프로토콜(ADAPTABLE CONFIGURATION PROTOCOL) ３５

3.3.1 WTB 마스터에서의 Inauguration_data 처리............................. ３５

3.3.2 WTB 슬레이브에서의 Inauguration_data처리........................... ３７

3.3.3 Export_list와 Import_list의 생성................................................. ３９

3.3.4 Inauguration_data 프레임의 에러처리 ....................................... ４０

4 열차 재구성 과정 실험 .............................................................................. ４１

4.1 하드웨어 ................................................................................................ ４１

4.1.1 Intelligent MVB Controller 보드의 개발(IMC4.0) ..................... ４１

IV

4.1.2 Intelligent Gateway Controller 보드의 개발(IGC1.1) ................. ４４

4.2 열차 재구성 실험환경 ......................................................................... ４６

5 결론 ................................................................................................................ ５１

V

그림 차례

그림 1 VEHICLE BUS & TRAIN BUS.......................................................................... ２

그림 2 TCN의 계층구조[1]...................................................................................... ４

그림 3 ELECTRICAL SHORT DISTANCE MEDIUM[1]..................................................... ５

그림 4 ELECTRICAL MIDDLE DISTANCE MEDIUM[1] .................................................. ６

그림 5 OPTICAL MEDIUM[1] ....................................................................................... ６

그림 6 BUS CONTROLLER[1]..................................................................................... ７

그림 7 멘체스터 코드로 변환된 데이터[1][3] ..................................................... ８

그림 8 마스터 프레임[1]......................................................................................... ８

그림 9 슬레이브 프레임[1]..................................................................................... ９

그림 10 텔레그램[1] ................................................................................................ ９

그림 11 WTB의 TOPOLOGY .................................................................................. １１

그림 12 WTB CABLE ARRANGEMENT(TOP VIEW)[1] .............................................. １３

그림 13 WTB MAU WITH DUPLICATED LINE_UNIT[1] .......................................... １４

그림 14 DOUBLE-LINE ATTACHMENT ................................................................... １５

그림 15 GROUNDED SHIELD CONCEPT.................................................................... １５

그림 16 FLOATING SHIELD CONCEPT ...................................................................... １６

그림 17 WTB BIT ENCODING ................................................................................. １６

그림 18 WTB SIGNAL ENCODING........................................................................... １７

그림 19 WTB FRAME (EXTENDED ISO/IEC 3309)................................................. １７

그림 20 WTB TELEGRAM ...................................................................................... １８

그림 21 WTB PROCESS_DATA TELEGRAM............................................................. １９

그림 22 WTB MESSAGE_DATA TELEGRAM ........................................................... ２０

그림 23 SUPERVISORY_DATA TELEGRAM............................................................... ２０

그림 24 WTB PERIODIC AND SPORADIC TRANSMISSION........................................ ２１

그림 25 SUMMARY OF FRAME FOR REGULAR OPERATION[1][3].............................. ２２

그림 26 열차 재구성의 조건[1] ......................................................................... ２６

그림 27 NORMAL OPERATION (MAIN CHANNEL) ..................................................... ２７

그림 28 DETECT REQUEST TO ANOTHER NODE (AT END NODE) .............................. ２７

그림 29 DETECT RESPONSE FROM ANOTHER NODE (AT END NODE)........................ ２７

VI

그림 30 UNNAMING ............................................................................................... ２８

그림 31 DETECTING NEW NODE............................................................................. ２８

그림 32 STATUS AND DETECTION ........................................................................... ２９

그림 33 SET TO INTERMEDIATE .............................................................................. ２９

그림 34 NAMING.................................................................................................... ３０

그림 35 TOPOGRAPHY REQUEST & TOPOGRAPHY RESPONSE[1] ............................ ３１

그림 36 INAUGURATION DATA영역의 정의 .......................................................... ３２

그림 37 WTB 마스터에서의 정보전달 PROTOCOL 순서도.............................. ３６

그림 38 WTB 슬레이브에서의 정보전달 PROTOCOL 순서도.......................... ３８

그림 39 EXPORT_LIST & IMPORT_LIST 구성과정 ................................................. ３９

그림 40 IMC4.0의 블록다이어그램.................................................................... ４２

그림 41 IMC4.0 과 VME 브리지........................................................................ ４３

그림 42 IMC4.0 WITH VME BRIDGE...................................................................... ４３

그림 43 WTB용 IP 모듈의 블록다이어그램 .................................................. ４４

그림 44 WTB용 IP모듈........................................................................................ ４５

그림 45 WTB용 GATEWAY보드............................................................................ ４５

그림 46 TRANSMISSION OF PERIODIC_DATA THROUGH THE NETWORK[1] ............. ４６

그림 47 열차 재구성 시험환경.......................................................................... ４７

그림 48 WTB 통신을 위한 마스터 프레임 & 슬레이브 프레임 ................... ４８

그림 49 두번째 노드가 추가되었을때의 WTB 프레임 .................................. ４９

그림 50 한국형 고속전철에 장착된 GATEWAY의 모습 (A)............................. ５０

그림 51 한국형 고속전철에 장착된 GATEWAY의 모습 (B)............................. ５０

VII

표 차례

표 1 F-CODE와 텔레그램 ................................................................................... １０

표 2 MODE FIELD ................................................................................................. ３３

1

1 서론

1.1 연구 배경

고속전철과 같은 전동차 시스템에서 분산환경의 실시간 제어, 온라인 감

시, 자가진단, 승객 정보서비스 등 다양한 기능을 수행하기 위해서 전동차

내의 차량 네트워크는 분산된 다양한 제어기들 사이의 빠르고 정확한 정보

의 교환을 보장해야 한다. 그러나 전동차용 네트워크라는 특징 때문에 차량

내의 하나의 데이터 버스를 분산되어 있는 간단한 I/O기기부터 지능형 스테

이션까지 공유해야 하고, 데이터 서비스에 있어서는 제어 신호같이 시간제

약성이 큰 데이터와 시간제약성은 적지만 사이즈가 큰 데이터를 동시에 처

리 할 수 있는 능력이 있어야 한다. 또 차량의 연결이나 차량구성이 변화되

었을 때 이를 지능적으로 감지해서 변화된 환경에 맞는 서비스를 보장해야

한다. 이러한 요구를 만족시키기 위하여 IEC(International Electrotechnical

Commission)에서는 차량간 혹은 차량내의 전자장치들의 상호 운용성

(Interoperability)을 목적으로 TCN(Train Communication Network)을 통신 프

로토콜 표준으로 정했다[1][3][4].

TCN은 그림 1에서 보는바와 같이 MVB(Multifunction Vehicle Bus)와

WTB(Wired Train Bus)의 이중 계층구조로 구성된다. MVB는 차량내의 디바이

스들을 연결하고 WTB는 차량간의 노드들을 연결하는 버스이다[1][3][4]. 이

러한 2계층의 구조로 이루어진 전동차의 구성은 고정적이지 않고 상황에

따라 각 차량의 연결이 변화될 수 있는데, 이때 MVB상의 디바이스의 구성

은 변화하지 않고, 단지 WTB상의 노드들의 구성만 변화하게 된다. 본 논

문에서는 이러한 전동차의 구성 변화 시 WTB상의 노드들간에 이루어지는

동적인 주소할당을 바탕으로, 변화된 노드의 구성에서 이루어져야할 주기적

또는 비 주기적 데이터 전송을 보장하기 위한 노드간 정보 전달 작업과 정

보전달을 위한 리스트의 갱신을 지원하는 전동차 재구성정보 전달 통신규

약을 구현하고자 한다[1][2][3][4][5].

2

그림 1 Vehicle bus & Train Bus

1.2 연구 내용 및 논문 구성

본 논문에서는 차량구성의 변화가 있을 때 능동적으로 그 변화를 인지하

고 그에 따른 적절한 재구성 과정을 수행함으로써 전동차의 안정성과 지능

성을 보장하는 전동차 재구성정보 전달 통신규약을 제안 및 구현하고, 그에

따른 실험결과를 보이려 한다. 본 논문의 구성은 2장에서 전동차 내부 네트

워크를 구성하고 있는 MVB(Multifunction Vehicle Bus) 와 전동차간의 네트워

크를 구성하는 WTB(Wire Train Bus)에 대한 내용을 기술하고, 3장에서는 차

량의 구성변화에 따라 능동적이고 지능적인 대처를 위한 전동차 네트워크

재구성 정보전달을 위한 통신규약의 내용을 설명하고, 4장에서는 3장에서

제안한 알고리즘의 구현에 따른 실험을 보인다. 5장에서는 실험결과의 분석

과 향후 연구방향을 언급한다.

3

2 TCN (Train Communication Network)

고속전철과 같은 극한기술이 요구되는 시스템을 위한 네트워크 시스템이

갖추어야 할 여러 요소들을 고려하면 실시간 분산제어를 위한 실시간성, 이

중구조 등의 내고장성과 안정성, 다양한 데이터 전송을 위한 유연성 등이

요구되므로 기존의 필드버스나 LAN 등과는 다른 특성을 가지고 있어야 한

다. TCN은 이러한 요구사항을 만족하기 위해서 IEC(International Electro-

technical Commission)에 의해서 제정된 전동차 네트워크 표준이다. TCN은

계층적 구조를 갖는 두가지 버스구조로 되어있다[1][3][5].

a) WTB Bus

• UIC 열차와 같은 Open Train에서 차량간을 연결

• 1 Mbit/s의 데이터 전송속도

• Self-configuration능력

b) MVB Bus

• 차량 내부 기기간의 연결

• 빠른 반응을 요하는 장치에 적합

• 1. 5 Mbit/s의 데이터 전송속도

TCN의 구조에서 모든 버스들은 동일한 실시간 프로토콜을 공유하게 된다.

이 프로토콜은 다음의 두가지 통신 서비스를 제공한다.

• 브로드케스팅을 통한 Process Variable의 주기적인 갱신

• 유니케스트(Point to Point) 또는 멀티케스트를 통한 메시지 전송

TCN의 구조는 그림 2에서 보는바와 같이 ISO/IEC 7498-1에 정의된 개방

형 시스템의 내부연결 모델과 비슷한 구조를 가지고 있다.

4

그림 2 TCN의 계층구조[1]

다음 2.1절과 2.2절에서는 TCN을 이루고 있는 MVB와 WTB의 특성과 기

능에 대한 내용을 보기로 한다.

2.1 MVB(Multifunction Vehicle Bus)의 특성 및 기능

MVB는 전동차량내부의 데이터 전송을 위한 버스 구조를 가지고 있다. 전

동차 내부의 여러 제어기기와 센서, 추진과 제동의 콘트롤러등 분산되어있

는 기기간의 통신을 위한 버스로서 내부적으로는 각 기기간의 연결을 담당

하고 객차간을 연결하는 WTB와 게이트웨이를 통해서 연결되게 된다. MVB

상에서 취합된 데이터 중 다른 객차로 전송 될 필요가 있는 데이터는 MVB

를 통해 WTB와 연결되어있는 MVB 유닛에 전송되고 이 정보는 WTB를 통

해서 객차간을 이동하게 된다.

5

2.1.1 MVB의 물리적인 특성

데이터가 분산되어있는 각 콘트롤러와 센서등의 기기들로부터 시스템 마스

터까지 전달되기 위한 첫번째 매채인 MVB는 전달매체에 따라 세가지형태

로 나뉘어 진다.

a) Electrical Short Distance(ESD)

RS485표준에 따라 차동 전송되는 Twisted pair로된 통신선을 사용하는 형

태로 세그먼트당 최대 32개의 장치들을 20m까지 전송보장.

그림 3 Electrical Short Distance medium[1]

b) Electrical Middle Distance(EMD)

철도선로에서 빈번하게 체결되거나 분리되는 차량구성에 적합한 형태로

shielded Twisted pair로된 통신선을 사용하고 세그먼터당 최대 32개의 장치

들을 200m까지 전송보장.

6

그림 4 Electrical Middle Distance medium[1]

c) Optical Glass Fiber(OGF)

전자기적인 간섭이 심한 환경에서 사용될 수 있는 형태로 2.0km까지의

전송보장.

그림 5 Optical medium[1]

이상에서 보인 세가지의 형태중 현재 한국형 고속전철개발사업에 적용된

것은 EMD의 형태로 트렌스포머를 사용한 연결이다. 이러한 네트워크에서

버스를 제어하게되는 버스컨트롤러가 존재하게 되는데, 이 버스컨트롤러의

역할은 같은 세그먼트내에 있는 디바이스들간의 데이터전송의 제어를 맡게

된다. 버스컨트롤러의 형태는 그림 6과 같은 구조로 되어 있다. 전송채널과

수신채널이 이중화로 되어있어 버스의 안정성을 보장하고 있다. 버스컨트롤

러의 구조는 데이터 저장소를 제어하기위한 로직과 엔코더와 디코더를 포

함하고 있다.

7

Send register Receive register

encoder decoder decoder

device status register

12 bitdevice

addressregister

Bus Controller

CPU Parallel Bus To Traffic Store

Address data control

selector carriersense

carriersense

A AB B

transmitters receivers

Bus pair A

Bus pair B(redundant)

Send register Receive register

encoder decoder decoder

device status register

12 bitdevice

addressregister

Bus Controller

CPU Parallel Bus To Traffic Store

Address data control

selector carriersense

carriersense

A AB B

transmitters receivers

Bus pair A

Bus pair B(redundant)

그림 6 BUS Controller[1]

2.1.2 데이터 전송

2.2.1절에서 보았던 물리적 매체를 통하여 MVB통신이 이루어지게 되는데,

MVB상의 모든 개체들은 1.5Mbit/s의 전송 속도로 통신을 하게 된다[1]. 전

송 되는 데이터는 클럭과 하나의 데이터시그널이 조합되어 전송되는데, 이

러한 데이터는 멘체스터코딩 방식을 사용한다. 다음 그림 7은 데이터가 멘

체스터코드로 변화되어 전송될때의 프레임형태를 보여준다. 이 프레임의 형

태를 보면 데이터 비트들과 구분하기 위한 시작 경계기호(Start Delimiter)와

데이터, 8비트 체크시퀀스, 그리고 끝 경계기호(End Delimiter)로 구성되어

있다.

8

Data

Clock

Line Signal

10 2 3 4 5 6 7 8

1 1 0 1 0 0 1

9bit Start_Delimiter Frame_Data8-bit Check_Sequence

End_Delimiter

Data

Clock

Line Signal

10 2 3 4 5 6 7 8

1 1 0 1 0 0 1

9bit Start_Delimiter Frame_Data8-bit Check_Sequence

End_Delimiter

그림 7 멘체스터 코드로 변환된 데이터[1][3]

시작 경계기호는 두가지 형태가 있는데, 마스터프레임 시작 경계기호와

슬레이브프레임 시작 경계기호이다.

2.1.2.1 마스터 프레임

마스터프레임은 그림 8에서 보는바와 같이 33비트의 고정된 길이를 가지

고 있고, 단지 버스 마스터에 의해서 전송된다.

Master Start Delimiter F-code Address Check Squence

9bit 4bit 12bit 8bit

Master Start Delimiter F-code Address Check SquenceMaster Start Delimiter F-code Address Check Squence


그림 8 마스터 프레임[1]

MVB상의 모든 디바이스들은 마스터프레임을 해석하고, 어드레스필드에

해당하는 디바이스들은 슬레이브프레임을 전송하게 된다. 이 슬레이브프레

임은 MVB상의 몇몇 디바이스들이 받아서 사용할 수 있다.

2.1.2.2 슬레이브 프레임

슬레이브 프레임은 데이터의 사이즈에 따라 33,49,81,153,297bit의 다양한

길이를 가질 수 있다. 그림 9와 같이 슬레이브프레임도 마스터프레임과 비

슷한 구조를 가지고 있다.

9

SSD Data CS CSData CSData CSData

CSDataSSD Data CS

SSD Data CS

SSD Data CS

SSD Data CS

9bit

9bit

9bit

9bit

9bit

16bit

32bit

64bit

64bit


64bit

8bit

8bit

8bit

8bit 8bit

8bit 8bit 8bit 8bit

SSD : Start Slave Delimiter

CS : check Secquence

SSD Data CS CSData CSData CSData

CSDataSSD Data CS

SSD Data CS

SSD Data CS

SSD Data CS

9bit

9bit

9bit

9bit

9bit

16bit

32bit

64bit

64bit


64bit

8bit

8bit

8bit

8bit 8bit

8bit 8bit 8bit 8bit

SSD : Start Slave Delimiter

CS : check Secquence

그림 9 슬레이브 프레임[1]

9bit 슬레이브 시작 경계기호와 16,32,64,128,256bit의 데이터, 8bit의 체크

시퀀스로 구성되어 있다.

2.1.2.3 MVB 텔레그램

이렇게 두가지 종류의 프레임, 마스터 프레임과 슬레이브프레임이 한쌍을

이루어 텔레그램을 형성하게 된다. 텔레그램의 형태는 그림 10과 같다.

MSD F-code Address CS


ED SSD CS

9bit

EDData

16…256 + CS 8bit

MSD

Telegram

Master_frame Slave_Frame

22uS 2uS..43uS 22,33,54,102 or 198 uS 2uS..43uS

Next Master_frame

MSD = Master_ Start_ Delimiter SSD = Slave_Start_DelimiterED = End_Delimiter CS = Check Sequence

MSD F-code Address CS


ED SSD CS

9bit

EDData

16…256 + CS 8bit

MSD

Telegram

Master_frame Slave_Frame

22uS 2uS..43uS 22,33,54,102 or 198 uS 2uS..43uS

Next Master_frame

MSD = Master_ Start_ Delimiter SSD = Slave_Start_DelimiterED = End_Delimiter CS = Check Sequence

그림 10 텔레그램[1]

텔레그램은 마스터프레임에 있는 F-Code에 따라 16개의 형태가 있다.

10

Telegram type

Process_Data_Request with size 16bits





F-Code

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

(reserved)

(reserved)

(reserved)

Mastership_Transfer_Requst

General_Event_Requst

(reserved)

(reserved)

Message_Data_Request with 256bits

Group_Event_Request

Single_Event_Request

Device_Status_Request

Telegram type






F-Code

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

(reserved)

(reserved)

(reserved)

Mastership_Transfer_Requst

General_Event_Requst

(reserved)

(reserved)

Message_Data_Request with 256bits

Group_Event_Request

Single_Event_Request

Device_Status_Request

표 1 F-Code와 텔레그램

MVB는 마스터프레임을 보내도록 설정된 하나의 마스터 디바이스에 의해

제어되고, 모든 다른 디바이스들은 슬레이브로 동작하게 된다. 그리고 몇몇

디바이스들은 마스터의 역할을 이양받을 수 있는 능력을 가질 수 있다. 마

스터디바이스는, MVB네트워크상에 어느 장소에든 위치할 수 있다.

2.2 WTB(Wire Train Bus)의 특성 및 기능

초기의 차량간 통신버스는 시리얼 통신버스로 개발이 되었다. 그 후 국제

적인 UIC 열차와 같은, 일상적인 기능을 수행하는 도중 열차를 재구성할 수

있는 열차 재구성을 위한 기능이 추가 개발되었다.

차량간 통신버스에서는 UIC 차량 22량까지 구성하고 이를 지원하는 통신

규약인 UIC leaflet 556의 요구조건을 이행하는 것에 대해 명시하고 있다[2].

11

차량간 통신버스의 구조는 그림 11과 같이 각 차량에 차량간 통신을 지

원하는 노드와, 이 노드간을 연결하는 케이블로 구성되어 있다. 이 노드들

사이에서 통신을 차량간 통신이라 한다.

그림 11 WTB의 topology

차량간 통신버스는 twisted, shielded wire pair 케이블을 이용하여 데이터를

1Mbit/s로 전송하며, 860m 길이 내에서 32개 node까지 지원한다. 그리고 필

요에 따라서는 리피터를 사용하여 최대 62개의 노드까지 사용한다[1].

정상 동작 상태에서 열차를 구성하고 있는 차량 내 노드들은 열차의 양

종단에 있는 경우 End_Node가 되며, 그 외의 노드들은 Intermediate_Node

가 되어 차량간 통신을 한다. 각 노드들은 2개의 채널을 가지고 있는데, 정

상적인 데이터의 전송을 위한 메인 채널과 열차의 재구성 등을 파악하기

위한 보조 채널이 있다. 열차의 양 종단에 있는 End_Node의 메인 채널에는

terminator가 연결이 되나, 열차 내부의 Intermediate_Node의 메인 채널에는

terminator가 연결이 되지 않는 채 차량간 통신에 참여하게 된다. 열차의 양

종단에 있는 노드에서만 활성중인 보조 채널을 통하여 새로운 노드를 찾는

작업, 열차의 재구성을 검지 하는 작업이 이루어진다. 만약 열차의 재구성

이 확인이 되면 이를 확인한 노드는 마스터에게 이를 통보하고, 마스터는

열차 재구성이 가능하면 열차를 새로운 구성에 맞추어 재구성하게 된다.

차량간 통신 버스는 하나의 마스터에 의해 운영이 되며, 이 마스터에 의

하여 열차 제어 신호의 전송을 위해 사용하는 Process_Data와 전동차량의

운행중 서비스를 위한 승객정보와 같은 비정기적이고 크기가 큰

Message_Data의 전송, 그리고 열차의 노드 관리를 위한 Supervisory Data의

12

전송이 이루어진다. 열차를 구성하고 있는 노드가 정상상태에서 동작할

경우에는 마스터 권한의 이양은 일어나지 않으며, 열차의 재구성이나 기존

마스터의 고장이 발생할 경우 마스터 권한의 이양은 열차 재구성이라는 과

정을 거쳐 발생하게 된다.

차량을 구성하고 있는 노드들은 마스터에 의해 노드 아이디를 할당받게

되므로 열차 재구성 등으로 인한 마스터권한의 이양은 모든 노드들이 새로

운 노드 아이디를 할당받게 됨을 의미한다. 하나의 차량간 통신 버스 내에

는 하나의 마스터만이 존재할 수 있기에 마스터 노드는 하나이지만 다른

여러 노드들도 열차재구성을 통해 마스터가 될 능력을 가지고 있다.

2.2.1 WTB의 물리적인 특성

2.2.1.1 특 징

차량간 통신버스는 shielded, twisted wire pair로 구성된 케이블을 이용하여

UIC 구성인 26m짜리 열차 22량과 50%정도의 여유를 갖는 길이인 860m

범위 내에서 1Mbit/s의 전송속도로 노드간에 데이터가 전송되며 차량 내 1

개 이상의 노드가 존재한다면 열차 내에서는 32개 노드까지 지원될 수 있

다[1][2].

차량과 차량간의 연결은 automatic coupler 또는 hand-plugged cable을 이

용하며 차량은 그 방향을 예측할 수 없기에 전기적 배선들은 차량의 각 종

단에서 나누어져 있고, 차량이 연결이 될 때 양 차량에 있는 두 배선이 연

결되며, 적어도 하나만 연결이 되어도 동작한다. 이와 같은 구조를 나타낸

것이 그림 12이다.

13

WTB node WTB nodeconnector

jumper cablevehicle vehicle

UIC linesLine_A Line_A

Line_BLine_B

e.g. UIC lines

2 2 11WTB node WTB nodeconnector

jumper cablevehicle vehicle

UIC linesLine_A Line_A

Line_BLine_B

e.g. UIC lines

2 2 11

그림 12 WTB cable arrangement(top view)[1]

2.2.1.2 노드의 구성

노드는 Medium Attachment Unit (MAU)를 통해 전송매체에 접근하며 MAU

는 Line Unit, Direction Commutator, Main Channel, Auxiliary Channel로 구성되

어 있다. Line Unit은 Bus_switch, Terminator_switch, Transceiver, Manchester

encoder/decoder, protection circuit으로 구성되어 있다. Direction Commutator

는 Main Channel, Auxiliary Channel를 direction 1 또는 direction 2에 연결하는

역할을 한다. Main Channel, Auxiliary Channel를 통해 HDLC frame과 제어신

호를 Line unit에 보내고 받게 된다. 이와 같은 구조를 나타낸 것이 그림 13

이다.

노드는 하드웨어 상에서 bus switch와 terminator switch의 스위치 제어에

의해 Intermediate_Node 또는 End_Node가 된다. End_Node 경우에는

Bus_Switch를 열어 놓고, Terminator_Switch를 닫음으로서 Main Channel은

내부 방향으로 연결시킴으로써 차량간 버스 통신을 하며, 활성화된

Auxiliary Channel는 열차 외부 방향으로 노출되어 있고, 새로운 노드의 검색

에 사용된다. Intermediate_Node의 경우에는 Terminator_Switch를 열어두고,

Bus_Switch를 닫음으로써 버스를 연결하게 되며 Main Channel만이 활성화되

어 차량간 버스 통신에 참여하며, Auxiliary Channel은 새로운 노드 검색이외

의 데이터 프레임에 대해 무시한다.

14

transceivers

encoder decoder encoder decoder

Terminator S/W

Main_channel auxiliary_channel

Direction_Commutator

Channel 1 Channel 2

Line_Unit A1 Line_Unit A2TxS TxE RxS RxSTxS TxE

X Y X Y

Zt2Zt1Kt2Kt1

bus switchKb

Direction_1 Direction_2

++ - -transceivers

encoder decoder encoder decoder

Terminator S/W

Main_channel auxiliary_channel

Direction_Commutator

Channel 1 Channel 2

Line_Unit A1 Line_Unit A2TxS TxE RxS RxSTxS TxE

X Y X Y

Zt2Zt1Kt2Kt1

bus switchKb

Direction_1 Direction_2

++ - -

그림 13 WTB MAU with duplicated Line_Unit[1]

2.2.1.3 통신라인의 이중화

차량간 통신버스 노드는 그림 14에서 보는 바와 같은 Line_Unit A와

Line_Unit B의 이중화 구조를 가진다. Medium_Attachment_Unit(MAU)도

Line_Unit A와 Line_Unit B에 대하여 각 방향에 대해 두 개의 transceiver를

가지고 있다. 이 구조에서는 각각의 Line_Unit에서 나오는 Carrier_sense

(CS)와 Signal_Quality_Error (SQE)를 가지고 Switchover_logic에서 trusted

line를 선택하며 신호를 받아들인다.

15

Line_Unit B

Line_Unit A

Line_Unit A

Line_Unit B

Line_Unit A

Line_Unit B

node node node

Direction_1 Direction_122 Direction_2 1

1 1 122

B

B BA

A A

Line_Unit B

Line_Unit A

Line_Unit A

Line_Unit B

Line_Unit A

Line_Unit B

node node node

Direction_1 Direction_122 Direction_2 1

1 1 122

B

B BA

A A

그림 14 Double-line attachment

2.2.1.4 Shielding concept

(1) Grounded shiled concept

차량간 버스를 구성하고 있는 노드를 그림 15와 같이 직접 그라운드 처

리를 하며 차량과 차량을 연결하는 곳에선 실드 라인을 연결하지 않아 노

드간에는 연결이 이루어지지 않은 방법이며, UIC558 leaflet를 따른다.

inter-vehicleimpedance


jumperconnector

jumperconnector

vehicle ground vehicle ground vehicle ground

End_Node End_NodeIntermediate_Node(s)terminators



jumperconnector

jumperconnector

vehicle ground vehicle ground vehicle ground

End_Node End_NodeIntermediate_Node(s)terminators

그림 15 Grounded shield concept

(2) Floating shield concept

차량간 버스를 구성하고 있는 노드를 그림 16과 같이 RC 회로를 사용하

여 그라운드 처리를 하며 차량과 차량을 연결하는 곳에선 실드 라인을 연

결하여 노드간 연결이 이루어지지는 방법이다.

16

End_Node End_NodeIntermediate_Node(s)



terminatorsJumper cable &

connector

RsRs Rs

Cs Cs Cs

End_Node End_NodeIntermediate_Node(s)



terminatorsJumper cable &

connector

RsRs Rs

Cs Cs Cs

그림 16 Floating shield concept

2.2.2 데이터전송을 위한 프레임구조

2.2.2.1 Signaling

차량간 버스 상에서 전송되는 데이터는 Manchester code로 변환되어 전송

이 이루어진다. 그림 17과 같이 “1”은 cell 중간에서 positive transition을 가

지고 “0”은 cell 중간에 negative transition을 가진다.

1.0 BT

0.5 BT 0.5 BT

1.0 BT

“1” “0”

Positive

Negative

TxS

1.0 BT

0.5 BT 0.5 BT

1.0 BT

“1” “0”

Positive

Negative

TxS

그림 17 WTB Bit encoding

그림 18에서 보는 바와 같이 각 프레임은 스타트 비트 1에 16 에서 32

bit동안은 0 과 1 이 반복되다가 마지막에 1 로 끝나는 Preamble과 2비

트 동안에 1을 유지하는 End_Delimiter가 데이터의 서두와 끝에 첨가가 되

어 구성된다.

17

HDLC FRAME

CLOCK

LINE SIGNAL

Preamble Flag FlagFrame_Data

End_

delimiter

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0000000 0 0 0 0

HDLC FRAME

CLOCK

LINE SIGNAL

Preamble Flag FlagFrame_Data

End_

delimiter

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0000000 0 0 0 0

그림 18 WTB Signal encoding

2.2.2.2 프레임 구조

모든 프레임의 구조는 HDLC (ISO/IEC 3309) 형태인 그림 19처럼 되어 있

다. 각 프레임은 preamble이 서두에서 시작되며 끝에 End Delimiter가 붙는

다. Preamble과 End Delimiter는 Manchester 인코더에 의해서 첨가되고,

Manchester 디코더에 의해서 제거된다. Preamble의 길이는 16 또는 32 bit를

가지나 기본은 16bit이다. Preamble 과 End Delimiter는 Frame_Data에 속하

지는 않는다.

Flag DD LC SD SZPreamble DD FCS-16 Flag ED

(16..32)

destination_devicelink_controlsource_devicelink_data_size

Frame_Data

HDLC_Data

Link_Data

0 .. 1024 bits

(2)8 8 8 8 8 816

(Stuffed bits are not counted)

Flag DD LC SD SZPreamble DD FCS-16 Flag ED

(16..32)

destination_devicelink_controlsource_devicelink_data_size

Frame_Data

HDLC_Data

Link_Data

0 .. 1024 bits

(2)8 8 8 8 8 816

(Stuffed bits are not counted)

그림 19 WTB Frame (extended ISO/IEC 3309)

Frame_Data는 8bit의 프레그(01111110)에 의해서 그 범위가 정해진다.

HDLC_Data는 8bit에 Destination_Device로 시작이 되며 이것은 현재 프레임

이 향하는 목적지 노드(또는 브로드케스팅)를 나타내는 것으로 HDLC 콘트

18

롤러에 의해서 디코딩 된다. 다음에 오는 8bit의 Link_Control은 WTB에서

미리 정해진 작업을 위해 정의가 되어있다. Source_Device는 이 데이터 프

레임이 전송되는 곳의 주소를 가리키며, Size는 Link_Data에 해당하는 부분

의 데이터 크기를 8진수로 나타낸다. Link_Data 뒤에 따르는 16bit의

Frame_Check_Sequence는 HDLC와 동일한 것으로 오류를 찾아내는데 이용

된다. 마지막에는 8bit에 End_Delimiter가 Manchester 인코더에 의해서 첨가

되고 Manchester 디코더에 의해서 제거된다.

Link_Data의 구성은 UIC556 leaflet를 따라 그 내용이 구성된다[2]. 시스템

제어 등과 같이 긴급성과 주기성을 요하는 데이터는 Process_Data로 구성되

어 전송을 하며, 비 주기적이고 크기가 큰 데이터는 Message_Data로 구성

되어 전송을 하게 된다.

2.2.2.3 WTB 텔레그램

차량간 통신을 하기 위해 마스터는 슬레이브들(하나 또는 여러 슬레이브)

에게 Master_Frame을 전송한다. 마스터 프레임을 받아 선택된 슬레이브는

이에 대한 응답으로 해당되는 Slave_Frame을 내보내며, 이때 Master_Frame

과 Slave_Frame은 모두 브로드케스팅을 하게된다. 이와 같은 하나의 통신과

정(Master_Frame과 Slave_Frame)을 Telegram이라고 하고 그림 20에 나타내

었다.

Flagpreamble FCS Flag preambleFlagpreamble FCS Flag

Telegram

Master_Frame(poll)

Slave_Frame(response)

End_Deliniter End_Deliniter Next poll

HDLC_Data HDLC_Data

64us .. 300us 64us .. 300us

Preamble = 16 bit PreambleFCS = 16 bit frame_Check_Sequence

HDLC_Data = 4 .. 132 octetsFlag = HDLC flag (01111110)

time

Flagpreamble FCS Flag preambleFlagpreamble FCS Flag

Telegram

Master_Frame(poll)

Slave_Frame(response)

End_Deliniter End_Deliniter Next poll

HDLC_Data HDLC_Data

64us .. 300us 64us .. 300us

Preamble = 16 bit PreambleFCS = 16 bit frame_Check_Sequence

HDLC_Data = 4 .. 132 octetsFlag = HDLC flag (01111110)

time

그림 20 WTB Telegram

텔레그램은 그 내용에 따라 세 가지로 구별이 된다[1][3].

• Process_Data Telegrams

• Message_Data Telegrams

• Supervisory_Data Telegrams

19

(1) Process_Data Telegram

마스터가 Process_Data 전송을 위하여 노드를 폴 하면, 폴 된 노드는

Slave_Frame을 브로드케스팅함으로써 Process_Data 의 전송이 이루어진다.

이와 같은 구조를 그림 21에 나타내었다. WTB상에 있는 노드들은

Slave_Frame이 브로드케스팅될 때 Process_Data를 전송 받아 각 노드에 있

는 포트를 갱신하게 되며, 이중 원하는 데이터를 찾는다. 한 노드에서 보내

는 Process_Data 프레임은 고정된 형식을 따른다. 만약 Master가

Process_Data를 보내고자 할 때에도 먼저 Master_Frame을 보낸 후

Slave_Frame을 보낸다. 이와 같은 것을 self_poll이라고 한다.

Size=0

SD=01

LC=PDDD sizeSDLC

=PDall

=FF NT NV

Destination

_Device

(polled)

Source

_Device

(master)

Destination

_Device

(broadcast)

Source

_Device

(polled)

Master_Frame(poll)

Slave_Frame(broadcast response)

up to 1024 bit of Process_Data

Link_Control = Process_Data

time

Key – The shaded areas enclosing the frames represent the Preamble, Flags, Check_sequence and End_Delimiter

Size=0

SD=01

LC=PDDD sizeSDLC

=PDall

=FF NT NV

Destination

_Device

(polled)

Source

_Device

(master)

Destination

_Device

(broadcast)

Source

_Device

(polled)

Master_Frame(poll)

Slave_Frame(broadcast response)

up to 1024 bit of Process_Data

Link_Control = Process_Data

time

Key – The shaded areas enclosing the frames represent the Preamble, Flags, Check_sequence and End_Delimiter

그림 21 WTB Process_Data Telegram

(2) Message_Data Telegram

Master에서 Message List를 근거하여 Message_Data를 위한 Master_Frame

이 전송되면 폴 된 노드에서는 메시지를 포함하고 폴 된 노드의 주소와 이

데이터를 받는 주소로 이루어진 Slave_Frame을 내 보내게 된다. 이와 같은

Message_Data 텔레그램을 그림 22에 나타내었다.

이 Slave_Frame은 한 노드(Destination_Node) 또는 브로드케스팅되어 전

체의 노드가 받게 되며, Message_Data는 Process_Data와 달리 그 길이가 고

정되어 있지 않기에 여러 Slave_Frame을 받아야 하나의 데이터가 되는 경

우도 있다. 그리고 보낼 메시지가 없는 경우에는 크기를 0으로 내보낼 수도

있다. 만약 마스터가 Message_Data 을 보내고자 할 때는 Process_Date때와

동일하게 먼저 Master_Frame를 보내고 메시지를 포함하고 있는 해당

Slave_Frame을 내보낸다.

20

sizeSDLC=MDDD sizeSDLC

=MDDD MTC Transport_Data

Destination

_Device

(polled)

Source

_Device

(master)

Destination

_Device

(can be broadcast)

Source

_Device

(polled)

Master_Frame(poll)

Slave_Frame(singlecast or broadcast response)

up to 1024 bit of Message_Data

Link_Control = Message_Data

final

network

address

original

network

address

Message

Transport

Control

time

key = The shaded areas enclosing the frames represent the Preamble,Flags,Check_Sequence and End_delimiter

sizeSDLC=MDDD sizeSDLC

=MDDD MTC Transport_Data

Destination

_Device

(polled)

Source

_Device

(master)

Destination

_Device

(can be broadcast)

Source

_Device

(polled)

Master_Frame(poll)

Slave_Frame(singlecast or broadcast response)

up to 1024 bit of Message_Data

Link_Control = Message_Data

final

network

address

original

network

address

Message

Transport

Control

time


그림 22 WTB Message_Data Telegram

(3) Supervisory_Data Telegram

WTB상에서는 Process_Data와 Message_Data 프레임과 버스의 유지보수를

위한 Supervisory_Data의 전송이 행해진다.

이것도 역시 그림 23과 같이 Master_Frame과 Slave_Frame으로 이루어진

다. Master_Frame이 Destination_Device로 브로드케스팅 될 수 있는데, 이

경우에는 Slave_Frame이 없고 단지 마스터가 Slave_Frame이 전송되어 소비

될 시간동안인 time-out만큼 기다린 후 다음 텔레그램이 이루어지게 된다.

sizeSDLC=SDDD sizeSDLC

=SDDD Supervisory_Data

Destination

_Device

(polled)

Source

_Device

(master)

Master_Frame Slave_Frame

Link_Control = Supervisory_Data

time


Supervisory_Data

Destination

_Device

(can be broadcast)

Source

_Device

(polled)up to 1024 bits up to 1024 bits

sizeSDLC=SDDD sizeSDLC

=SDDD Supervisory_Data

Destination

_Device

(polled)

Source

_Device

(master)


Link_Control = Supervisory_Data

time


Supervisory_Data

Destination

_Device

(can be broadcast)

Source

_Device

(polled)up to 1024 bits up to 1024 bits

그림 23 Supervisory_Data Telegram

2.2.2.4 데이터 전송

모든 노드(Slave)들은 마스터의 폴에 의해서만 데이터 전송을 할 수가 있

다. 노드가 정상적으로 운영되어 차량간 데이터 통신을 하는 경우, 마스터

는 그림 24에서 보는 바와 같이 Periodic_Phase와 Sporadic_Phase로 구성된

Basic_Period를 주기로 동작을 한다. Periodic_Phase동안에 마스터는 열차 재

구성시 구성된 Periodic List를 근거하여 미리 정해진 노드의

21

1 12 2 3 4 5 6 Message_Data 1 12 7 8 9 10 11

12? 12!

Periodic_phase

(poll for Process_data)

Sporadic_phase

(poll for Message_dataand Supervisory_data)

Next Periodic_phase

guard time time

Basic_Period

Master

Polls node#12

Process_data

from slave#12

1 12 2 3 4 5 6 Message_Data 1 12 7 8 9 10 11

12? 12!

Periodic_phase

(poll for Process_data)

Sporadic_phase

(poll for Message_dataand Supervisory_data)

Next Periodic_phase

guard time time

Basic_Period

Master

Polls node#12

Process_data

from slave#12

그림 24 WTB Periodic and Sporadic Transmission

Individual_Period를 주기로 각 노드들을 폴 하여 Process_Data를 전송하게

된다. Basic_Period 중에서 Periodic_Phase가 60%을 넘지 않게 조정이 되어

Periodic List가 구성되며 나머지 시간 동안에 비주기성 데이터

(Message_Data와 Supervisory_Data)의 전송이 이루어지게 된다.

비주기성 데이터의 전송은 Message List와 Supervisory List를 근거하여 이

루어지며 이 리스트들은 이전에 전송된 Slave_Frame 중의 Link Control를 근

거로 갱신된다. 만약 열차 재구성 등으로 인하여 차량 구조 환경이 바뀌게

되면 이를 인지한 End_node는 이를 자신의 전송 주기에 맞추어 마스터에

알리고 이 데이터를 받은 마스터는 열차 재구성을 통해 노드의 주소를 재

설정, Periodic List를 재구성 등을 하게 된다.

Basic_Period는 25ms로 고정이 되어있으며, 노드의 주기 또한 이

Basic_Period의 배수로 표현이 된다. 따라서 Process_Data의 주기

는 Basic_Period의 배수로 표현된다. 차량의 증가는 구성 노드의 증가를 가

져오기 때문에 노드 수의 증가에 의해 전송해야할 Process_Data의 수가 증

가하게 되어 Periodic_Phase의 영역이 증가하게 되고 그로 인하여

Sporadic_Phase가 감소한다. 그러므로 각 노드의 Process_Data 전송 주기를

최적화 시킬 필요가 있으며 만약 전송해야 할 Process_Data의 양이 많아

Periodic_Phase가 60%를 넘게 되면 가장 긴 주기를 가지는 노드의 주기를

2배로 함으로써 60%를 넘지 않도록 조정하게 된다.

마스터는 비주기성 데이터 전송을 위해서 이전에 전송된 Process_Data와

22

Message_Date의 전송 시 첨부되는 Link Control 비트를 체크함으로써 전

송을 원하는 노드 FIFO의 방식으로 Message List와 Supervisory List를 작성

하게 되며 이를 근거로 노드들은 순서대로 폴 하게 된다. 이때 남은 시간보

다 보낼 데이터의 양이 큰 경우 경우에는 다음 Basic_Period의

Sporadic_Phase에서 폴 해서 전송하게 된다.

2.2.2.5 유효한 프레임

그림 25은 정상동작의 상황하에서 전송되는 Master_Frame과

Slave_Frame을 정리한 것이다.

DD LC SD=01 SZ optional Process_Data

DD=FF LC SD

=01 SZ Process_Data

DD=FF LC SD SZ

=0No process data

DD LC SD=01 SZ

DD LC SD SZ Message_Data

DD LC SD SZ No message data


Process_Data_Request Process_Data_Response

Message_Data_Request Message_Data_Request

DD LC SD=01 SZ MR LS MT DD

=FF LC SD SZ NR RS

Presence_Request Presence_Response

keyDD = Destination DeviceSZ = Link_Data size in octetsLC = Link_ControlSD = Source DeviceFF = broadcast address

LS = Local StrengthMR = Master ReportMT = Master Topo_CounterRS = Remote StrengthNR = Node Report

DD LC SD=01 SZ optional Process_Data

DD=FF LC SD

=01 SZ Process_Data

DD=FF LC SD SZ

=0No process data

DD LC SD=01 SZ

DD LC SD SZ Message_Data

DD LC SD SZ No message data


Process_Data_Request Process_Data_Response

Message_Data_Request Message_Data_Request

DD LC SD=01 SZ MR LS MT DD

=FF LC SD SZ NR RS

Presence_Request Presence_Response

keyDD = Destination DeviceSZ = Link_Data size in octetsLC = Link_ControlSD = Source DeviceFF = broadcast address

LS = Local StrengthMR = Master ReportMT = Master Topo_CounterRS = Remote StrengthNR = Node Report

그림 25 Summary of frame for regular operation[1][3]

2.2.3 전동차 통신 네트워크 재구성

2.2.3.1 전동차 통신 네트워크 재구성의 목적

최근의 전동차는 인간중심적인 기능을 보유하고 있으면서, 사용자의 편의

와 고객의 편리성을 보장하면서, 안정적인 운행을 필요로하게 되었다. 이러

23

한 전동차의 기능을 만족하기 위하여 전동차 제어시스템에 실시간성을 보

장할 수 있는 통신 네트워크를 적용하게 되었다[21]. 이러한 통신 네트워크

를 바탕으로 전동차의 구성이 변경될 때, 즉 이미 구성되어있는 차량에 새

로운 차량이 추가되거나 어떤 원인에 의해 구성된 차량이 제거되어 네트워

크의 변화가 생기게 되면, 네트워크의 마스터는 열차 재구성(inauguration)

의 절차를 거쳐 이러한 변화를 인지하고 능동적으로 새로운 네트워크구조

를 갱신하고 그에따른 데이터의 전송구조를 변경할 수 있어야한다.

열차 재구성 시 차량의 종단에 있는 각 노드들은 End_node가 되며 이 노

드에 있는 메인 채널에는 terminator를 붙이게 되며 내부의 노드들은 전기

적으로 케이블을 연결시킴으로써 각 노드들을 연결하게 된다. 각각의 노드

는 마스터로부터 할당받은 주소를 통해 WTB 내에서의 위치와 방향을 알

수가 있는데 차량 재구성 시 각각의 노드들은 마스터에게 자신의

Individual_Period와 Node_Descriptor를 전송하며, 이를 받은 마스터는 각각

의 노드들에게 어드레스, 위치, descriptor를 알려주는 Topography라 불리는

descriptor를 보내게 된다. 이로써 열차의 물리적 차량변화를 열차 재구성을

통해 하나의 버스로 만들며, 데이터 전송을 위해 노드들의 descriptor를 전

송하여 periodic list를 구성함으로써 차량간 버스 통신을 위한 작업을 마친

다.

2.2.3.2 노드 주소 할당

열차 재구성 과정에서 각 노드의 어드레스 할당은 다음과 같은 절차를 따

른다[1].

a) 열차 재구성 시 구성하고 있는 노드 중 전동차의 제어기능이 있는 노

드중 네트워크 마스터로 동작할 수 있는 노드가 마스터가 되며 이 노

드는 자신의 어드레스를 ‘01’로 한다.

b) 마스터는 Direction_1로는 "bottom"으로 정의하고, Direction_2로

는 “top"으로 정의한다. 이때 차량 내 parking brake가 위치하는 반대

편을 Direction_1로 설정한다.

c) 마스터는 Direction_1의 방향에 붙은 노드의 주소는 63을 할당하며 그

다음에 오는 노드는 점차 감소시켜가며 노드의 어드레스를 할당한다.

24

마지막으로 할당되는 노드는 Bottom_Node가 된다.

d) 마스터는 Direction_2의 방향에 붙은 노드에는 2부터 점차 증가시키면

서 노드의 어드레스를 할당하고 마지막으로 할당되는 노드는

Top_Node이다.

마스터는 62개의 노드에 어드레스 할당을 할 수 있다. 차량간 통신버스의

재구성이 모두 이루어지면 각 노드들은 다음의 사항들을 알 수 있게 된다.

a) 자신의 노드 어드레스.

b) 마스터의 Line_A와 일치하게 되는 자신의 Line_A 또는 Line_B가 “P"

라 불려지고 다른 라인은 ”S"라 불려지게 되는데 이 때 자신의 위치.

c) 노드의 주소는 증가 또는 감소되는 순서로 할당.

d) 모든 노드의 어드레스, 위치, 타입을 알려주는 Topography.

2.2.3.3 노드의 등급

어플리케이션은 노드의 등급을 달리함으로써 차량 내 노드 중 하나만이

마스터가 될 수 있도록 조정 되어지며, 마스터의 권한을 갖는 노드는 열차

재구성 시 다른 노드와의 경합을 통해 마스터가 된다.

2.2.3.4 Strong Node

Strong node는 어플리케이션에 의해 승급되어 마스터가 되며 "Strong

master"라 불리게 된다. 또 어플리케이션에 의해 강등되어 weak node가 될

수 있다. 어플리케이션은 열차를 구성하고 있는 노드 중 오직 하나의 노드

만을 strong node로 승급시킨다. 만약 차량의 결합 등으로 열차에 하나 이

상의 strong node가 존재하게 되면 열차 재구성이 발생하게 되며 strong

node 중 보다 강한 것이 마스터가 되며 나머지 하나는 weak node가 되면서

슬레이브가 된다.

2.2.3.5 Weak Node

어플리케이션에 의해 마스터가 될 수 있는 노드이다. 마스터 권한을 수행

하는 weak 노드는 "Weak master"로 불린다. 어플리케이션은 구성 중에 여

25

러 개 혹은 모든 노드를 weak node로 설정할 수 있다. 차량간 통신버스

에 마스터가 존재하지 않으면, 노드들간의 경합을 통해 오직 하나만이

weak master가 되고 다른 노드들은 slave가 된다. 만약 weak master가

strong node를 발견하거나 자신보다 더 많은 slave node를 가진 weak

master node의 존재를 알게 되면, 보다 약한 노드는 자신의 마스터 권한을

포기하고 다른 노드의 slave가 된다.

2.2.3.6 Slave Node

어떠한 경우에도 어플리케이션에 의해 마스터가 될 수 없는 단지 슬레이

브로만 동작되는 노드이다. 이 모드는 테스트를 목적으로 하거나 strong

node와 함께 쓰이게 된다.

2.2.4 열차 재구성의 조건

2.2.4.1 열차 재구성의 시작조건

다음과 같은 조건이 만족되면 마스터는 열차 재구성을 시작하게 된다.

a) 열차의 구성변화 등으로 인해 열차 재구성이 이미 완료된 경우라 하

더라도 어플리케이션 명령이 있는 경우.

b) 정상 동작 중 열차 구성의 변화로 노드의 추가가 이루어지는 경우(단,

마스터가 노드의 재구성을 금지하는 경우에는 해당하지 않음).

c) 정상동작 중 마스터가 아닌 슬레이브였던 weak node가 strong node로

승급되는 경우.

d) 마스터에 문제가 생기거나, 네트워크 운영에 이상이 있는 경우.

다음 그림 26은 위의 조건들을 나타내고 있다.

26

그림 26 열차 재구성의 조건[1]

2.2.4.2 열차 재구성 과정

이와 같은 네트워크의 상황변화나 응용프로그램에 의한 열차 재구성과정

의 시작이 결정되면, 마스터는 여러 단계를 거처 새로 추가되거나 제거되는

전동차 노드의 구성을 하게된다.

열차 재구성 과정은 32개의 노드에 대해 25ms에서 1.0s 이내에 끝나

야 한다[1][3]. 최소 시간은 모든 노드가 정상 동작 시작 전에 어플리케이션

이 열차의 재구성 정보를 확인하는 시간까지를 의미한다.

차량 내의 노드 중 Intermediate_Node에 문제가 발생을 하면, 그 노드는

다른 노드에 영향을 주지 않도록 sleep 상태가 되어야 한다. 만약 sleep 상

태가 되지 않을 경우에는 다른 노드에 영향을 미칠 수 있다.

그림 27은 이미 구성된 전동차 구성에서 마스터의 메인 채널에 의해 새

로운 노드의 존재여부를 확인하는 과정을 나타내고 있다.

27

그림 27 Normal operation (main channel)

마스터는 매 기본 주기마다 양쪽방향의 끝 노드에게 새로운 노드의 존재

여부를 확인 할것을 명령하는 프레임을 전송하게된다. 이 프레임을 받은 끝

노드는 자신의 보조 채널을 통해 새로운 노드의 존재를 확인하는 프레임을

전송하고 그에 대한 응답을 기다리게 된다. 만일 새로운 노드가 존재하지

않거나 존재하게 되면 그러한 내용을 네트워크의 마스터에게 알리게 된다.

그림 28은 이러한 과정을 나타내는 그림이다.

그림 28 Detect request to another node (At End node)

그림 29는 끝 노드에서 새로운 노드를 발견하게 됐을 때의 그림으로 새

로운 노드의 존재를 마스터에게 알림으로써 마스터가 이미 구성되어있는

네트워크의 구성에 새로운 노드를 추가할 것인지를 결정하게 한다.

그림 29 Detect response from another node (At End node)

이때 마스터는 재구성과정이 가능한지를 판단하게 되는데, 응용프로그램

에서 열차의 속도가 5km/h이상이면 재구성을 금지할 수 있고, 또 네트워크

28

상의 하나의 노드라도 재구성을 원치 않을 때에도 재구성은 이루어지지

않는다[1]. 마스터는 이러한 노드들의 결정을 모든 노드들에게 재전송하게

된다. 만일 모든 노드들이 재구성과정을 동의하게 되면, 마스터는 정상 동

작상태를 멈추고, 열차 재구성의 상태로 천이하게 된다.

그림 30에서 보는것과 같이 열차 재구성 상태로 천이하게된 마스터는 새

로운 노드를 이미 구성되어있던 네트워크에 추가하기 위해서 모든 노드들

의 이름을 미정인 상태(unnamed)로 할것을 요구하고, 모든 노드들의 이름

을 다시 배정하게 된다(naming).

그림 30 Unnaming

모든 노드들이 이름이 미정인 상태가 되면, 그림 31과 같이 마스터는 주

채널과 보조채널을 통해 새로운 노드의 존재여부를 묻는 프레임

(Detect_Request)을 전송하게 된다. 이때 먼저 반응(Detect_Response)을 보

내오는 방향에 대해서 이름을 부여하게 된다.

그림 31 Detecting new Node

이때 마스터는 방향1(parking brake가 위치하는 차량의 끝단)에대해서는

내림 차순으로 이름을 부여하게 되고, 방향2에대해서는 오름차순으로 이름

을 부여하게 된다. 다음 그림 32는 이름이 부여된 네트워크 구성에 새로운

노드가 추가되는 과정을 보여준다.

29

그림 32 Status and Detection

이름 부여가 끝난 네트워크의 마스터는 끝노드에게 새로운 노드의 존재여

부를 묻게되고(Status_Request), 끝 노드는 자신의 보조채널을 통해 새로운

노드의 존재여부를 확인하게 된다(Detect_request). 이때 새로운 노드가 존

재하게 되면, 끝 노드는 그러한 정보를 마스터에게 알리게된다

(Status_response). 새로운 노드의 존재를 알게된 마스터는 현재 구성되어있

는 네트웍의 끝 노드에게 중간노드로 변경할것을 명령한다(SetInt_request).

마스터로부터 명령을 받은 끝 노드는 자신의 버스 스위치를 닫음으로써 자

신을 중간노드로 변경하게 되고 마스터에게 결과를 알리게 된다

(SetInt_response). 그림 33은 이러한 과정을 보여준다.

그림 33 Set to intermediate

이렇게 구성되어 있던 네트워크의 끝 노드가 중간노드로 변하게 되면, 마

스터는 새로 발견된 노드를 직접 엑세스 할 수 있게 된다. 그림 34와 같이

마스터가 직접 새로운 노드를 엑세스 할 수 있게되면, 마스터는 새로운 노

드에게 이름부여법칙에 따라 이름을 부여하게 된다(Naming_request). 새롭

게 이름을 부여받은 노드는 자신의 이름을 확인하고, 그 사실을 네트워크에

존재하는 노드와 마스터에게 알리게 된다(Naming_response).

30

그림 34 Naming

31

3 능동적 변화적응 프로토콜 구현방법

WTB의 프레임 종류는 크게 세가지로 구성되어있는데, 주기적인 데이터

통신을 위한 Process data frame, 비주기적인 데이터 통신을 위한 Message

data frame, 그리고 마지막으로 전동차 네트워크의 관리를 위한 Supervisory

data frame이 있다. 이러한 세가지 프레임의 활용방법에 대한 내용은 TCN

Spec에서 자세히 언급하고 있다. 그러나 이러한 활용방법 중에서 열차 재구

성시 정보전달을 위한 Data frame중 그림 35에서 보는바와 같이

topography_response 프레임의 Inauguration data영역의 활용방법에 대해서

는 사용자의 정의에 의한 활용을 제안하고 있다[1][3]. 본 논문에서는

121byte에 달하는 Inauguration data 영역을 이용하여 보다 효율적인 열차구

성 변화정보 전달에 대한 Protocol을 구현하려 한다.

0 1 2 3 4 5 6 7

Destination_device

Link_control

Source_device

Link_data_size

Bottom_node

nns insmas

Master_topo

Your_period

0 1 2 3 4 5 6 7

Destination_device

Link_control

Source_device

Link_data_size

Node_type

Node_addressrsv1sam

Inauguration dataArray[inaug_data_size] of

WORD8

Node_version

Inaug_data_size

0 1 2 3 4 5 6 7

Destination_device

Link_control

Source_device

Link_data_size

Bottom_node

nns insmas

Master_topo

Your_period

0 1 2 3 4 5 6 7

Destination_device

Link_control

Source_device

Link_data_size

Node_type

Node_addressrsv1sam

Inauguration dataArray[inaug_data_size] of

WORD8

Node_version

Inaug_data_size

그림 35 Topography Request & Topography Response[1]

32

3.1 능동적 변화적응 프로토콜의 필요성

열차 재구성과정이 실행이 되면, 마스터는 이미 구성되어있던 네트워크에

새로운 노드의 추가나 제거를 위하여 여러 단계를 거처 새로운 네트워크를

구성하게 된다. 이렇게 되면 기존의 네트워크상황에서 전송되던 프레임의

구조라든지 데이터의 종류가 변하게 된다. 이때 이러한 변화를 네트워크의

정상동작 이전에 모든 네트워크 구성객체에게 전달함으로써 보다 신속한

네트워크 정상화를 이룰 수 있다. 이러한 과정을 위해서 열차구성 변경정보

를 전달하기 위한 Protocol을 정의해야 한다[6][7][8][9][10][11][12][13][14].

3.2 Inauguration data 영역의 활용방법

열차구성 변경정보를 전달하기 위한 protocol을 구현하기 위해 사용되는

topography_response 프레임중 Inauguration data영역을 활용하기위해 정의

한 데이터 영역의 형태는 그림 36와 같다[19][21].

Frag Port_count Port_inform CRC

Port_num offsetsizes/s

1byte2byte 2byte

15bit 1byte 2byte1bit

Fragment_IDM

14bit2bit

116byte

5byte

Frag Port_count Port_inform CRC


1byte2byte 2byte


Fragment_IDM

14bit2bit

116byte

5byte

그림 36 Inauguration Data영역의 정의

3.2.1 Frag field

Frag field는 Inauguration_data영역을 이용한 정보전달시 포트데이터의 수

가 많을 경우 한꺼번에 모든 포트에 대한 정보를 보낼 수 없을 때 정보를

33

나누어 전송하는데 사용한다.

• Mode

2bit로 구성된 Mode 영역은 현재 전송되는 프레임에 이어지는

프레임이 있는지를 나타내고, 마지막 데이터 프레임을 나타내기

위해 사용한다.

00 Reserved

01 Fragmentation되어있고 추가프레임이 있다.

10 마지막 데이터 프레임

11 Topography_Response ACK frame

Mode 의 미

00 Reserved

01 Fragmentation되어있고 추가프레임이 있다.

10 마지막 데이터 프레임

11 Topography_Response ACK frame

Mode 의 미

표 2 Mode field

• Fragment_ID

14bit로 구성되고, 현재의 프레임이 나누어진 프레임의 몇 번째

프레임인지를 나타냄으로써, 데이터의 전송시 전송오류로인한 잘

못된 데이터의 사용을 막기위해 사용한다.

3.2.2 Port_count field

Inauguration_data영역을 통해서 보내지는 port의 수를 나타내는 필드로

1byte로 구성된다. WTB상의 하나의 노드가 가지고 있는 port의수는 수십에

서 수백개에 이르기 때문에 한번의 데이터전송을 통해서는 모든 정보를 전

달할 수 없게 된다. 여러번 반복해서 프레임을 전송할 때 모든 정보를 처리

하기보다는 카운터 필드의 정보를 미리 확인함으로써 보다 효율적인 알고

리즘의 구현이 가능하다.

34

3.2.3 Port_inform field

이 영역은 총 4가지 정보를 포함하고 있는데, WTB상의 각 노드가 가지고

있는 Port의 정보를 나타내고 있다.

• S/S bit

해당하는 포트가 WTB노드상에서 source인지 sink인지를 구분

하는 영역으로 사용되며, 이 정보를 이용하여 WTB상의 모든 노

드는 Import list 와 Export list를 구성하게 된다. 이 영역이 1이

면 source를 0이면 sink를 표현하게 된다.

• Port_num

WTB노드가 가지고있는 port의 number로 모든 TCN 네트워크

상에서 Unique한 값을 가지게된다. 15bit로 구성되고, 32767개

의 port를 나타낼수 있다. 즉 TCN 네트워크상에 32767개의 서

로 다른 port를 구성할 수 있다.

• Size

Port의 데이터 사이즈를 나타내는 영역으로 TCN 네트워크에서

는 다양한 사이즈의 데이터 형태를 지원하고 있다. 16, 32, 64,

128, 256bit의 데이터 사이즈를 나타내기 위해서 1byte의 크기

를 갖는 영역이다.

• Offset

WTB상의 네트워크 상태가 재구성 동작을 마치고 정상상태로 동

작할 때 통신 프레임상의 Port 데이터의 위치를 나타내는 정보

를 포함하고 있다. WTB 프레임의 정상동작시 데이터 사이즈는

1024bit이기 때문에 각 port의 위치를 나타내기 위해서는 2byte

의 영역이 필요하다.

35

3.2.4 CRC (Cyclic Redundancy Check)

네트워크를 통해 전송되어온 데이터의 오류여부를 판단하기 위한 영역이

다. 간단한 에러 검출방법으로는 Parity에의한 방법과 Check sum을 이용한

방법이 있으나, 이러한 방법은 에러를 검출할 수 있는 확률이 매우 낮기 때

문에 데이터의 무결성이 중요한 TCN의 네트워크정보를 전달하기 위한

protocol에서는 적합하지 않다[19]. 그림 36에서 보는 바와 같이 16bit를 이

용하고 있다.

3.3 능동적 변화적응 프로토콜(adaptable configuration protocol)

전동차 네트워크의 변화에의해 열차재구성 과정이 이루어졌을 때, 새로운

네트워크정보를 네트워크를 구성하고 있는 모든 노드들이 공유하기 위해서

supervisory frame를 통해 전송하게 된다[1][3]. 이때 각 노드들은 자신이 소

유하고있는 하부장치들에 대한 정보를 가지고 있고, 다른 노드로 보내거나

받아야하는 정보에 대해서도 알고 있어야 한다. 이때 다른 노드로 보내야하

는 정보를 source정보라 하고, 다른 노드로부터 받아야하는 정보를 sink정보

라 한다. 전동차에 실장되는 장치들은 독립적으로 동작할수도 있지만 다른

장치로부터 받은 정보를 가지고 자신의 장치를 운용할 필요가 있을 수 있

기 때문에, source정보와 sink정보는 오프라인상에서 장치들의 개발 업체들

간에 미리 정의되어야 한다. 이러한 정보들은 객차간의 통신을 하는 WTB노

드에 제공되어야 한다. 미리 제공된 정보(이하 Port data)를 통하여 객차간

의 데이터 통신이 이루어지게 된다.

3.3.1 WTB 마스터에서의 Inauguration_data 처리

열차재구성 과정에의해 변화된 정보를 모든 노드가 공유하기 위해서 WTB

상의 마스터는 Tography_request 프레임을 전송하게 된다. 이 프레임을 받

36

은 각각의 노드는 차례로 자신이가지고 있는 정보를

Topography_response 프레임을 네트워크상에 브로드캐스팅함으로써 알리게

된다[1][3]. 그림 37은 마스터에서 Topography_response를 받았을 때 프레

임에 포함 된 Inauguration_data영역을 분석하고 그에따른 데이터의 추출과

그림 37 WTB 마스터에서의 정보전달 Protocol 순서도

37

에러가 발생했을시 처리방법을 나타내고 있다.

우선 Topography_response의 Inauguration_data영역의 check_sum 영역을

확인하여 전송되온 프레임상의 에러가 있는지를 검사하게된다. 에러가 발생

했다면, 마스터는 Topography_request 프레임의 master_topo의 값을 증가시

키지 않고 다시 전송하게 된다[1][3]. Inauguration_data에 에러가 발생하지

않았다면, 현재 전송받을 프레임이 해당하는 노드로부터 보내진 정보를 모

두 포함하고 있는지 mode 영역을 확인함으로써 알 수 있다. 이어지는 프레

임이 있다면 현재 받은 프레임의 fragment_ID와 port_count를 확인하고

Port_imform영역을 저장한다. 그리고 master_topo값을 증가시키지 않고, 현

재와 같은 노드로 재차 Topography_request를 보냄으로써 나머지 port_data

를 전송할것을 명령한다. 이러한 과정을 해당노드의 모든 정보를 받을때까

지 반복하고, 해당 노드로부터 마지막 프레임을 받게되면 저장된

Port_imform의 S/S영역을 확인하여, Export_list와 Import_list를 생성한다.

3.3.2 WTB 슬레이브에서의 Inauguration_data처리

WTB마스터와는 다르게 슬레이브노드는 Topography_response를 네트워크

상에 브로드캐스팅하게 되므로 자신의 정보를 마스터뿐만아니라 모든 다른

슬레이브들도 같이 공유하게 된다. 이렇게 네트워크를 통해 전송받은

Topography_response의 Inauguration_data영역을 처리하는 방법은 그림 38

과 같다. 네트워크상에서 Topography_response를 받은 슬레이브 노드는

Inauguration_data영역의 check_sum영역을 확인하여 프레임의 오류 여부를

확인한다. 이때 전송받은 프레임에 오류가 있다면 다음에 마스터로부터의

Topography_request에 대한 응답 프레임에 오류보고를 하고, 다시 정보전송

을 위한 Topography_request를 보낼 것을 요청하게 된다[3]. 오류가 없는

프레임을 받은 슬레이브는 Mode영역을 확인하여 이어지는 데이터 프레임이

있는지 확인하고, 이어지는 프레임이 있다면, 현재 받은 Inauguration_data

를 저장하고 다음 프레임을 받을 준비를 한다. 마지막 프레임을 받았으면,

저장된 Port_inform의 S/S영역을 확인하여 Export_list와 Import_list를 생성

38

한다.

그림 38 WTB 슬레이브에서의 정보전달 Protocol 순서도

39

3.3.3 Export_list와 Import_list의 생성

위에서 보았던 과정을 거쳐 Inauguration_data를 모든 노드에서 공유하게

되면 각각의 노드는 자신이 네트워크상에 전송해야하는 Port_data의 집합인

Export_list를 구성할 수 있고, 다른 노드로부터 전송받아야하는 Port_data의

집합인 Import_list 또한 구성할 수 있다. 그림 39는 이러한 과정을 보여주

고 있다.

Port_inform

WTB Node 0_1 (source)

WTB Node 1 (sink)

WTB Node 2 (sink)

Port_inform

Port_inform

WTB Node 0_0 (source)Port_inform

119 byte



Source port list Sink port listPort_num size offset

100 16 1

120 256 17

188 32 300

199 16 332

Port_num size offset

490 32 0

495 16 0

888 64 0

970 32 0


490 32 0

888 64 100

333 32 300

567 16 332


120 256 0

199 16 0

786 64 0

897 32 0

WTB Node 0 WTB Node 1

Port_inform

WTB Node 0_1 (source)

WTB Node 1 (sink)

WTB Node 2 (sink)

Port_inform

Port_inform

WTB Node 0_0 (source)Port_inform

119 byte




100 16 1

120 256 17

188 32 300

199 16 332


490 32 0

495 16 0

888 64 0

970 32 0


490 32 0

888 64 100

333 32 300

567 16 332


120 256 0

199 16 0

786 64 0

897 32 0



100 16 1

120 256 17

188 32 300

199 16 332


490 32 0

495 16 0

888 64 0

970 32 0


490 32 0

888 64 100

333 32 300

567 16 332


120 256 0

199 16 0

786 64 0

897 32 0


그림 39 Export_list & Import_list 구성과정

그림에서 보는바와 같이 Inauguration_data영역의 Port_inform영역의 S/S

비트를 체크하여 각각의 노드가 가지고있는 포트들의 소스와 싱크별로 나

누어 테이블 형태로 저장한다. 이렇게 저장된 각각의 노드들의 정보를 가지

고 자신의 Export_list와 Import_list를 구성해야 한다. 그림 39에서 WTB

Node 0의 테이블을 보면 120,199번 Port가 소스이고, 490,888번 Port가 싱크

이다. 한편 WTB Node 1의 테이블을 보면 490,888번이 소스이고 120,199번

40

이 싱크이다. 이러한 결과를 가지고 WTB Node 0는 120,199번 Port를

Export_list에 추가하고, 490,888번 Port를 Import_list에 추가해서 두 가지 리

스트를 구성할 수 있다. 이러한 과정은 각각의 모든 WTB노드에서 이루어

지게 되며, 모든 노드의 리스트구성이 올바르게 끝나면 정상동작시 오류없

는 데이터 전송이 이루어질 수 있다.

3.3.4 Inauguration_data 프레임의 에러처리

WTB 마스터가 보낸 Topography_request의 응답을 해당 노드가 네트웍상

에 브로드케스팅하게 되고, 이 프레임을 받은 각각의 노드들은 프레임의 에

러여부를 판단하게 된다. 이후 마스터는 네트워크상의 모든 노드에게 프레

임을 정확히 전송받았는지를 확인하는 프로세스를 수행하게 된다. 네트워크

상의 모든 노드들이 정확한 프레임을 받았을 때 Topography_request의

master_topo값을 1 증가시켜 다음 노드에게 보냄으로써 정보공유 과정을

계속 수행하게 된다. 슬레이브에서는 전송받은 Topography_request의

master_topo값의 변화가 없다면 이전 노드의 프레임이 여러 조각으로 나누

어져서 전송된 경우이든지, 프레임의 에러에 의한 Topography_request의 재

전송이라고 판단하면 된다.

41

4 열차 재구성 과정 실험

전동차 네트워크의 변화에 의한 재구성과정을 위해서는 WTB상의 노드인

Gateway보드와 MVB상의 노드인 IMC보드의 상호 유기적인 동작이 필요하

다. 우선 MVB를 통하여 전송되는 데이터의 종류와 크기, 주기등의 정보를

Gateway보드는 알고 있어야 한다. 이러한 정보를 바탕으로 네트워크의 변

화가 생겼을 때 본 논문에서 제안한 재구성 정보전달 Protocol을 이용하여

정상동작이 시작되기전에 모든 WTB노드가 정보를 공유할 수 있게 된다. 우

선 다음 4.1절에서는 열차 재구성 과정을 위한 하드웨어의 개발에 관해 간

략히 살펴보고, 4.2절에서는 열차 재구성 실험 환경과 선도기술개발사업으

로 진행되고 있는 한국형 고속전철기술개발 사업의 시제차에 적용된 내용

을 언급한다.

4.1 하드웨어

하드웨어의 개발은 크게 MVB 통신을 위한 IMC4.0과 WTB 통신을 위한

IGC1.1로 나뉘어진다.

4.1.1 Intelligent MVB Controller 보드의 개발(IMC4.0)

지능형 MVB 콘트롤러(IMC4.0)은 MVB네트워크를 구성하는 노드로서,

ATbus를 컴팩트하게 만든 PC104 형태의 외형을 가지고 있다. 그림 40은

IMC4.0의 하드웨어 구성을 보여준다. MVB통신은 MVB 전용 컨트롤러인

MVBC가 담당하며 데이터의 저장, 컨트롤 비트 등의 저장을 위해 1Mbyte로

구성된 전용의 Traffic Memory를 사용한다. MVBC는 데이터를 처리하여 Line

driver을 통하여 bus에 전달하게 된다[15]. AMD사의 PLD인 PALCE22V10H에

어셈블리 언어를 이용 코딩함으로써 로컬 호스트와의 데이터 이동 동작을

지원하였다. 디버깅과 데이터 전송용으로 2개의 RS232 규격을 준수하는

Serial 포트를 제공하는데 비동기 방식으로 디버깅과 데이터 전송을 위해 사

용될 수 있다. IMC 4.0은 주요부품을 SMD부품으로 사용함으로써 하드웨어

42

의 안정성과 컴팩트한 사이즈를 만족시키고 있다.

D-subconnector

MVBC

SRAM

TTL/RS232 D-subconnector

CPU(AM186ED)

SRAM

FLASH

DP

RA

M

PA

L

BU

S

Line unit

D-subconnector

MVBC

SRAM

TTL/RS232 D-subconnector

CPU(AM186ED)

SRAM

FLASH

DP

RA

M

PA

L

BU

S

Line unit

그림 40 IMC4.0의 블록다이어그램

한국형 고속전철 개발사업의 참여 업체의 특정한 하드웨어에 형태에 따라

ISA형태, 3U VME, 6U VME등 여러가지 종류의 하드웨어 외형을 필요로 하는

데, 대부분 6U VME형태를 가지고 있다[20]. PC104의 형태를 갖고 있는

IMC4.0을 참여업체들의 호스트 보드와 인터페이스하기위한 브리지보드를

만들어 기본적인 IMC4.0보드를 공통적으로 사용함으로써 전체적인 통일성

과 유연성을 높일 수 있었다. 그림 41은 IMC4.0과 VME브리지를 보여준다.

그림 42는 IMC4.0과 VME 브리지의 결합된 사진이다.

43

그림 41 IMC4.0 과 VME 브리지

그림 42 IMC4.0 with VME bridge

44

4.1.2 Intelligent Gateway Controller 보드의 개발(IGC1.1)

Gateway보드는 WTB상의 통신 노드로 동작하게 된다. MVB네트워크를 통

해 전달되온 데이터를 다른 객차로 전송하거나 다른 객차로부터 전송받기

위한 역할을 하게 되는데, WTB네트워크에는 하나의 마스터가 존재하고, 이

노드가 열차의 구성변화를 감지하거나, 응용프로그램에 의해 열차의 구성을

재편성할 수 있어야 한다. 이러한 조건을 만족시키위해서 Gateway보드는

고사양의 CPU를 지원할 수 있어야 한다. 이를 위해 고성능 통신 CPU로 인

정받고 있는 모토롤라사의 MC68EN360EM25K 프로세서를 사용한 상용보드

인 XV015A(㈜우리기술)를 케리어보드로 사용하고, WTB통신을 위한 IP모듈

을 탑재하는 방식으로 IGC1.1을 개발하였다[16][17]. 그림 43은 WTB용 IP

모듈의 블록다이어그램 이다.

IP conn

A

WTBCODEC

IP conn

B

WTBLine unit

WTBLine unit

SCC2SCC3

Line A

Line B

IPI/FIPI/F

For WTB redundancy

SCC4

IP conn

A

WTBCODEC

IP conn

B

WTBLine unit

WTBLine unit

SCC2SCC3

Line A

Line B

IPI/FIPI/F

For WTB redundancy

SCC4

그림 43 WTB용 IP 모듈의 블록다이어그램

WTB용 IP모듈은 WTB네트워크에서 전송되온 데이터를 Manchester

45

decoding하여 HDLC형태로 XV015A의 CPU의 SCC(Serial Communication

Controller)채널로 전달하게 되고 CPU의 SCC채널을 통해 전달받은 HDLC형

태의 데이터를 Manchester encoding하여 WTB네트워크상에 전송하게 된다.

그림 44는 WTB용 IP모듈의 사진이고, 그림 45는 Xv015A보드에 IP 모듈이

탑재된 Gateway보드의 사진이다.

그림 44 WTB용 IP모듈

그림 45 WTB용 Gateway보드

Gateway 소프트웨어의 구조는 열차의 상태등을 모니터링 하면서, 주기적

인 통신과 비주기적인 메시지 통신을 지원해야 하기 때문에 실시간성이 중

46

요시된다. 이러한 사양을 바탕으로 하드웨어와 밀접한 Link layer위주의 프

로그램 개발이 진행 되었다. 그림 46은 본 논문에서 제안한 열차 재구성 정

보전달 Protocol을 사용한 후 WTB통신 네트워크가 정상상태일 때 데이터를

네트워크로 전송하거나 받을때의 작업을 나타내는 Mashalling 테스크를 단

적으로 보여주는 그림이다[1][3]. Gateway를 위해 프로그래밍된 소프트웨어

는 windRiver사의 실시간 운영체계인 VxWroks상에서 컴파일 했다[18].

그림 46 Transmission of Periodic_Data through the Network[1]

4.2 열차 재구성 실험환경

열차 재구성 과정을 실험하기 위해서는 여러개의 WTB network노드가 필

요하다. 그림 47은 연구실 환경에서의 열차 재구성 과정을 테스트하기 위한

시험환경으로 IGC1.1보드와 IMC4.0보드가 하나의 쌍을 이루어 Gateway노드

47

를 구성하게 된다. 이렇게 구성된 Gateway노드들은 backplane를 통하여

통신선을 연결하고 마스터에의해 통신을 시작하게 된다.

Master_Node

Second_Node

Master_Node

Second_Node

그림 47 열차 재구성 시험환경

그림 48은 WTB네트웍의 통신이 시작되고 마스터가 통신을 위한 마스터

프레임을 전송했을때의 사진이다. 아직까지 추가되는 노드가 없기 때문에

마스터 프레임에 대해서 응답하는 슬레이브 프레임이 1개밖에 없다. 그림

48의 아래쪽 그림은 마스터 프레임을 확대한 그림으로 HDLC포멧을 이루는

것을 확인할 수 있다.

48

그림 48 WTB 통신을 위한 마스터 프레임 & 슬레이브 프레임

(HDLC 포멧)

위와 같은 동작상태에서 새로운 노드가 추가되면 WTB상의 프레임은 그림

49와 같은 형태를 띄게 된다. 마스터 프레임에 응답하는 슬레이브 프레임이

2개로 변화된 것을 볼 수 있다.

49

그림 49 두번째 노드가 추가되었을때의 WTB 프레임

그림 50과 그림 51은 한국형 고속전철 개발사업으로 제작된 KHST(Korea

High Speed Train)의 내부에 장착된 Gateway의 모습을 보여준다.

50

그림 50 한국형 고속전철에 장착된 Gateway의 모습 (a)

그림 51 한국형 고속전철에 장착된 Gateway의 모습 (b)

51

5 결론

IEC(International Electrotechnical Commission)에서 전동차 통신네트워크의

표준으로 정한 TCN은 전동차 네트워크의 구성변화에 대해 능동적으로 대처

할 것을 나타내고 있다. 이러한 기능은 전동차의 운용성과 유연성을 위해서,

전동차량에 탑재를 위한 장치의 개발을 위해서는 반드시 적용해야 할 것으

로 보여진다. 전동차의 정상적인 네트워크 상황에 변화가 생기게 되면 그것

을 빠른 시간내에 감지하고, 이미 구성되어있던 네트워크에 새로운 네트워

크 노드를 추가하기 위해서 변화된 정보를 모든 네트워크상의 장치들이 공

유할 수 있어야 한다. 하지만 TCN에서는 능동적 대처방안에대한 대략적인

방법과 순서에 관해서만 언급하고 있다.

본 논문에서 제안한 전동차 통신네트워크 재구성 정보전달 Protocol에대한

내용은 이전에 행하여진 연구가 없었기 때문에 객관적인 비교대상이 없지

만, 네트워크상황의 변화에 대한 구체적인 대응방법을 제안하였다. 이 방법

은 전동차 통신 네트워크이라는 특수한 상황에 적용되는 Protocol로써, 전동

차를 구성하고 있는 장치들의 제어를 위한 사용자 편의를 도모하고, 운용성

과 유연성을 제공할 수 있다.

본 논문에서는 전동차량간의 구성변화에대한 능동적 대처 방법에 대한 구

체적인 연구를 수행 하였지만, 향후 전동차 내부의 제어기기의 변화나 고장

에 대처하기위한 방법도 고려되어져야할 것으로 생각된다.

52

참고 문헌

[1] IEC 61375-1 Standard, Train Communication Network. first edition

1999-09: Part (1)General Architecture (2)Real-time protocol

(3)Multifunction Vehicle Bus (4)Wire Train Bus (5)Train Network

Management (6)Train Communication Conformance Testing, 1999

[2] UIC 556 Standard, Information Transportation on the Train Bus

1999.05.01 v2.0

[3] Kirrmann, H., Zuber, P.A., “The IEC/IEEE train communication

network”, IEEE Micro , Volume: 21 Issue: 2 , March-April 2001

[4] Schifers, C., Hans, G. “IEC 61375-1 and UIC 556-international

standards for train communication” Vehicular Technology

Conference Proceedings, 2000. VTC 2000-Spring Tokyo. 2000

IEEE 51st , Volume: 2 , 2000

[5] Chavarria, A., de Arroyabe, J.L., Zuloaga, A., Jimenez, J., Martin,

J.L., Aranguren, G., “Slave node architecture for train

communications networks” Industrial Electronics Society, 2000.

IECON 2000. 26th Annual Conference of the IEEE , Volume: 4 ,

2000

[6] Mcauley, A.J., Manousakis, K. “Self-configuring networks”,

MILCOM 2000. 21st Century Military Communications Conference

Proceedings , Volume: 1 , 2000

[7] Misra, A., Das, S., McAuley, A., Das, S.K. “Autoconfiguration,

53

registration, and mobility management for pervasive computing”,

IEEE Personal Communications , Volume: 8 Issue: 4 , Aug. 2001

[8] R. Droms, “Dynamic Host Configuration Protocol for

IPv6(DHCPv6)”, IEFT RFC 2026, May 24 2002

[9] Schuster, A., Ben-Asher, Y. “Algorithms and optic implementation

for reconfigurable networks”, Information Technology, 1990. 'Next

Decade in Information Technology', Proceedings of the 5th

Jerusalem Conference on (Cat. No.90TH0326-9) , 1990

[10] Ramos, R.E., Madani, K. “A novel deneric distributed intelligent re-

configurable mobile network architecture”, Vehicular Technology

Conference, 2001. VTC 2001 Spring. IEEE VTS 53rd , 2001

[11] Kamat, S., Wei Zhao, “An efficient optimal reconfiguration algorithm

for FDDI-based networks”, Parallel and Distributed Systems, IEEE

Transactions on , Volume: 7 Issue: 4 , April 1996

[12] Camp, T., Boleng, J., Wilcox, L., “Location information services in

mobile ad hoc networks”, Communications, 2002. ICC 2002. IEEE

International Conference on , Volume: 5 , 2002

[13] Green, C.J., “Protocols for a self-healing network”, Military

Communications Conference, 1995. MILCOM '95, Conference

Record, IEEE , Volume: 1 , 1995

[14] Tschudin, C., Lundgren, H., Gulbrandsen, H. “Active routing for ad

hoc networks”, IEEE Communications Magazine , Volume: 38 Issue:

4 , April 2000

54

[15] ABB Daimler-Bensz Transportation(Switzerland) Ltd,

“Multifunction Vehicle Bus Controller”

[16] MOTOROLA, MC68360 Quad Integrated Communication Controller

User’s Manual

[17] Thomas L.Harman, David T.Hein, The Motorola Mc68000

Microprocessor Family, Assembly Language, Interface Design, and

System Design. Second Edition. by Prentice-Hall Inc. 1996

[18] WindRiver, “VxWorks Programmer’s Guide,5.3.1, Edition 1” 1997

[19] W.Richard Stevens, TCP/IP Illustrated, Volume 1, Addison-wesley

publishing company, Inc. 1997

[20] IEEE Standard for A Versatile Backplane Bus:VMEbus, Approved

March 12,1987 IEEE Standards Board, Approved September

11,1987 American National Standards Institute

[21] Jane W.S.Liu, “Real-time systems”, Prentice Hall.

55

감사의 글 어떤일이든 처음의 마음은 새로운것에의 도전이라는 설레임과 희망을 가

지고 시작하게 되지만 시간이 지나면서 그러한 생각이 점점 움츠러드는 것

은 어쩔수 없는것 같습니다. 지나고나면 후회를 하게 되고, 아쉬워하면서

최선을 다했다고 자위하게 되는 것을 매번 반복하지만, 또 후회하게되는 것

이 아직 스스로 많이 모자람 때문일 것입니다. 지난 9년간의 대학생활과 대

학원생활을 통해서 많은사람들과 인간관계를 맺어 왔으며, 그들의 도움으로

지금의 내가 있음을 감사하게 생각합니다. 2년간의 대학원생활동안 많은 가

르침을 주신 박재현 교수님께 감사의 말씀을 드립니다.

연구실에 들어와서 더 많이 알게된 솔내시스템 영찬이형, 용국이형, 명현

이형, 그리고 태경이, 많이 생각해주시고 좋은말씀 많이 해주신거 정말 고

맙게 생각합니다. 연구실 생활을 시작하게 도와준 준우에게 감사하고, 재윤

이, 동규형, 태림이형, 세섭이형, 원구형, 영기형께도 감사드립니다. 후배지

만 연구실 선배인 창호와 민정이에게 아울러 고맙다는 말을 전합니다. 대학

원생활을 같이한 복진이와 기홍이가 있었기에 힘든 과정을 무사히 마칠수

있었다고 생각하고, 진심으로 고마움을 전합니다. 이제 새롭게 연구실을 이

끌어가게될 맏형 기중이형과 멋있는남자 명호, 똑똑한 영준, 제2의 바른생

활맨이 될거 같은 동진, 카리스마 병철, 조용한남자 하영, 연구실 막내 명환,

모두 대학원 생활을 멋있게 마치길 기원합니다. 그리고 무의미라는 이름으

로 모여 나의 대학생활의 추억을 깊게해준 나에게는 정말 의미있는 녀석들

준석, 기원, 욱향, 강엽, 창석, 형준, 수련, 성민, 해승이에게 고마움을 전합

니다.

학교생활 때문에 많이 신경못써주고 짜증섞인 말을 해도 다 받아준 정훈

이에게도 감사의 말을 전합니다. 지금도 손자를 위해서 기도하고계실 할머

니께 감사드리고, 큰아들이 대학원까지 마칠수 있도록 고생하시면 뒷바라지

해주신 부모님께 말로는 표현할 수 없는 존경과 감사의 말씀을 드립니다.

많이 부족한 나를 형이라서, 오빠라서, 항상 잘따라주었던 내동생 재장이와

재숙이에게도 감사의 말을 전합니다.

Documents

고속전철 차량간 구성변화의 능동적 적응을 위한 통신규약에 ... · 2010-10-16 · a) Electrical Short Distance(ESD) RS485표준에 따라 차동 전송되는