[7호]Multi-CAN Analyzer를 이용한 차량 ECU 모니터링

Multi-CAN Analyzer를

이용한 차량 ECU 모니터링

자료제공 : 마을소프트웨어

1. 들어가며

CAN (Controller Area Network)은 멀티마스터(Multi-Master) 브로드케스트 시리얼(Broadcast Serial) 버스 표준으로 실시간 제어 응용시스템 내에 있는 센서나 기동장치 등과 같은 주변장치들을 서로 연결해 주는 메시지 통신방식으로 마이크로 제어기용 네트웍을 가리킨다. CAN에서는 이더넷 등에서 사용되는 것과 같은 주소 지정 개념은 사용되지 않으며, 메시지는 해당 네트웍에서의 고유한 식별자를 사용하여 네트웍 내에 있는 모든 노드들에게 동시에 뿌려진다. 개개의 노드들은 이 식별자에 기반하여 해당 메시지를 처리할 것인지의 여부를 결정하며. 버스 접근 순서 역시 경쟁원리에 따라 메시지 우선순위가 배정되어 충돌이 없어 중단 없는 데이터 전송이 가능하다. 또한 differential twisted pair방식을 사용하여 노이즈에 매우 강한 특성이 있다. 보다 자세한 CAN에 대한 역사나 기술적인 내용은 본고에서는 생략하기로 하고 참고자료를 참고한다.
위와 같은 CAN 특성으로 최근 매우 안정성을 요구 하는 차량의 내부 네트워크로 CAN 통신을 사용하고 있는 추세다. 즉 주제어기인 ECU (Electronic Control Units) 끼리의 통신이나 각종 센서 및 작동기 등과 안정적인 통신을 위해 CAN이 사용되고 있는 것 이다. 따라서 CAN 통신을 이용하여 ECU가 이해할 수 있는 프로토콜로 통신을 하게 되면 차량 네트워크로부터 차량의 다양한 정보를 얻어 낼 수 있게 된다.
본고에서는 CAN 메시지를 송수신하고 메시지로부터 프로토콜을 해석할 수 있는 Analyzer를 소개하고, 그것을 통해 실제 차량 ECU로부터 다양한 정보를 모니터링 하는 방법에 대해 소개한다.

2. Multi-CAN Analyzer 소개

마을소프트웨어는 반도체 및 LED 생산설비 제조 전문업체로 그간 산업용 제어 분야의 경험을 기반으로 다양한 CAN 제품을 출시하였다. CAN 경험이 없는 일반 사용자들을 위해 보다 쉽게 접근할 수 있는 CAN2RS232 컨버터와, 인터넷을 통한 원격 제어를 위한 CAN2Ethernet 게이트웨이 등이 그것이다. 이 제품들은 주로 제어기 용도로 개발되었기 때문에 필터 설정을 통해 필요로 하는 메시지들만 CAN 버스로부터 수신하고 전송하는 제품으로 컨버터나 게이트웨이가 처리할 수 있는 용량 이상으로 CAN버스 메시지를 모두 처리 할 수는 없었다. 또한 절연되지 않아 현장 상황에 따라 컨버터가 파손되는 경우도 있었다. 이런 이유로 Analyzer 용도로는 적합하지 못해 High-End급 고성능 절연 CAN-USB Analyzer와 Multi-CAN Analyzer를 개발 출시 하게 되었다.

본고에서 소개될 Multi-CAN Analyzer는 이름에서 유추 할 수 있듯이 동시에 여러 인터페이스 방식을 사용할 수 있는데, 그것은 RS232C, USB 그리고 Ethernet이다. 따라서 어떠한 환경이나 조건에도 쉽게 Analyzer를 쓸 수 있는 장점이 있다. RS232C는 최대 460800bps의 속도 까지 사용할 수 있으며 인터페이스가 UART밖에 없는 소형 제어기와도 쉽게 연결된다. USB는 PC와 외부 전원 없이 연결할 수 있기 때문에 노트북으로 현장에서 디버깅하는데 매우 유용하다. Ethernet은 현장에 설치된 CAN버스의 문제점을 원격지 사무실에서 모니터링 하는데 매우 적합하다.
본 Analyzer는 제공되는 전용 프로토콜을 통해 직접 Analyzer를 제어기들과 연결하여 고성능 컨버터 처럼 사용할 수도 있지만, Windows 응용프로그램으로 제공되는 전용 분석기인 CANTALKER를 통해 추가적인 소프트웨어 개발 없이 고수준의 CAN 프로토콜을 분석할 수 있다. 기본적으로 표준 프로토콜로 OBD-II, CANopen 그리고 DeviceNet등이 일부 지원되며 향후 J1939도 지원될 예정이다.

그림1. CANTALKER Windows Application

그 밖에 CANTALKER가 지원하는 주요 기능은 다음과 같다.

· 10us 단위 Timestamp
· CAN 송신 메시지 프로그래밍
· CAN 송수신 메시지 읽기 및 저장
(텍스트 파일로 export지원)
· 특정 CAN 메시지 모니터링 및 산술 계산 / 그래픽 표시 / 로깅(실시간/비실시간 지원)
· CAN 수신 메시지 소프트웨어 필터링 / 트리거
· CAN 송수신 메시지에서 특정 메시지 찾기 / 복사
· CAN 버스 통계자료 제공
· CAN 컨트롤러 상태 확인 및 제어
· 터미널
· 펌웨어 업그레이드

본고에서 ECU 모니터링에 사용될 장비와 프로그램은 Multi-CAN Analyzer와 CANTALKER이다.

3. ECU 모니터링

CAN통신을 지원하는 차량의 대부분은 OBD-II PID 프로토콜을 지원한다. ECU와 통신하기 위해서는이 프로토콜을 반드시 숙지 해야 하는데 그다지 복잡하기 않기 때문에 쉽게 구현될 수 있다. 그럼 OBD-II PID가 무엇인지 다음절에서 알아 본다.

3.1 OBD-II PID란 ?

OBD-II PID는 On Board Diagnostics Parameter ID의 약자로 정확하게 말하면 프로토콜이 아니라 코드를 의미 하며 SAE J1979 표준의 한 부분으로 1996년부터 북미의 모든 차량에 구현되었다. 이 코드는 고장 진단장치가 차량으로부터 데이터를 얻는데 사용되는데 데이터를 요청할 때 OBD-II PID 코드를 정해진 프로토콜을 이용하여 차량으로 요청하여 응답을 얻는다. 중요 PID종류와 관련 응답 데이터 형식은 표 1과 같다. 모든 PID는 모든 차량에서 지원하는 것은 아닌데, 지원여부는 PID 00의 응답 값으로부터 알 수 있다.
표 1의 공식에서 사용되고 있는 알파벳 A, B, C, D 등은 수신된 데이터의 바이트 순서와 일치한다. 즉 첫번째 바이트는 A, 두번째는 B, 세번째는 C, 그리고 네번째는 D이다.

표 1의 Mode는 각 숫자별로 의미하는 내용은 표 2에서 알 수 있다. ECU의 각종 정보 데이터를 얻는 경우는 대부분 현재 데이터 표시용 Mode 0×01만 이용하면 되며, 차량의 고장진단 코드를 얻고자 하는 경우는 Mode 0×03를 사용한다.

차량으로부터 데이터를 얻기 위해 ECU로 PID를 전달하기 위한 질의 CAN 메시지 형태는 각 메시지 데이터 바이트 별로 다음과 같은 형식을 갖는다. CAN ID는 11비트를 사용하는 경우 반드시 0x7DF로 해야 한다.

CAN메시지 전체 8바이트 중 첫번째 바이트(Byte0)는 몇 바이트의 정보가 오는지를 의미 하는 것으로 그 뒤로 Mode와 PID Code가 각각 1바이트씩 2바이트가 오기 때문에 2가 되며, 세번째 바이트(Byte2)는 PID코드가 위치하고 그 이상은 사용되지 않으므로 0×55로 채워진다.

이상과 같이 생성된 CAN 메시지를 ECU로 전송하면 ECU는 다음과 같은 형태의 CAN메시지로 응답한다. 이때 응답으로 오는 CAN ID는 주로 0x7E8이며, 0x7E9나 0x7EA가 될 수 도 있다.

여기서 첫번째 바이트는 질의 메시지와 동일하게 이후에 올 추가 데이터의 크기이다. 두번째는 질의 메시지에서 사용된 Mode값에 0×40을 더한값과 같다. 내번째 부터는 질의한 PID에 대한 응답데이터가 온다. 데이터 크기는 1바이트부터 4바이트까지만 갖을 수 있어 마지막 Byte7은 사용되지 않아 0×55로 채워진다. 응답데이터는 첫번째 바이트부터 A, B, C, D로 명명되고 PID 표의 공식 부분에서 참조된다.

3.2 ECU 모니터링을 위한 전송 메시지 설정

이제 ECU로 전달해야 할 CAN메시지 형식을 알게 되었기 때문에 Analyzer에서 질의 메시지를 작성하여 보내 보고자 한다. 보낼 PID는 표 1에 나와 있는 것으로 하고, 각 PID별로 보내는 시간 간격은 10ms로 한다. 모든 PID를 모두 보내면 10ms 만큼 대기하고 다시 처음부터 PID전송을 반복 한다. 이것을 Analyzer의 “CAN Send Message Tool”에서 설정하는 방법은 다음과 같다.

1. Engine RPM 질의를 위한 CAN메시지 예는 다음과 같다.

A. 전송하므로 Task Type은 “TX”
B. 11비트 질의이므로 CAN ID는 0×7DF, 2.0B와 RTR은 설정하지 않음
C. DATA는 “02 01 0C 55 55 55 55 55”로 함, 여기서 0×0C Engine RPM 질의 PID임.
D. 추가 반복하지 않으므로 Repeat는 “0”
E. 10ms이후에 다음 메시지 전송하므로 Interval은 “10”
2. 위와 같은 형식으로 나머지 PID에 대해서 모두 추가 한다.
3. 모든 PID가 전송된 후 10ms대기를 위해 Task Type이 “WAIT”, Wait Time을 10으로 설정한다.

4. 다시 처음부터 반복 전송을 위해 Task Type을 “GOTO”, Goto Index는 “0”으로 설정한다.

이렇게 모두 입력되면 “CAN Send Message Tool”창은 다음과 같이 보여지며 전송준비는 완료되며 (GO)버튼을 클릭하면 CAN메시지가 전송되기 시작한다. 이때 대부분 차량내에 사용되는 CAN통신 속도는 500kbps이므로 사전에 CAN통신 속도는 맞춰져 있어야 한다. 그렇지 않은 경우는 Analyzer의 Error LED가 켜질 것이다.

그림2

3.3 ECU 모니터링을 위한 수신 메시지 설정

3.1절에서 OBD-II PID가 포함된 질의 메시지에 대한 ECU 응답 메시지에 대한 형식을 알아 봤다. 이 정보를 토대로 CANTALKER에서 지원하는 “Monitor CAN ID & Data” 기능을 이용하여 응답 메시지로부터 실제 물리적인 값들을 추출하여 그래프로 표시하여 보자.
응답 메시지 형식과 표 1의 공식 부분을 참고 하여 “Monitor Condition”을 작성하여 보자. “Engine RPM”작성예를 보면 다음과 같다.

1. Item Title은 제목인 “Engine RPM”을 기록한다.
2. “CAN ID To Monitor”는 모니터링 하고자 하는 CAN ID를 의미 하므로 0x7E8이 된다.
3. “Engine RPM”의 경우 PID가 0x0C인데, CAN메시지 8바이트 중 세번째 바이트가 PID이므로 이 값이 0x0C인 메시지를 찾기 위해 Mask와 Compare는 다음과 같이 설정한다.
4. Mask는 세번째 바이트만 관심 대상이므로 0xFF로 설정하고, Compare값의 세번째 바이트를 0x0C로 설정한다. 이유는 “MSG & Mask == Compare”공식에 의해 각 바이트에 대해 모두 참이 되면 수신 메시지를 사용하게 된다.
5. 이렇게 수신 조건에 의해 걸러진 “Engine PRM” 메시지에서 Engine PRM에 관련된 데이터를 추출하기 위해 다음과 같이 설정한다.
6. Engine RPM값은 CAN 메시지 8바이트 중 4번째 바이트부터 2바이트 크기를 갖기 때문에 “Offset”은 3, “Length”는 2가 된다. 추출된 2바이트에서 첫번째가 상위 두번째가 하위 바이트가 되는 Big Endian형식이므로 “Big Endian”에 채크한다. 또한 공식에 의해 2바이트 값을 4로 나누거나 또는 0.25로 곱해야 하므로 “Multiply”에 0.25를 입력한다. 최종 생성되는 값은 산술 계산된 정수형이므로“Display Data Format”을“Scaled Integer”로 선택한다.
7. 결과적으로 생성된 물리값은 그래프로 표시하고 싶으므로 “Display Type”을 “Graph”로 선택하고 최대 최소값을 각각 0과 6000으로 한다.
그 밖의 다른 Item들도 위와 같은 형식에 의해 공식을 참고하여 비슷한 형식으로 아래 그림3과 같이 모두 입력한다.

그림3.

3.4 실차량에서 모니터링 수행

3.2절에서 전송할 메시지들를 생성하고 3.3절에서 추출할 수신메시지 형식과 표시형식을 모두 설정하였으므로 실제차량에서 ECU에서 정보가 실제로 오는지 확인해 보자.
먼저 CAN 방식의 OBD-II가 지원되는 차량을 준비해야 한다. 대부분 최근에 생산된 차량은 거의 CAN 버스와 OBD-II를 지원하고 있다. 간혹 CAN은 지원하는데 OBD-II PID메시지에 대해 무응답하는 차량도 있으니 미리 확인해야 한다. Analyzer를 차량의 OBD-II단자에 연결하기 위해서는 OBD-II단자의 핀배열을 확인한 후 CAN 컨넥터와 맞게 케이블을 다음과 같이 제작해야 한다. OBD-II컨넥터는 디바이스마트에서 쉽게 구매할 수 있다.

그림4.

그림4에서 OBD-II Male Connector의 PIN6은 CAN_H, PIN14는 CAN_L 이므로 Analyzer DB9 Connector의 PIN7번과 PIN2번에 각각 연결한다. CAN_H와 CAN_L은 잘못 연결되어서는 절대 안되므로 주의 깊게 작업해야 한다.
커넥터 작업이 완료되면, Analyzer를 차량의 OBD-II단자에 연결한다. 차량에 전원이 들어가거나 시동이 걸려있어야 CAN 통신이 되므로 사전에 전원을 넣거나 시동을 걸어 놓는다. 만약 컨넥터를 연결하자 마자 Analyzer의 Error LED가 점등 된다면, (1) 500kbps 속도 설정이 제대로 안되었거나, (2) CAN_H, CAN_L라인 결선에 문제가 있거나 (3) 종단저항 연결이 ON되어 있는 경우일 수 있으므로 다시 한번 확인해 본다.
모든 준비가 완료되면, “CAN Send Message Tool”에서 (Go)버튼을 클릭하여 ECU에 질의 메시지를 전송시킨다. 그러면 아래와 같이 질의에 해당하는 응답이 수신되면서 그 값과 그래프가 표시된다.

그림5.

3.5 기타 차량 네트웍의 데이터 분석

차량에 Analyzer를 연결하여 보면 OBD-II PID질의 메시지를 보내지 않아도 수많은 메시지들이 수신되는 것 관찰 할 수 있다. 이 메시지들은 차량에 붙어있는 다양한 센서와 작동기 등과 ECU간에 정보 교류일 것인데 차량회사의 전용 프로토콜을 사용했을 것이다. 이에 알 수 없는 다양한 메시지들이 어떤 의미로 사용되는 것인지 분석하기 위한 방법을 본 절에서 제시하겠다.

그림6.

그림6은 뉴카렌스 차량에서 수신한 메시지들에 대해 “CAN Bus Statistics” 기능을 이용하여 어떤 메시지들이 있는지 통계를 보여주고 있다.
OBD-II PID와 관련된 CAN ID를 제외하고 총8개의 CAN ID가 사용되고 있다. 각 ID에 대해 실시간으로 값을 모니터링 하려면 CANTALKER의 “Monitor ID & Data” 기능에서 통계창에서 보여지는 각각의 CAN ID에 대해 “CAN ID to Monitor”에 ID를 입력하고,“Display Data Format”을 “All Data”로 설정하며 [Logging]을 체크하는 식으로 보든 CAN ID를 다음과 같이 입력한다.

그림7.

현재 차량에 연결되어 있는 상태라면 [RealTime]을 채크한 후 [Go]버튼을 클릭하면 실시간으로 수신되는 Data 내용을 볼 수 있으며 변화되는 내용이 쉽게 관찰될 수 있다. 만약에 이미 차량에서 데이터를 모두 수집한 상태에서 후처리로 확인하고 싶다면 [RealTime]을 끄고 [Go]버튼을 클릭한다. 처리가 완료되면 CANTALKER 프로그램에 있는 디렉토리에 “Item Title”을 파일이름으로 하고 확장명이 “log”인 파일들이 각각 생성된다. 예를들어 “test_271”에 대해서는 “test_271.log”로 생성된다.
그럼 관찰된 데이터로부터 좀더 깊이 분석을 하기 위해 329 CAN ID의 데이터를 확인해 보자. 다음은 수신된 메시지 로그의 일부이다.

20087.55           40 5D 7D 04 04 20 FF 14
20097.49           40 5D 7D 04 04 20 FF 14
20107.47           40 5D 7D 04 04 20 FF 14
20117.45           86 5D 7D 04 04 20 FF 14
20127.48           86 5D 7D 04 04 20 FF 14
20137.48           86 5D 7D 04 04 20 FF 14
20147.43           86 5D 7D 04 04 20 FF 14
20157.42           86 5D 7D 04 04 20 FF 14
20167.46           86 5D 7D 04 04 20 FF 14
20177.49           86 5D 7D 04 04 20 FF 14
20187.40           86 5D 7D 04 04 20 FF 14
20197.40           DE 5D 7D 04 04 20 FF 14
20207.63           DE 5D 7D 04 04 20 FF 14
20217.41           DE 5D 7D 04 04 20 FF 14
20227.37           DE 5D 7D 04 04 20 FF 14
20237.36           DE 5D 7D 04 04 20 FF 14

첫번째 컬럼은 timestamp이고 두번째가 메시지 내용이다. 메시지 내용을 보면 8바이트 중 첫번째 바이트만 변화되는 것을 볼 수 있다. 그럼 첫번째 컬럼에 대해 그래프로 확인하기 위해 “Monitor CAN ID & Data”기능에서 “test_329” item에 대해 “Calculation Information”과 “Display”를 다음과 같이 수정한다.

1. Offset             : 0
2. Length          : 1
3. Multiply       : 1
4. Add                : 0
5. Display Data Format : Scaled Integer
6. Display Type : Graph
7. Min                : 0
8. Max               : 256

이상과 같이 설정을 완료한 후 다시 [Go] 버튼을 클릭하면 다음과 같이 그래프가 그려지는 모습을 볼 수 있다. 정확하게 무엇을 의미하는지는 자동차 업계에서 일하는 사람이라면 알 수 있을지도 모르겠다.

 4. 맺음말

이상과 같이 차량의 ECU 정보값을 모니터링 하기 위해 OBD-II PID와 관련한 질의와 응답 프로토콜에 대해 확인하였고, 그 내용을 Analyzer에 적용하여 각각의 데이터를 수신하고 그래프까지 출력해 보았다.
필자도 그러했지만 많은 사람들은 정보가 없었을 때 차량의 ECU와 통신을 해서 각종 정보를 얻어내는 것은 자동차 회사에서 프로토콜을 공개하지 않는 이상 불가능 한 것으로 여겨 왔었다. 그러나 정말 단순한 OBD-II PID 프로토콜만 인터넷 검색으로 찾아본다면 차량의 각종 상태나 고장진단 등을 Analyzer로 매우 쉽게 해낼 수 있다는 것을 알게 되었다.
그 밖에 Analyzer에서 제공하는 CANopen이나 DeviceNet 프로토콜로 관련 프로토콜을 지원하는 다양한 장비들의 상태 체크나 고장진단 등에 활용할 수 있으며, 표준 프로토콜을 사용하지 않는 각종 장비나 차량 부품도 CAN버스 통계정보로 사용되는 모든 CAN ID를 찾아 낼 수 있고, 찾아낸 CAN ID에 대해 각각 실시간 모니터링 함으로써 그 메시지의 특성이나 프로토콜을 쉽게 알아 낼 수 있다.

5. 참고자료
http://terms.co.kr/CAN.htm
http://en.wikipedia.org/wiki/Controller_area_network
http://en.wikipedia.org/wiki/OBD-II#OBD-II
http://en.wikipedia.org/wiki/OBD-II_PIDs
Multi-CAN Analyzer & Converter User’s Manual (http://user.chollian.net/~ascbbs/can/MCA_100_Manual.pdf)

[6호] 위드로봇 무료강좌 기술자료 – 2차

2차 릴레이 무료강좌 기술자료

영상 처리 시스템 소개

글 | 위드로봇(주) 김도윤대표

위드로봇 연구실 확장 이전 기념 릴레이 무료 강좌 2차 교육이 2010년 12월 11일 토요일에 성수동 위드로봇 본사에서 진행 되었습니다. 영상 처리 시스템에 대한 주제로 진행된 이번 강좌의 강의 내용을 참석하지 못한 디바이스마트 매거진 구독자들을 위해 간단히 소개하고자 합니다. 

센서 관점에서 영상 처리

자동화 시스템을 구성할 때 대상 시스템의 상태를 정확하게 파악하기 위해 다양한 센서들이 사용된다. 예를 들어 모터의 속도를 정확하게 유지하는데 관심이 있다면 타코메타(Tachometer) 또는 엔코더(Encoder)를 센서로 사용하게 될 것이고, 어떤 물체가 특정 위치를 지나갔는지 아닌지를 판단하기 위해서는 접촉식 스위치 또는 적외선 LED 방식의 비접촉 검출 센서를 사용하게 될 것이다. 자동화 시스템에서 사용되는 센서는 무수히 예를 들 수 있겠지만 이러한 많은 센서들 중에서 가장 많은 정보를 포함하고 있는 센서로는 영상(Image)을 취득할 수 있는 이미지 센서를 꼽는데 전문가들은 주저하지 않는다.

영상은 3차원 공간 상에 존재하는 물체들이 광원의 빛 입자를 반사하는 파장대(색깔)를 2차원 공간에 투영한 것으로 데이터 안에 공간에 대한 기하학적인 정보(크기, 모양, 두께, 각도, 형태, 존재 유무)뿐만 아니라 색상 정보에 의한 추가 정보(대상 물체간의 그룹핑, 표면의 결함, 각 물체의 인식, 사람일 경우 얼굴 인식, 성별 인식, 나이 추정 등)까지 알 수 있어 그 활용도는 무궁무진하다. 정보가 많다는 것은 그 데이터의 크기가 크다라는 말과 직결되고, 영상 데이터의 크기 문제 때문에 이전 기술로는 실시간 처리가 어려워 산업체에서는 활발히 사용하기가 어려웠다. 하지만 빠르게 발전하는 전자공학과 IT 기술에 힘입어 이제 주변에서 손쉽게 영상 데이터를 취득할 수 있으며, 데이터의 가공, 조작이 쉬워졌다. 따라서 조만간 우리 주변에 많은 부분에서 이러한 영상 센서를 사용한 제품군들을 접하게 될 것으로 예상되며, 이런 기술을 가진 기술자, 전문가들 또한 많이 필요할 것으로 예상되어, 디바이스마트 매거진 독자들에게 해당 기술을 소개할 목적으로 본 원고는 작성되었다.

영상처리 시스템의 구성

전형적인 영상처리 시스템은 영상을 취득하는 카메라, 취득된 영상 신호를 원거리로 전송할 수 있게 변경하는 인코더, 그리고 이를 다시 복원하는 디코더, 마지막으로 영상을 출력 또는 처리하는 PC 또는 임베디드 시스템으로 구성할 수 있다. 이 중 영상처리 분야에서는 디코더 대신 해당 기능을 강조한 이미지 그래버(Image Grabber) 또는 프레임 그래버(Frame Grabber)라는 표현을 더 많이 사용한다. 현재 시장에 나와있는 대부분의 카메라는 인코더를 카메라에 내장한 형태로 나오기에 다시 정리해 보면 카메라-이미지 그래버-PC 형태로 정리할 수 있고 아래 그림과 같다.

그림 1. 영상 처리 시스템의 구성

위드로봇에 많이 문의하는 내용 중에 하나가 “2~3만원하는 USB 웹캠으로 영상을 받아 PC에서 처리하는 형태로 시스템을 구성하면 안되나요?”이다. 결론부터 말하면 “문제없다”이다. 예전에는 웹캠의 영상을 사용자가 작성할 프로그램 영역으로 가져오기 위해 MS Windows OS를 사용하는 경우에는 Direct Show 기술을 미리 알고 있어야 했지만, 최근에는 OpenCV(http://sourceforge.net/projects/opencvlibrary/)와 같은 공개 비전 라이브러리를 이용하면 매우 손쉽게 웹캠 영상을 바로 취득할 수 있으며, 여러 영상 처리 알고리즘을 라이브러리 레벨에서 바로 이용할 수 있다. 하지만 복수 개의 영상을 얻어야 한다든지, 렌즈 화각을 변경해야 한다든지, 노출 시간을 조절해야 하는 부분은 USB 웹캠으로는 해결하기 어려운 부분이다. 따라서 영상 처리 분야에 입문하는 분들이라면 USB 웹캠과 OpenCV로 학습을 하다가 일정 단계 지식이 쌓이면 카메라와 이미지 그래버를 구매하여 본격적인 연구를 진행할 수 있는 시스템을 구축하는 것도 좋은 방법이다.

영상 처리에서 가장 중요한 광원

위에서 전형적인 영상 처리 시스템은 카메라-그래버-PC 세 가지 조합으로 구성된다고 설명했다. 하지만, 이 세 가지 전체를 합친 것보다 중요한 것은 광원이다. 영상을 얻으려면 물체 자체가 발광하지 않는 한 외부에 어떠한 광원이 있어야 하는데, 영상은 광원의 종류, 개수, 위치에 따라 큰 차이가 발생하게 된다.

예를 들어, 참치캔을 제조하는 회사에서 참치캔 윗면에 주름이 제대로 있는지 없는지 확인하는 검사 장비를 의뢰했다고 가정해 보자. 전형적인 환경에서 카메라로 참치캔 윗면을 촬영한다면 아래 그림 2처럼 나올 것이다. 이 영상에서 참치캔 주름을 잘 찾아내는 일은 영상 처리 분야에 지식을 많이 가진 고수들도 꽤나 난감한 일이다. 주름 부분이 도드라진 부분도 있지만, 그림자로 인해 반대로 어두운 부분이 섞여 있으며, 참치캔 표면에 인쇄되어 있는 글씨들도 영상 처리에 많은 영향을 미친다. 이 사진 하나로 참치캔 주름의 유무를 찾아야 한다면 꽤나 복잡한 영상 처리 알고리즘을 동원해야 하고, 그런다손 치더라도 다양한 참치캔에 일일이 적용해 보기 전에는 그 결과를 장담할 수 없는 시스템이 만들어진다. 하지만 광원을 바꿔 촬영할 수 있다면 이는 매우 손쉬운 문제로 바꿀 수 있다.

그림 2. 전형적인 참치캔의 윗면을 일반 광원에서 촬영한 영상	그림 3. 좌측 그림처럼 돔형 광원을 배치하고 거리를 달리하여 영상을 촬영하면 중앙과 우측의 영상을 얻을 수 있다.

위 그림3과 같이 돔형으로 생긴 광원을 이용하여 참치캔 적정 거리에서 영상을 하나 얻고, 광원을 참치캔에 좀 더 접근하여 또 다른 영상을 얻으면 중앙과 우측과 같은 영상을 얻을 수 있다.
두 영상을 비교해 보면 하나의 영상은 참치캔 주름이 그림자로 짙은 색으로 표현되어 있고, 다른 한쪽은 주름의 그림자가 사라진 것을 볼 수 있다. 두 영상의 차이를 추출하면 간단히 참치캔의 주름 부분을 파악할 수 있어 매우 손쉬운 문제로 바뀐다.

위 예에서 볼 수 있듯이 지능적이고, 고도로 복잡한 영상 처리 알고리즘보다 잘 선택한 광원으로 얻은 영상과 간단한 영상 처리 알고리즘의 조합이 훨씬 더 좋은 결과를 내는 경우가 많다. 가장 좋은 디자인은, 더 이상 뺄 것이 없는 디자인이라는 말이 있듯이 가장 좋은 시스템은 복잡한 것이 아니라, 간단하고 명료하면서 정확하게 동작하는 시스템이다. 아쉬운 점은 이러한 광원에 대한 연구는 학계에서 보다는 산업체 현장에서 더 강조되고 있기에 체계적인 매뉴얼에 의해 광원 선정 및 배치가 이뤄지기 보다는 현장에서 경험한 시행착오에 의해 결정되고 있다. 보다 많은 영상 처리 전공자들이 이러한 광원에 대한 여러 경험치를 공유하고 정리된다면 영상 처리 분야의 발전을 보다 당길 수 있을 것으로 기대된다.

너무나 넓은 영상 처리 분야

이러한 영상 처리 분야를 본격적으로 학습하려면 어디서부터 무엇을 하는 것이 좋을까? 앞에서 언급했듯이 영상 데이터 자체에 워낙 많은 정보가 들어있어 영상 처리의 목적에 따라 각각의 관심 분야가 달라지기에, 내가 최종적으로 무엇을 원하는가를 명확하게 알고 있어야 한다. 영상 처리에 관하여 권위 있는 AIA(Automated Imaging Association)에서는 다음과 같이 영상 처리 분야를 Machine Vision, Image Processing, Computer Vision으로 세 분류로 나눠났다. 각각의 특징은 여러 가지로 설명할 수 있겠지만 Image Processing과 Computer Vision 분야는 아무래도 그 차이점을 구분하기가 모호한 것이 사실이다. 따라서 위드로봇에서는 Computer Vision 분야 대신 Computer Graphics로 표현을 변경하고 그림 4의 좌측 표로 세 분류간의 차이를 설명하곤 한다.

그림 4. 좌측-AIA 에서 제안한 영상 처리 분야, 우측-위드로봇 관점의 영상 처리 분야 grouping

위 표를 보면서, 각 분야의 차이점을 따져보자. 입력으로 영상을 넣고 출력을 영상으로 얻는 것에 관심이 있는 경우는 Image Processing 분야가 된다. 만일 여러분이 포토샵과 같은 툴을 이용해 작업하는 분야에 관심이 있다면 이는 Image Processing 분야가 된다. 입력은 영상이 아닌데 출력이 영상으로 나오는 경우는 Computer Graphics 분야가 된다. 각종 3차원 기하학적인 정보와 광원의 속성들을 입력하여, 가상의 이미지를 얻어내는 분야가 Computer Graphics 분야이다. 세 번째로 영상을 입력하여 영상이 아닌 다른 데이터를 얻어내는 것에 관심을 가지는 분야가 Machine Vision 분야이다. 예를 들면 각종 영상 기반 검사 장치에서 제품에 하자는 없는지, 인쇄는 제대로 되었는지 등을 영상을 통해 파악하는 경우는 Machine Vision 분야에 속하게 되는 것이다. 마지막으로 영상이 아닌 것을 넣어 영상이 아닌 정보를 얻는 것은 당연히 영상 처리 분야에 속하지 않으므로 이 자리에서 언급할 필요는 없어 보인다.

위에서 소개한 세 분류는 각각의 목적에 따라 알아야 할 지식, 관심을 가지는 방법론들이 서로 다르다. Image Processing을 전공하는 사람들은 주로 2D Signal Processing에 관심이 많다. 2D Matrix로 표현되는 선형 필터를 설계하거나, 압축을 위해 Mpeg을 연구하는 분들이 이 부류에 속한다. 반면에 Machine Vision의 경우는 카메라 내부, 외부의 기하학적인 정보(Intrinsic, Extrinsic Parameter)를 정확하게 얻어내기 위한 카메라 캘리브레이션(Camera Calibration)이 가장 기초가 되며 한 장의 영상으로 원하는 정보를 얻지 못하는 경우 여러 장의 이미지에서 원하는 데이터를 추출하는 Multi-view Geometry에 관심을 가진다. 자신이 현재 해결하고자 하는 영상 처리 문제가 어디에 속하는 문제인지 파악하는데 어려움을 겪고 있는 독자가 있었다면, 위 표로 조금이나마 도움이 되길 바란다.

색의 수학적 표현

우리는 초등학교 시절부터 색은 3원색으로 구성되며 Red, Green, Blue (RGB)라고 배워왔다. 정말 색은 R + G + B의 조합으로 구성될까? 특정 색이 RGB로 표현된다는 뜻은 수학적으로 보면 3가지 색상이 각각의 좌표축을 이뤄 공간을 형성하며, 이 공간이 벡터 스페이스가 되어야 한다. 하지만 RGB 는 단지 인간의 편의에 의해 만들어진 공간이기에 RGB 공간 상에서는 일반 대수 연산이 아무런 의미를 가지지 못한다.

그림 5. RGB 공간에서 색의 표현

설명이 복잡하니 좀 더 쉽게 설명해 보자. 어떤 물체의 색상이 잘 칠해졌는지 잘못 칠해 졌는지 판단하는 영상 처리 시스템을 만든다고 가정해 보자. 카메라로 물체를 촬영하여 색상 정보를 추출한 뒤 내가 원래 가지고 있는 색상과 얼마나 차이가 나는지를 어떻게 프로그램 할 것인가?

RGB 공간에서 프로그램 한다면 원래 알고 있는 색상의 각각 R, G, B 값과 측정한 물체의 R, G, B 값을 빼서 그 차이가 크면 원본과 차이가 많이 난다고 할 수 있을 것이다. 그런데 R 값의 차이와 G 값의 차이는 1:1 같은 의미를 가지는가? 어떤 샘플은 G와 B는 일치하는데 R 값은 차이가 Alpha 만큼 났고 또 다른 샘플은 R과 G는 일치하는데 B 값은 Alpha 만큼 났다. 그러면 이 두 샘플은 원본과 비슷한 정도로 차이가 나는 걸까? 아쉽게도 RGB 공간은 벡터 스페이스가 아니기에 이러한 뺄셈은 서로 비교가 불가하다(정확한 표현은 벡터 스페이스가 아니면 뺄셈이라는 연산이 정의가 되지 않는다). 원리가 이러한데 아무런 사전 지식 없이 색상의 차이를 RGB 공간에서 비교하겠다고 프로그래밍을 작성한다면 아무리 복잡한 알고리즘을 들이민들 해결책을 찾기란 꽤나 어려울 것이다.

다행히 벡터 스페이스 정의를 만족하는 CIE 색공간이 정의되어 있으며, RGB 공간을 조금은 복잡하지만 CIE 색공간으로 바꿀 수 있다. CIE 공간에서는 위에서 설명한 색상 차이를 정확하게 계산해 낼 수 있다. CIE 공간으로 바꾸는 수식이 꽤나 복잡하여 연산량이 많기에 산업체 현장에서는 CIE 공간 효과를 볼 수 있는 YUV나 YIQ 색공간에서 위와 같은 작업을 대신하기도 하지만 엄밀한 의미에서 이 공간들도 벡터 스페이스 정의를 만족시키지는 못한다.

영상 전송 방식

앞의 글에서 영상 신호를 원거리로 전송하기 위해 특정 신호 규약으로 인코딩을 한다고 밝혔다. 일반적인 CCTV 카메라들은 국내에서는 NTSC 신호 규약으로 아날로그 방식으로 전송하고 있으며, 웹캡에 사용되는 CMOS 센서들은 ITU BT.601 또는 BT.656으로 전송한다. 영상 처리를 하려면 이러한 신호를 다시 풀어 접근이 가능한 메모리 영역에 영상을 집어 넣어야 하기 때문에 이러한 전송 방식에 따른 특장, 장단점을 잘 알고 있어야 한다.

아날로그 전송 방식은 국내의 경우는 거의 예외 없이 NTSC 방식을 따르므로 NTSC 신호를 디코딩 할 수 있는 장치, 즉 이미지 그래버가 필요하다. 이러한 이미지 그래버는 PC에 연결하는 방식에 따라 다시 PCI(또는 PCI Express) 방식과 USB 방식으로 나뉜다. CPU 점유율, 전송 지연 시간, 영상의 품질 등에서는 아무래도 PCI 방식이 USB 방식에 비해 낫다. 하지만 PCI 방식일 경우 부피가 큰 데스크톱 PC에만 설치가 가능하므로, 이동이 잦고 노트북이나 PCI 슬롯이 없는 환경에서는 USB 타입의 이미지 그래버가 필요하게 된다. 이러한 이미지 그래버를 사용하면 NTSC 신호로 전달되는 영상 신호를 사용자가 접근할 수 있는 영역까지 전달하는 라이브러리를 제공하므로 손쉽게 프로그래밍 할 수 있다.

CMOS 센서의 경우 BT.601/656 데이터 신호를 PC에서 직접 받을 수 있는 장치는 없다. 따라서 이 신호를 기존 PC가 가지고 있는 USB나 기타 인터페이스에 맞게 변형하여 전달해야 하는데, 아직 시장이 형성되지 않은 관계로 상용품은 찾기 어려우며, 주로 개발 용역 과제 형태로 진행된다. 특정 CMOS 센서를 이용해서 시스템을 구축해야 하는 경우라면 외주 용역 형태로 개발 또는 자체 개발을 해야 할 것이며, 센서 모델이 딱히 정해지지 않은 경우라면 일반 웹캠을 이용하는 것도 한 가지 방법이다.

임베디드 비전 시스템

1990년대까지만 해도 영상 처리는 고가의 PC에서도 실시간으로 처리하기 어려울 만큼 연산량이 많은 분야였다. 하지만 눈부시게 발전하는 반도체 기술로 인해 이제는 손바닥에 올라갈 만큼의 조그마한 임베디드 마이크로프로세서 보드들이 2000년대 중반에 나온 PC의 성능만큼을 가지게 되어 매우 복잡한 알고리즘이 아니면 이러한 임베디드 보드에서도 실시간 처리가 가능하게 되었다.

그림 6. 2011년 하반기 출시 예정인 Smart-I 플랫폼

위드로봇에서는 이러한 시대의 흐름에 맞춰 Smart-I 라는 임베디드 비전 플랫폼을 만들어 출시할 계획이다. 실수 연산이 가능한 ARM11 프로세서와 CMOS 1.3M 화소의 카메라를 내장하고, PC와는 USB로 연결이 된다. 이 보드에는 OpenCV가 이식되어 있으며, PC쪽으로 영상을 USB를 통해 전송하여 PC에서 처리 결과를 바로 확인할 수 있다. 또한 PC쪽에서 작성한 알고리즘이 별다른 변경 없이 바로 Smart-I 플랫폼에서 동작할 수 있도록 환경을 구축하여 보다 편리하게 영상 처리 개발자들이 임베디드 비전 시스템을 사용할 수 있을 것이라 기대하고 있다. Smart-I 플랫폼은 2008년도에 그 원형이 개발 완료되었지만, 이러한 편리한 기능을 갖추기 위해 시간이 많이 소요되었으며, 2011년 올해 드디어 공개할 수 있을 것으로 보인다.

인간의 시각 시스템과 비교

마지막으로 영상 시스템은 인간의 시각 시스템과 그 구조, 구성이 매우 유사하기에 인간의 시각 시스템과 자주 비교되곤 한다. 카메라의 해상도, 즉 화소는 인간의 망막에 있는 시세포와 동일한 기능을 한다. 디지털 카메라의 성능을 비교할 때 몇 만 화소인가를 이야기하는데, 최근 시장에서 많이 판매되는 디지털 카메라의 경우는 약 천 만화소급이 많이 보인다. 그렇다면 인간의 시세포는 몇 만 화소쯤 될까? 재미있게도 1:1 비교가 조금은 힘들다. 디지털 카메라의 화소는 영상을 얻는 전체 영역에 같은 분포로 배치가 되어 있지만 인간의 경우는 그렇지 않기 때문이다. 그 이유는,

1. 인간의 망막에는 흑백 명암만을 구별하는 간상체(Rod)와 색상을 인식하는 추상체(Cone)로 나눠져 있다.
2. 추상체와 간상체의 배치가 디지털 카메라의 화소처럼 바둑판 모양으로 균일하게 배치되어 있지 않고, 망막 중심에 집중적으로 배치되어 있다.
3. 일반 카메라는 렌즈와 센서가 하나지만, 인간은 두 개다.

1번을 상세히 설명해 보면 인간의 눈에는 흑백 센서와 컬러 센서가 따로 존재한다는 뜻이 된다. 하나의 눈에 300만개 이상의 추상체가 있는 것으로 알려져 있다. 생각보다 적은 수치인데 반면 흑백 명암을 구별하는 간상체는 약 1억개 이상으로 추정된다.

2번의 내용은 컬러를 인식하는 추상체의 경우 눈을 움직여 어느 한 곳을 응시할 때, 상이 맺히는 망막에 집중적으로 분포하고 그 외 지역에는 듬성듬성 배치되어 있다. 이러한 이유로 우리는 무엇인가 집중적으로 보려고 할 때, 고개와 눈동자를 돌려 관심있는 물체를 응시하는 습관이 나오게 되는 것이다.

3번 내용은 매우 복잡하다. 아직까지도 인간이 3차원 공간을 어떻게 인지하는지 전문가들 사이에서도 의견이 분분하다. 확실한 것은 하나의 2차원 이미지로는 3차원 공간에 대한 정보를 얻을 수 없기에 눈 두 개를 이용하여 사라진 3차원 공간에 대한 정보를 복원하는 것인데, 단순히 이러한 스테레오 매칭만으로는 인간의 뛰어난 인지 능력을 설명하기에는 부족하다. 최근 뇌공학자들의 집중적인 연구에 의해 밝혀진 부분은 단순히 영상이 뇌로 전달되는 경로(feed-forward path)만 있는 것이 아니라, 뇌에서 다시 되먹임 경로(feedback path)를 통해 상위 레벨의 정보가 하위단으로 내려오는 부분이 있다는 점이다. 이는 단순히 두 개의 눈으로 들어온 정보만으로 3차원 공간을 인지하는 것이 아니라, 기존 학습에 의해 인지하고 있는 정보를 추가로 이용하여 공간을 인지한다는 가설을 뒷받침하는 강력한 증거이기도 하다. 스테레오 비전 시스템은 이 주제만으로 한참 설명을 해야 하므로 다음 번 디바이스마트 매거진을 통해 소개하기로 한다.

마감하며

영상 처리 기술을 소개한다며 정작 영상 처리 알고리즘에 대한 이야기는 한 마디도 언급이 안되었다. 이는 디바이스마트 매거진 독자층을 고려한 것인데, 현재 영상 처리 분야에서 활동하시는 분이라면 최근 이슈가 되고 있는 알고리즘의 동향(예를 들면 SIFT, SURF 등등의 특징점 추출 알고리즘)의 소개를 기대했을지 모르겠다. 하지만 위드로봇에서 공개강좌를 했을 때 접한 대다수 분들은 영상 처리에 대해 관심을 가지고 막 시작하려는 분들이 대부분이었기에, 우선 본격적인 알고리즘이나 이론을 소개하기에 앞서 영상 처리 분야가 이런 것이고 이런 부분이 중요하다는 점을 강조하고 싶었다. 다음 번 원고(스테레오 영상 및 3D Vision 기술)도 현재 작성 중인데 이 때 알고리즘과 이론들을 설명하는 것으로 이번 호를 마친다.