레이블이 vehicle인 게시물을 표시합니다. 모든 게시물 표시
레이블이 vehicle인 게시물을 표시합니다. 모든 게시물 표시

2020년 7월 17일 금요일

[번역] 현대 자동차 소수 연료전지(fuel cell) 트럭 방향으로 밀어 붙이다. by Lewin Day

Originated at https://hackaday.com/2020/07/16/hyundai-makes-push-towards-fuel-cell-trucking/



현대 자동차는 상업용 운송차 시장에서 배터리 전기차 트럭에 대응하여 수소연료전지(fuel-cell) 기반의 중장비 트럭을 출고하기 시작했다.

배터리 전기 차량은 좀 더 일반적으로는 전기차는 일상에서 볼 수 있을 정도로 세상에 나타나기 시작하였다. 하지만, 자연친화적 운송으로 전환할때 도시에서만 적용되는 게임이 아니다. 수소연료전지(Fuel cells)은 전기를 생산하는데 수소 탱크를 사용하고 부산물로 물(H2O)을 양산하기 때문에 당황스러운 충전 시간이 필요없이 오랫동안 주변에서 오염을 제거하기로 기대를 받아 왔다. 그렇지만 지금까지 큰 영향력을 만들어 내지 못하였다. 그러나 현대 자동차는 여전히 이러한 개념에 가치가 있다고 생각하고 있다. 그리고 그에 대한 더 많은 증거를 제시하는 XCIENT Fuel Cell 트럭을 개발 하였다.

32KG의 수소로 400KM

그져 단순한 포로토타입이 아니고, 현대 자동차는 리스 고객에서 많은 양의 자동차를 이미 출하하고 있다.

현대 자동차는 이 프로젝트에 집중 투자 해왔다. 상업용 중장비 회사에서 사용할 목적으로 스위스에 첫번째 10대의 수소연료전지(Fuel Cell) 트럭을 출하하였고, 올해 말까지 필드 테스트에 40대의 트럭을 추가하려고 계획하고있다. 2025년까지 1600대의 트럭을 운용하기를 목표로 하고 있다. 이 의미는 년단위로 수백대의 주문에 생산가능한 역량을 의미한다. 이 클라스의 트럭이 전세계적으로 년당 수백만대의 판매량을 보이는 것에 비하면 미약하다. 하지만, 그럼에도 불구하고 기술 개발에 강력한 의지를 보여주고 있다.

32.1kg의 수소로 400Km 운용 능력은 트럭이 일반적인 장거리 운송 범위를 충분히 넘어 선다. 단기적으로 디젤 대형 굴착 장치와 경쟁 할 가능성은 없지만, 짧은 충전 시간은 모든 전기차가 가지고 있는 showstoppers(관심을 거두게 하는 요소) 중 하나를 극복한다. 현대 자동차의 다음 목표는 재충전 사이의 거리가 1,000km에 도달하는 것이다. 이것은 일반적인 트럭의 교대 길이에 가까워지게 된다. 트럭은 190kW의 총 에너지를 위해 95kW를 땡겨쓸 수 있는 두 개의 수소연료전지(Fuel Cell)를 사용한다. 이것은 큰 수량이 아니며, 이러한 차량에게 더 중요한 것은 토크이다. 전기 모터가 제공하는 즉각적인 twist(???)를 가지고 현대의 원동기는 이와 관련하여 전통적인 디젤 경쟁자와 차별되는 자신의 영역을 구축해야 한다.

그러나, 이 회사는 수소연료전지(fuel cell) 기술에서 이방인이 아니다. 토요타와 같이 그들은 몇년동안 이 시장에 존재하였다. 현대 자동차의 첫 번째 큰 이정표는 과거 2001년의 산타페 Fe FCEV의 개발이었다. 그 이후로 그들은 전세계의 선정된 시장에서 새로운 모델로 좀 더 갈고 닦아 왔다. 넥소는 5.6kg의 수고로 570km의 주행거리를 제공하는 최근의 성과이다. 이미 생산이 준비 되어 있지만, 아직 전세계적으로 판매를 개시한 것은 아니다. 제한된 인프라는 미국에서의 차량 소유자가 특혜를 위해서 캘리포니아로 이주해야 한다는 것을 의미합니다.

넥소는 수소연료전지 기술을 가지고 있는 현대적인 SUV 최신모델이다. 그러나, 알맞은 인프라가 있는 지역에 있지 않다면, 여러분은 하나 구매하는 것이 어렵다는 것을 알게 될것이다.

대체 연표 트럭의 출현

전세계의 도시들은 지구 기후와 지역 오염의 영향으로 화석연료 차량을 제거하도록 밀어 붙이고 있다. 배터리 전기 차량은 전통적으로 이러한 문제점의 해결책으로써 존재하여 왔지만, 긴 충전 시간과 비용은 비판자들을 끌어 모으고 있다. 인프라가 이러한 문제점을 해결하기 위해서 전세계적으로 구축되고 있지만, 많은 사람들에게서 드러나는 방해 요소로 뚜렷하게 대두되는 사안들이 남아있다.

수소연료전지(Fuel Cell) 차량은 배터리 의존적인 차량을 가지고 있는 사람들에게서 돌고있는 매력적인 특성을 가지고 있다. 시중에 있는 배터리가 최선의 경우 몇 십분의 의미있는 충전시간을 가지고 있는 반면에, 수소 연료 전지(fuel cell) 차량은 기존의 화석 연료 차량의 충전 시간과 동일한 시간안에 수소 탱크를 다시 채울 수 있다. 이상적인 수소 에너지 세상에선 집에 자신 소유의 충전기를 가질 필요가 없다. 그져 간단히 수소 주유소로 가서 추가적으로 연료 뚜껑만 위로 올리면 된다. 이 차량은 아무런 이산화 탄소 배출이 없는 긍정적은 요소를 유지한다. 미세먼지나 질소 산화물같은 다른 해로운 오염물은 말할 것도 없다. 이러한 점은 까다로운 배출규제를 유지하면서 상품들을 주기적으로 배달해야 하는 과밀 도시 중심부에서는 중요한 부분이다.

수소연료전지(fuel cell) 기술의 두 개의 주요 단점이 남아 있다. 첫 째는 인프라. 지금 시점에서 전세계적으로 단지 듬성듬성 분산되어 있는 한줌의 수소 충전소만 있다. 2014이후로 수소연료전지 차량이 시장에 존재하여 왔지만, 전 세계의 몇몇 지역만이 이들을 사용할 수 있게끔 해주는 필요 조치를 해왔다. 경쟁자인 전기차에 비해 적은 기반을 가지고는 빠른 시일 안에 변화를 기대하기는 쉽지 않다. 또 다른 하나는 수소 생산이다. Steam reforming 기술(CH4 + H2O ⇌ CO + 3 H)은 저렴하지만, 배출 측면에서 공정의 오염원으로 탄화수소를 포함하고 있다. 이러한 점은 깨끗한 운송 수단이 되도록 하는 이득을 다소 제거하는 요소이다. 대체제로써 물의 전기 분해(electrolysis of water)가 수소를 생산하는 또 다른 한가지 방법이다. 이것은 반응로의 에너지로 사용되는 발전과정 만큼이나 깨끗하다. 하지만, 더 비용이 들어 간다. 그리고 단순히 직접 배터리 전기 차에 충전하는데 전기를 사용하는 것 보다 효율을 좋지 못하다.

Tesla Semi 같은 배터리 전기차는 현대 자동차의 수소연료전기 트럭의 주요 경쟁자일 것이다.

그러나 현대자동차의 트럭의 중장비 영역은 수소연료전기 기술에 있어서 좋은 기회이다. 인프라의 문제점은 상업용 fleet(함대)에 사용되는 차량에 있어서 덜 중요하다. 그들은 차고에서 정기적으로 운영되기 때문에, 통근하는 인구를 위해 모든 곳에 수소 충전소를 설치하는데 드는 것에 비해, 적은 수의 충전소를 더 감당할 수 있는 비용으로 화물 네트워크에 설치할 수 있다. 추가적으로, 프로젝트의 기후적인 이득을 유지하기 위해 회사가 깨끗한 공정에서 생산된 수소를 확보하도록 할 수 있다. 또한 중장비 차량이 도시 주변이나 안에서 운용될 수 있도록 하는 기대되는 방법이다. 지금은 더많은 오염원을 발생하는 차량은 금지하고 있다. 배터리 전기 트럭은 이 시장에서 어렵게 경쟁하고 있지만, 느린 충전시간의 장벽을 떨쳐버리기를 원하는 회사에게 수소 연료전지는 설득력있는 대체제를 제공할 것이다.

수소연료전지가 통근 영역의 시장에 있어서도 배터리 전기차를 넘어 설 수있는 기회가 점점 좁혀져 가고 있어 보인다. (비록 테슬라, 니싼, 다른 자동차 메이커들이 수천대 이상 많이 수소 경쟁자 보다 많이 팔요 있지만,) 그러나, 깨끗한 트럭의 전쟁은 단지 시작이 뿐이다. 재충전 문제의 뚜렷한 해결책과 주요 화물 도로를 따라 수소 인프라를 구축하는 가능성을 가지고 여러분의 다음번 온라인 주문을 배송하는 트럭이 수소연료전지로 구동될 가능성이 매우 큽니다.





2013년 11월 16일 토요일

[번역] CAN 통신 해킹하기 : 하드웨어



 지금까지 우리는 CAN의 기초, 차량내 네트워크, 그리고 CAN 위에서 사용되는 통신규약에 대해서 논의하여 왔다. 우리는 CAN 도구에 대한 논의와 여러분 자신의 하드웨어를 만들기 위한 부품을 완성하여 나갈 것이다.

배선하기

 불행하게도 CAN을 접속하는데 어떤 표준이 존재하지는 않는다. 고속의 CAN을 위한 대부분의 공통된 커넥터는 7번핀에 CAN high와 2번핀에 CAN low를 갖는 DE-9이다. 그러나 케이블들은 서로 다를 것이고 많은 것들이 호환성이 없다.

 CAN은 신호선의 양 끝에 120옴 저항에 의해서 적절히 마무리 될 필요가 있다. 실제적으로 여러분들이 종단을 다룰때 신호선로에 한 개의 120 옴 저항을 붙일

수 있다.

도구들

 좋은 CAN 도구는 여러분이 CAN 메세지들을 주고받고, CAN 데이터베이스를 사용해서 데이터를 해석하고 CAN 통신규약을 구현할 수 있게 할 것이다. 이러한 특성을 갖는 도구들은 개방성이 없는 독점적 소유물이고 비싸지만, 몇몇의 해커에 친숙한 대체품들이 존재한다.

GoodThopter


 [Travis Goodspeed 사의] GoodFET에 기반한 GoodThopter는 신호선로에 진입하는데 Microchip사의 MCP2515, CAN to SPI 제어기를 사용한다. 이 오픈소스 하드웨어 도구는 여러분이 Python 스크립트를 이용해서 메세지를 주고 받을 수 있도록 해준다.

CAN Bus Triple


 CAN Bus Triple 장치는 세 개의 CAN 신호선로에 접근할 수 있게 해주고, Arduino와 유사한 환경에서 프로그램되어 질 수 있다. 이 오픈 소스 코드는 여러분이 2세대 Mazda 3시리즈와 작업할 수 이쎄 해준다. 불행하게도 하드웨어는 오픈소스인 것으로 보여지지 않는다.

Saleae Logic


 오픈소스는 아니지만, Saleae Logic은 CAN 신호선로를 들여다보기에 매우 간편하고 저렴한 도구이다. 이것은 CAN 트래픽을 표현하고 해석하고, 갈무리할 수 있다. 이것은 여러분이 자신의 하드웨어를 만들고자 할때 대단히 유용한다.

DIY

부품들

 여러분들이 CAN을 위한 자신만의 하드웨어를 고안하고자 한다면, 두 가지가 필요하다: 하나는 CAN 제어기이고, 하나는 CAN 송수신기이다.

 CAN 제어기는 CAN 메세지를 해석하고 생성한다. Atmel사의 Atmega32M1, Freescale사의 S08D, 그리고 TI사의 Tiva C Series 같은 내장형 CAN 제어기를 갖는 마이크로컨트롤러가 시장에 많이 있다. 내장형 CAN 제어기를 사용할때 여러분은 외장형 오실레이터를 사용해야한다. 내장된 오실레이터는 고속 CAN에 적용하기에 충분히 정확하지 않다. 만약 여러분이 기존의 마이크로컨트롤러에 CAN을 추가하고자 한다면, MCP2515은 추가해야할 사항이다. 이것은 SPI로 통신하는 독립형 CAN 제어기이다.

 송수신기는 제어기에서 신호선로로 혹은 신호선로에서 송수신기로 이동하는 신호를 변환한다. 고속과 저속의 CAN 네트워크를 위해 서로 다른 송수신기가 필요하다. NXP사의 TJA1050은 고속 신호선로에서 동작하고, ONsemi사의 NCV7356은 저속의 단일 신호선로에서 동작한다. 

개발보드들

 CAN 제어기를 갖고 있는 마이크로컨트롤러를 가지고 있는 수많은 개발보드가 세상에 존재한다. Arduino Due의 SAM3 프로세서는 제어기를 가지고 있지만, 보드에 송수신기가 없다. 여러분은 실제로 시도해 보기 위해서 CAN 신호선로용 추가 보드와 Due CAN Library를 선택할 수 있다. 

 ChipKIT사의 Max32는 Due와 유사하다. 이것은 두 개의 CAN 제어기를 가지고 있지만, 여러분이 신호선로에 실제로 접근하기 위해서 외장 송수신기를 제공할 필요가 있다. 다행히도, 이것을 위한 추가 보드가 존재한다. 이 ChipKIT은 공식적으로 Ford사의 OpenXC Platform에 의해서 지원되기 때문에 여러분은 그 펌웨어를 갈무리 할 수 있다. 

 이것이 CAN 해킹하기에 대한 우리 논의의 결론이다. 여러분들이 이제는 희망적으로 이 통신규약을 가지고 실험하고 앞으로 나아갈 준비가 되었다. 만약 질문이 있다면 주제란의 "CAN Hacking"에 있는 우리의 팁 라인에 해당하는 곳에 질문들을 보내주기 바란다. 그리고 우리는 몇몇의 질문을 들여다 볼 것이다. 여러분이 이 연재물을 좋아하고 다음 번을 위한 주제를 제안하기 원한다면 우리는 그것을 듣는 것 또한 좋아한다.

[번역] CAN 통신 해킹하기 : 통신규약 (Protocols)

[출처 : http://hackaday.com/2013/10/29/can-hacking-protocols/]


 우리는 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을 사용하기 위해서 어떤 하드웨어가 필요한지 살펴 볼 것이다.

[번역] CAN 통신 해킹하기 : 차량 내 네트워크

[출처 : http://hackaday.com/2013/10/22/can-hacking-the-in-vehicle-network/]

 지난 시간에 우리는 차량 내 네트워크가 어떻게 CAN 통신 위에서 작동하는지에 대해서 논의 하였다. 이제는 그 통신 규약과 어떻게 자동차 산업에서 사용되는지에 대해서 살펴볼 것이다.

신호선로(The Bus)

 하드웨어적인 측면에서 두 가지 종류의 CAN이 존재한다: 고속 통신이 가능한 상호 반전 선로 방식(differential) 그리고 단일 선로 방식. 상호 반전 선로는 두 개의 신호선을 사용하고 1Mbps까지의 속도로 동작 가능하다. 단일 선로는 한개의 신호선위에서 동작하고 낮은 속도이지만, 저렴하게 구현할 수 있다. 상호 반전 선로 방식은 엔진 제어 같은 좀 중요한 분야에서 사용되고, 단일 선로 방식은 HVAC나 유리창 제어 같은 덜 중요한 분야에 사용된다.

 많은 제어기들은 다중-master 설정에서 동일 신호선로에 연결할 수 있다. 모든 메세지들은 신호선로를 통해 모든 제어기에 전달 된다. 

매우 단순화된 차량내 네트워크

CAN 메세지의 구조

  소프트웨어적인 관점에서 CAN 메세지는 3개의 부분으로 구성된다: 구분자(ID), 데이터 길이 코드, 그리고 8byte까지의 데이터.

 구분자(ID)는 메세지가 무엇을 의미하는지 누가 보내는 것이지를 지정하는데 사용된다. 보통은 표준 ID들은 11bit이지만, 29bit의 확장된 형태의 ID도 있다. ID는 또한 우선 순위도 정의한다. ID 값의 낮고 높음이 메세지의 우선순위가 된다.

 데이터이 길이 코드(DLC)는 4bit이고 메세지에 얼마나 많은 byte가 있게 될 것이지를 지정한다. 어떤 분야에서 8값을 갖는 DLC가 항상 사용되고 사용되지 않는 byte들은 0값으로 채워지곤한다. 

 마지막으로 8byte의 데이터는 실제적으로 정보를 포함한다. 정보의 의미는 메세지의 ID와 DLC에서 지정되는 길이로부터 추정되어 진다. 

의미 해석과 데이터베이스 (Decoding & Databases)

 8byte의 데이터를 이해하기 위해서 제어기는 데이터를 엔진 RPM, 기름 수위, 혹은 브레이크의 위치 같은 신호로 해석한다. 각각의 신호는 8byte 이외에 정정을 위한 bit를 선택하는데 사용되어 지는 시작 bit와 마지막 bit를 갖는다. 아무런 정보가 없는 신호가 신호선로에 보내지면, 대신 모든 제어기들은 앞서 보내진 신호와 메세지의 형태에 동의하게 된다. 아래는 신호 테이블과 샘플 메세지의 도표화된 형태를 보여주고 있다.
메세지를 형성하는 CAN 신호들의 테이블

단순한 CAN 메세지의 형태

 신호들과 메세지에 동의하는 제어기를 프로그램하는데 도움이 되기 위해서 CAN 데이터베이스가 사용된다. 이 데이터베이스는 모든 메세지와 신호의 정의들을 포함하고 있다. 가장 많이 사용되는 형식은 Vector사에 의해서 제작된 사유화된 형태이지만 ASCII 코드에 기반한 DBC이다. DBC 변경도구인 CANDB++는 공짜(as in beer ?)이다. 데이터베이스들은 메세지를 해석할 수 있는 코드를 자동 생성하는데 사용된다.

 수중에 데이터베이스 파일을 넣게 되면 여러분들은 CAN 신호선을 쉽게 엿볼 수 있고 모든 종류의 데이터를 해석 할 수 있다. 단적인 예가 우리가 작성한 해킹인 운전대의 버튼을 위한 신호 엿보기(sniffed the bus for steering wheel button presses)이다. 여러분은 또한 신호선로에 속임수 데이터를 보내서 어떤 제어기 인척 만들 수도 있다. 예를 들면, 여러분은 계기판에 거짓 엔진 RPM 정보를 보낼 수도 있다.


아니야, 이 차는 8000 RPM 까지 정말로 올라 갈 수 없어.

 정상 운행중에 발생하는 통신의 대부분은 데이터베이스를 해석하는데 할여된다. 그러나, 진단 분야를 위해서 사용되어지는 특별한 통신 규약들이 있다. 다음에 우리는 이러한 통신 규약들이 어떻게 동작 하는지를 알아 보고, 그것을 가지고 어떤 재미있는 것을 할 수 있을 것이다.



[번역] CAN 통신 해킹하기 : 소개

[출처 : http://hackaday.com/2013/10/21/can-hacking-introductions/]

October 21, 2013 by Eric Evenchick


 우리는 지금 CAN에 대한 새로운 연재물과 자동차 해킹을 소개하려 한다. 먼저, 우리는 CAN 통신을 소개하고 어떻게 자동차 안에서 네트워크가 작동하는지에 대해서 논의 할 것이다.

 1986년에 Bosch사는 Controller Area Network 통신 규약을 소개하였다. 이것은  차량 제어기 사이에 이루어지는 자동차내의 네트워크를 위해 특별히 고안되었다. CAN 통신은 차량, 산업, 그리고 로봇 분야에서 네트워크 제어기로써 일반적인 옵션이 되었다. 2008년을 시작으로 미국에서 팔리는 모든 자동차는 CAN을 사용해야 한다.

 현대의 자동차들은 특수한 작업을 다루도록 고안된 제어기 (예를 들면, 차문 제어 모듈은 잠금과 창문 제어를 담당한다.) 를 가진 분산제어시스템(distributed control systems)이다. CAN 통신은 이 제어기들이 통신 가능하도록 해준다. 또한, 외부 시스템들이 차량내 네트워크에 접속함으로써 진단 작업을 수행할 수 있도록 해준다.

 자동차 안에서 이루어지는 CAN 통신의 여러가지 예들은 다음과 같다:


  • 회전 속도가 표시되는 종합 계기판(instrument cluster)에 현재의 엔진 속도를 보내는 엔진 제어 모듈
  • 유리창을 움직이기 위해 차문 제어기에 메세지를 보내는 운전자의 차문 제어기
  • 진단 도구로 부터 보내지는 제어기를 위한 펌웨어 변경
 CAN은 보통 통신 내용이 숨겨져야 하는 곳을 제외한 약간 혹은 필요없는 보안에 사용된다. 우리는 통신 내용을 보고 해석하기 위해서 CAN to USB 변환기를 사용할 수 있다. 또한 위조된 메시지를 보내거나 진단 조치를 수행하기 위해서 이러한 도구들을 사용할 수 있다. 불행하게도, CAN을 다루는 대부분의 도구들은 비공개 되어 있다. 그리고 매우 비싸다. 진단 규약은 엄연히 표준이지만, 비공개 되어 있는  것들이다. 이것들은 International Organization for Standardization 에서 구매해야 한다.

 다음에는 우리는 CAN 통신의 frame의 구조를 들여다 보고, 어떻게 통신 내용이 버스에 복조되는지 알아 볼 것이다.

[그림은 Wikipedia로 부터 가져옴]