우리는 CAN 통신의 기초지식을 알아보고 CAN 데이터베이스가 어떻게 작동하는지 살펴보았다. 지금 우리는 CAN에서 통상 사용되는 몇 가지 통신규약을 살펴볼 것이다.
지난 글에서 우리는 메세지의 각 bit가 특정 의미를 가지게 되는 CAN 데이터베이스에 대헛 살펴 보았다. 예를 들면, ID 0x400인 CAN 메세지의 첫 번째 bit는 현재 엔젠이 켜져 있는지 아닌지를 표현해준다.
그러나, 좀 더 복잡한 통신에 대해선 우리는 통신규약(protocol)의 사용이 필요하다. 이것은 데이터를 주고 받기 위한 구조에 동의함으로써 많은 의미를 하나의 단일 CAN ID에 부여할 수 있습니다.
OBD-II
자동차 운전석에 앉은 다음 여러분의 왼쪽 무릎 주위를 살펴보자. 여러분은 위의 사진과 같은 커넥터를 찾을 수 있을 것이다. 이것이 OBD-II 커넥터이다.
OBD-II 통신규약은 CAN 통신과는 별개의 것이다. 이 규약은 CAN 뿐만아니라 UART, PWM 채널 위에서도 구현 될 수 있다. OBD-II는 California Air resources Board가 1991년에 캘리포니아에서 판매되는 모든 자동차를 위한 진단용 통신규약으로 요구하였을때 출현하게 되었다. 이거은 새로운 자동차에서 CAN 통신 위해서 통상 구현되었기 때문에 이 커넥터는 여러분에게 최소한 자동차의 CAN 통신 버스에 접속할 수 있는 하나의 통로가 되어 준다.
OBD-II는 자동차의 파라미터와 오류코드를 읽는데 사용된다. 다양한 OBD-II 모드의 사용으로 여러분은 자동차의 상태에 관한 파라미터 IDs(PIDs)들이 포함하는 정보를 읽을 수 있다. Wikipedia는 OBD-II 모드와 PIDs에 관한 대단한 글들을 가지고 있다.
OBD-II에 관한 많은 정보들은 이글 밖에 있다. 그리고 여러분은 오류코드를 읽고 성가신 엔진 점검 경고들을 지울 수 있는 20달러 이하의 도구를 구매 할 수 있다. OBD-II에 관한 자세한 사항에 대해서 알아보는 대신, 이것의 독재자(big brother)에 대해서 이야기 해보도록 하자.
하나로 통합된 진단 서비스(Unified Diagnostic Services)
많은 자동차 광들은 OBD-II에 친숙 하지만, 많은 이들은 Unified Diagnostic Service(UDS)에 대해서 들어보지 못했을 것이다. 이것은 불행이다. 왜냐하면, OBD-II는 그져 UDS의 한 부분이기 때문이다. OBD-II는 단지 제한된 서비스만 제공하는 반면, UDS는 제조사와 기술자들이 사용하는 진단 규약이다. 이것은 진단하고, 보정하고, 펌웨어를 굽는데 필요한 모든 종류의 서비스를 제공한다.
UDS는 한 Byte의 Service ID(SID)와 인지되어지는 ReadDataByIdentifier와 TransferData 같은 다양한 종류의 서비스를 가지고 있다. 0x0F로 시작하는 SIDs들은 OBD-II를 위해서 예약되어 있고 나머지는 표준에 의해서 혹은 제조사에 의해서 정의 된다. 여기에 표준 UDS 서비스의 리스트와 그들의 헥사코드 지시자들이 있다.
- DiagnosticSessionControl – 10 hex
- ECUReset – 11 hex
- SecurityAccess – 27 hex
- CommunicationControl – 28 hex
- TesterPresent – 3E hex
- AccessTimingParameter – 83 hex
- SecuredDataTransmission – 84 hex
- ControlDTCSetting – 85 hex
- ResponseOnEvent – 86 hex
- LinkControl – 87 hex
- ReadDataByIdentifier – 22 hex
- ReadMemoryByAddress – 23 hex
- ReadScalingDataByIdentifier – 24 hex
- ReadDataByPeriodicIdentifier – 2A hex
- DynamicallyDefineDataIdentifier – 2C hex
- WriteDataByIdentifier – 2E hex
- WriteMemoryByAddress – 3D hex
- ClearDiagnosticInformation – 14 hex
- ReadDTCInformation – 19 hex
- InputOutputControlByIdentifier – 2F hex
- RoutineControl – 31 hex
- RequestDownload – 34 hex
- RequestUpload – 35 hex
- TransferData – 36 hex
- RequestTransferExit – 37 hex
UDS는 제어기에 데이터를 보내는데 frame 구조를 사용한다. Single Frame(SF)들은 모든 데이터가 6byte에 적합한 짧은 메세지를 위한 것이다. 만약 데이터가 길어 지게되면, FirstFrame(FF)는 전송을 시작하기 위해 보내진 다음 Consecutive Frames(CF)가 데이터를 가지고 보내진다. 여기에 frame들이 어떻게 구조화 되었는지를 보여주는 형태가 있다.
 |
| SF, FF 그리고 CF 메세지들의 구조 |
OBD-II는 단지 첫 번째 frame 구조만 사용하지만, 다른 것들은 펌웨어 다운로드 같은 긴 데이터를 위해서 유용하다.
어떻게 모든 서비스들이 동작하는지를 들여다 보기 위해서 여러분들은 ISO 14229의 복사본이 필요할 것이다. 불행하게도 PDF만 구하는데도 250달러 정도를 지불해야할 것이다. USD로 통신할 수 있는 도구들은 매우 비싸다. 그러나 이러한 기초적인 지식을 가지고 있다면 여러분은 신호선로에서 무슨 일이 일어나는지를 들여다 볼 수 있을 것이다.
OpenXC
UDS가 개방되지 않은 통신규약인 반면, Ford사의 연구자들은 자동차와 연동하기 위한 개방된 platform을 구축하는데 힘써 왔다. 그 결과가 OpenXC Platform이다. OpenXC는 CAN위에서 Ford사의 차량으로 부터의 데이터를 읽는 통신규약이다.
이것을 사용하기 위해서 여러분은 차량 인터페이스를 필요로 한다. chipKIT은 Ford사의 오픈 소스 펌웨어와 사용되어 질 수 있다. 아니면 그 대체용으로 여러분은 CrossChasm로 부터의 사전에 구축된 솔루션을 살 수 도 있다. 한번 차량 인터페이스를 구축되고 연동되면, 여러분은 안드로이드나 Python APIs를 이용해서 데이터에 접근할 수 있다. 우리는 지난 글에서 몇 가지 OpenXC hacks on Hackaday 것을 마련해 두었다.
자동차 제조사가 오픈소스를 수용하는 것을 보는 것은 대단한 일이다. 그리고 Ford사는 희망적으로 이 platform에서의 작업을 계속하고 있다. 이러한 사실은 OpenXC의 통신규약이 단지 읽고 아주 작은 메세지 그룹만으로 제한되어 있다는 것을 의미 한다.
지금 현재 우리는 통신규약에 대한 모든 것들을 알아 보았다. 이제는 CAN 하드웨어를 만들어 보아야할 시간이 되었다. 다음 주에 우리는 여러분 자신의 프로젝트에 CAN을 사용하기 위해서 어떤 하드웨어가 필요한지 살펴 볼 것이다.
댓글 없음:
댓글 쓰기