CAN 버스 차량용 컴퓨터는 단순히 한 쌍의 CAN 단자를 노출하는 것 이상의 기능을 수행합니다. 적절한 메시지를 적시에 수신하고, 선택된 데이터를 애플리케이션에 전달하며, 직렬 장치 및 무선 링크와 공존하고, 차량의 전기적 및 환경적 조건 전반에 걸쳐 안정적으로 작동해야 합니다.
OEM 업체에게 있어 어려운 부분은 디스플레이 크기를 선택한 후부터 시작됩니다. 통합 팀은 버스 아키텍처, 메시지 정의, 운영 체제 인터페이스, 서비스 동작 및 인수 테스트에 대해 합의해야 합니다. 이 가이드는 CAN 버스 터미널을 반복 가능한 생산 서브시스템으로 전환하기 위한 실용적인 체크리스트를 제공합니다.
PDS 통합 예시. 배선, 프로토콜 및 소프트웨어 동작은 대상 차량에서 검증되어야 합니다.
하드웨어를 선택하기 전에 CAN 버스 차량용 컴퓨터 아키텍처를 정의하십시오.
CAN 네트워크는 공유 차동 버스입니다. 여러 전자 제어 장치(ECU)가 프레임을 교환하고, 각 수신 노드는 프레임의 관련성을 판단합니다. 물리 계층, 비트 전송률, 종단 처리, 커넥터 정책 및 메시지 프로토콜은 차량 설계에 맞춰야 합니다. CSS Electronics는 공통 용어가 필요한 팀을 위해 CAN 버스에 대한 유용한 입문 자료를 제공합니다.
OEM이 가장 먼저 결정해야 할 사항은 CAN 버스 차량용 컴퓨터가 수행할 수 있는 작업의 범위를 정하는 것입니다. 데이터 모니터링만 허용하거나, 제한된 작업만 요청하거나, 게이트웨이 역할을 하거나, 사설 네트워크에 참여할 수 있도록 허용할 수 있습니다. 이러한 역할을 인터페이스 제어 문서에 명시해야 합니다. 모니터링 터미널과 명령 실행 기능을 갖춘 컨트롤러는 서로 다른 테스트 및 사이버 보안 고려 사항이 필요합니다.
또한 터미널에 연결된 모든 버스를 식별해야 합니다. 상용 차량은 종종 파워트레인, 차체, 작업 장치, 진단 및 개인 CAN 네트워크를 분리합니다. 이러한 네트워크를 격리 또는 게이트웨이 전략 없이 혼합하면 원치 않는 트래픽, 웨이크업 동작 또는 오류 전파가 발생할 수 있습니다.
| 통합 계층 | 디자인 결정 | 증거 필요 |
|---|---|---|
| 물리적 | 비트 전송률, 토폴로지, 종단 처리, 케이블, 커넥터 및 절연 | 배선 도면, 오실로스코프 또는 분석기 측정값 및 EMC 계획 |
| 규약 | Raw CAN, J1939, CANopen, ISO-TP, UDS 또는 독자적인 포맷 | 메시지 데이터베이스, 식별자, 타이밍 및 상태 다이어그램 |
| 운영 체제 | 드라이버, API, 권한, 프로세스 우선순위 및 복구 | SDK 문서, 샘플 코드 및 오류 주입 결과 |
| 애플리케이션 | 디코딩, 필터링, 로깅, 표시 및 비즈니스 로직 | 차량 데이터 기록을 활용한 엔드투엔드 테스트 사례 |
| 생명주기 | 버전 관리, 업데이트, 진단 및 현장 서비스 | 구성 기준선, 릴리스 프로세스 및 복구 절차 |
CAN 버스 RS232 RS485 차량 컴퓨터 점검 목록을 작성하십시오.
OEM 프로젝트에서는 CAN과 기존 직렬 장비를 함께 사용하는 경우가 많습니다. CAN 버스 RS232 RS485 차량용 컴퓨터 체크리스트에는 각 인터페이스를 개별적으로 문서화한 후 전체 데이터 경로를 테스트해야 합니다.
CAN 버스
독립 채널 수, CAN FD 지원 여부, 비트 전송률, 종료 방식, 절연, 웨이크업 동작 및 커넥터 핀 배열을 확인하십시오. 단말기가 특정 프레임만 수신해야 하는지 또는 메시지도 전송해야 하는지 확인하십시오. 전체 차량 하네스를 사용하여 버스 부하 및 최악의 경우 지연 시간을 측정하십시오.
RS232 및 RS485
RS232를 사용하는 차량용 컴퓨터의 경우 전압 레벨, 전송 속도, 흐름 제어, 커넥터, 케이블 길이 및 프로토콜을 명시해야 합니다. RS232는 일반적으로 지점 간(point-to-point) 방식입니다. RS485는 다중 노드에서 반이중(half-duplex) 또는 전이중(full-duplex) 동작을 사용할 수 있으므로 종단 및 바이어스 요구 사항을 정의해야 합니다. 동일한 전송 속도 설정이 프로토콜 호환성을 보장한다고 가정해서는 안 됩니다.
차량 설치 전에 루프백 또는 장치 수준 테스트를 요청하십시오. 그런 다음 CAN, 두 개의 직렬 채널, USB 및 무선 연결을 통해 동시 트래픽을 테스트하십시오. 공유 프로세서 부하 및 인터럽트 처리는 단일 인터페이스 데모에서는 나타나지 않는 문제를 드러낼 수 있습니다.
PDS OEM 통합 예시입니다. 인터페이스 동작은 제시된 제품 구성에 따라 확인해야 합니다.
메시지 데이터베이스 및 데이터 모델을 제어합니다.
애플리케이션은 코드베이스 전체에서 원시 16진수 프레임을 디코딩해서는 안 됩니다. 메시지 데이터베이스 또는 DBC를 정의하고, 물리적 값과 단위를 매핑하고, 테스트를 거친 디코딩 계층을 생성하십시오. 업데이트 속도, 타임아웃 동작, 잘못된 값 처리, 바이트 순서, 스케일링 및 신호 범위를 포함해야 합니다.
터미널 애플리케이션뿐 아니라 차량 소프트웨어와도 데이터베이스 버전을 관리해야 합니다. ECU가 메시지를 추가하거나 신호를 변경하는 경우, 통합 팀은 어떤 터미널, 클라우드 모델 및 테스트 케이스가 영향을 받는지 파악해야 합니다. 차량 없이도 변경 사항을 재현할 수 있도록 대표적인 CAN 로그를 저장해야 합니다.
프로젝트에서 SAE J1939를 사용하는 경우 소스 주소, 파라미터 그룹, 요청 동작 및 진단 처리를 문서화하십시오. CANopen 또는 독자적인 프로토콜을 사용하는 경우, 이에 상응하는 상태 머신과 오류 정의를 제공하십시오.
운영 체제와 CAN API를 선택하세요.
리눅스 운영체제를 사용하는 CAN 버스 차량용 컴퓨터는 커널의 SocketCAN 서브시스템을 통해 인터페이스를 노출할 수 있습니다. 소프트웨어 개발팀은 표준 소켓 연산, 필터 및 네트워크 도구를 활용할 수 있습니다. 커널 버전, CAN 드라이버, 수신 버퍼 구성 및 권한은 개발 보드뿐 아니라 배포 이미지에서도 확인해야 합니다.
Android 환경에서 공급업체는 Java, Kotlin, 네이티브 또는 JNI API를 제공할 수 있습니다. 애플리케이션이 프레임을 수신하는 방법, 전송 액세스 제어 방식, 서비스 재시작 시 발생하는 상황에 대해 문의하십시오. 통합 계획에는 중지된 프로세스, 연결이 끊긴 인터페이스 또는 오류 발생 시 버스 상태가 복구될 수 있는 감시 또는 상태 점검 기능이 포함되어야 합니다.
OpenHarmony 프로젝트는 그에 걸맞게 구체적인 인터페이스 정의를 받아야 합니다. CAN을 지원한다는 일반적인 설명만으로는 충분하지 않습니다. OEM은 실제 API 인터페이스, 샘플 프로젝트, 권한, 수명 주기 동작 및 디버깅 기능을 필요로 합니다.
차량 인터페이스 성능 저하 없이 GNSS 및 4G LTE 기능을 추가합니다.
CAN 버스를 사용하는 GNSS 차량 단말기는 위치, 움직임 및 차량 상태 데이터를 결합할 수 있습니다. 필요한 정확도, 업데이트 속도, 좌표 형식, 시간 소스 및 보정 서비스를 정의하십시오. 실제 차량 지붕, 운전석, 화물칸 및 주변 무선 장비를 사용하여 안테나 배치를 테스트하십시오. GNSS 손실과 CAN 타임아웃을 독립적인 상태로 유지하여 한 소스가 사용 불가능하더라도 다른 소스가 무효화되지 않도록 하십시오.
4G LTE 차량 탑재 컴퓨터는 이러한 데이터 스트림을 차량 관리 플랫폼으로 확장하지만, 업링크가 항상 사용 가능한 것으로 간주해서는 안 됩니다. 지원되는 주파수 대역, 통신 사업자 프로필, 로밍 동작, 안테나 절연, 데이터 제한 및 재연결 시간을 명시해야 합니다. 중요한 기록은 로컬 버퍼링을 사용하고, 어떤 필드를 즉시, 주기적으로 또는 이벤트 발생 후에 전송할지 정의하십시오.
데이터 소유권과 접근 권한을 명확히 정의해야 합니다. 차량 소유자는 위치, 진단 정보, 운전자 정보, 운행 데이터 등에 대한 제어 권한이 필요할 수 있습니다. 단말기와 클라우드 플랫폼은 명확한 인증, 권한 부여, 데이터 보존 및 원격 제어 정책을 수립해야 합니다.
전원, 신호 및 소프트웨어 경계를 보호하십시오.
차량 전원에는 시동 시 전력 저하, 부하 분산, 점프 스타트 및 액세서리 전환이 포함됩니다. CAN 버스 차량 컴퓨터는 실제 차량 등급에 따라 입력 범위, 과도 응답 표준, 퓨즈, 접지 및 점화 동작을 명시해야 합니다. CAN 및 직렬 포트는 외부 장비에 연결될 때 전기적 절연 또는 보호가 필요할 수도 있습니다.
OEM에서 신뢰를 정의한 후에만 CAN을 신뢰할 수 있는 인터페이스로 취급하십시오. 전송 식별자를 제한하고, 수신 길이 및 범위를 검증하고, 명령 속도를 제한하고, 애플리케이션이 관련 없는 버스 채널에 액세스하지 못하도록 방지하십시오. 보안 관련 구성 변경 사항을 기록하고 서명되거나 검증된 소프트웨어 업데이트를 지원하십시오.
케이블 하네스는 유지보수 편의성을 고려해야 합니다. 커넥터에 라벨을 부착하고, 핀 배열을 문서화하고, 사용하지 않는 포트를 보호하고, 필요한 경우 토크 값을 명시해야 합니다. 벤치 테스트에서 정상 작동하는 터미널이라도 무거운 하네스가 커넥터를 잡아당기거나 버스에 간섭을 일으키는 돌출부를 만들면 고장날 수 있습니다.
제품 출시를 위해 승인 매트릭스를 사용하세요.
| 테스트 영역 | 합격 기준 예시 |
|---|---|
| 버스 건강 | 정상 작동, 시작, 절전 모드 해제 및 종료 과정 중 의도치 않은 오류 프레임이 발생하지 않습니다. |
| 데이터 정확도 | 디코딩된 신호는 전체 작동 범위에 걸쳐 기준 측정값과 일치합니다. |
| 숨어 있음 | 프로젝트 일정 예산 내에서 핵심 데이터가 애플리케이션에 도달합니다. |
| 회복 | CAN, 시리얼, GNSS 및 셀룰러 서비스는 케이블, 전원 및 네트워크 오류 발생 후 복구됩니다. |
| 파워 사이클 | 구성 및 버퍼링된 데이터는 필수적인 시동 및 배터리 시나리오에서도 유지됩니다. |
| 업데이트 및 롤백 | 업데이트가 실패하면 장치가 정상 작동 버전으로 되돌아갈 수 있습니다. |
CAN 버스 차량용 컴퓨터는 생산 전에 승인된 버스, 지연 시간, 복구 및 업데이트 테스트 매트릭스를 통과해야 합니다. PDS는 견고한 차량용 단말기에 대한 OEM/ODM 통합 지원을 제공하며 프로젝트의 소프트웨어 계획에 맞춰 인터페이스를 조정할 수 있습니다. OEM은 차량 수준의 인터페이스 사양을 보유하고 최종 검증 계획을 승인해야 합니다.
PDS 검증 예시. 생산 개시 전에 승인 기준 및 시험 장비에 대한 합의가 이루어져야 합니다.
자주 묻는 질문
CAN 버스 차량용 컴퓨터가 차량 데이터를 수신하려면 무엇이 필요합니까?
호환 가능한 물리적 CAN 인터페이스, 올바른 비트 전송률 및 종단 처리, 관련 버스에 대한 접근 권한, 메시지 데이터베이스, 그리고 필요한 신호를 디코딩하는 소프트웨어가 필요합니다. 또한 단말기는 타임아웃, 잘못된 값, 버스 오류를 처리해야 합니다.
차량용 컴퓨터가 CAN, RS232, RS485 프로토콜을 동시에 사용할 수 있나요?
많은 견고한 차량용 컴퓨터는 이러한 인터페이스를 동시에 지원할 수 있지만, 정확한 채널 수와 절연 수준은 모델에 따라 다릅니다. 필요한 모든 트래픽을 동시에 테스트하고 운영 체제가 각 인터페이스를 안정적으로 노출하는지 확인하십시오.
J1939는 CAN 버스와 같은 것인가요?
J1939는 CAN 네트워크, 특히 대형 차량에서 사용되는 상위 계층 프로토콜입니다. 단말기는 물리적으로 CAN을 지원할 수 있지만, 프로젝트에서 요구하는 특정 J1939 메시지나 진단 동작을 지원하지 않을 수도 있습니다.
CAN 데이터는 단말기에서 처리해야 할까요, 아니면 클라우드에서 처리해야 할까요?
시간에 민감한 필터링, 표시, 알림 및 버퍼링에는 터미널을 사용하십시오. 네트워크 가용성과 데이터 정책이 허용하는 경우 요약 또는 이벤트 기반 기록을 클라우드로 전송하십시오. 데이터 분할은 지연 시간, 개인 정보 보호, 비용 및 오프라인 요구 사항을 고려하여 결정해야 합니다.
저희에게 연락하세요
📧이메일: [email protected]
📞전화:+86 13421822024
🌐웹사이트: www.szpds.com
부인 성명
본 문서의 정보는 참고용으로만 제공됩니다. PDS Technology Co., Ltd.는 내용의 오류, 누락 또는 특정 용도에 대한 적합성에 대해 어떠한 책임도 지지 않습니다. 제품 사양은 예고 없이 변경될 수 있습니다. 구매자는 사용 전에 모든 기술 세부 사항을 당사 팀과 확인해야 합니다.
PDS 테크놀로지 소개
PDS Technology는 2011년부터 농업, 건설, 광업, 택시 및 물류 산업에 고정밀 RTK GNSS 단말기 및 차량용 컴퓨터를 공급하는 선도적인 OEM/ODM 제조업체입니다.
15년 이상의 자동차 등급 연구 개발 경험을 바탕으로, 당사는 RTK 센티미터급 정밀 위치 측정, IP66 방수/방진, AI 지원 성능을 갖춘 견고한 멀티 OS(안드로이드/리눅스/오픈하모니) 기기를 제공합니다. IATF16949 인증을 획득한 당사의 공장에서는 전 세계적으로 10만 대 이상의 제품을 생산하여 중국 농업용 자동 조향 단말기 시장의 30% 이상을 점유하고 있습니다. 일본, 미국, 영국, 터키, 러시아 등 다양한 국가에 제품을 수출하고 있습니다.
