지게차 배터리 CAN 통합: OEM이 공급업체에 제공해야 할 사항

이 작업은 초반에 실패합니다.

지게차 OEM 업체가 배터리 공급업체에 공칭 전압, 용량, 커넥터 사진, 그리고 “CAN을 작동하게 해 달라”는 막연한 요청만 보내면, 해당 프로젝트는 이미 체계적인 엔지니어링 단계에서 벗어나 비용이 많이 드는 리버스 엔지니어링 단계로 접어들게 되며, 이때 누락된 가정 하나하나가 프로토타입 개발 지연, 펌웨어 수정, 또는 현장 고장으로 이어지게 됩니다.

왜 첨단 장비 기업들은 여전히 통신 데이터를 선택 사항으로 취급하는 것일까?

지게차 배터리의 CAN 버스 통합은 단순히 배선을 연결하는 작업이 아닙니다. 이는 배터리 관리 시스템, 차량 제어 장치, 충전기, 계기판, 구동 인버터, 텔레매틱스 장치, 그리고 경우에 따라 게이트웨이 ECU 간의 인터페이스 계약입니다.

공급업체에게는 CAN-H와 CAN-L 이상의 것이 필요합니다.

이 시스템은 각 메시지의 의미, 표시되어야 할 시점, 메시지의 소유자, 메시지가 사라졌을 때 어떤 일이 발생하는지, 그리고 어느 기기가 충전을 중지하거나 구동 장치를 비활성화할 권한을 가지고 있는지를 파악해야 합니다.

제 솔직한 견해는 간단합니다: 인터페이스 정의를 공개하지 않는 OEM은 배터리 공급업체에게 통합 성능에 대한 책임을 합리적으로 물을 수 없다.

CAN 커넥터는 통신 사양이 아닙니다

그리고 ISO 11898-1 CAN 표준 CAN 데이터 링크 계층과 물리적 코딩 규칙을 정의합니다. 특정 지게차에서 3번째 바이트가 무엇을 의미하는지, 충전 상태가 0.5% 단위를 사용하는지, 또는 메시지가 0x351 100밀리초마다 도착해야 합니다.

그 차이는 중요합니다.

공급업체는 CAN 분석기를 연결하면 즉시 트래픽을 확인할 수 있습니다. 프레임이 표시되고, 카운터가 증가하며, 가속 페달을 밟거나 충전기를 연결하면 데이터가 변경됩니다.

하지만 교통이 곧 의미는 아니다.

다음 프레임을 살펴보세요:

CAN ID: 0x351
DLC: 8
데이터: 64 0A 5E 10 00 03 7B 92
사이클: 100 ms

승인된 신호 정의가 없으면 공급업체는 다음 사항들을 알 수 없습니다:

• 0번 바이트는 충전 상태, 배터리 건전도 또는 누적 카운터 값입니다.
• 바이트 1~2는 인텔 또는 모토로라 바이트 순서를 사용합니다.
• 전류는 부호 있는 값, 부호 없는 값, 32,000을 뺀 값, 또는 0.1 A 단위로 표시됩니다.
• 바이트 5에는 접촉기 상태, 충전기 허용 여부 또는 고장 레벨이 포함됩니다.
• 6~7바이트는 CRC, 체크섬, 카운터, 온도 또는 사용되지 않는 패딩입니다.
• 이 프레임은 수면 중, 충전 중, 주행 중 또는 이 세 가지 상태 모두에서 허용됩니다.

추측에 의존하면 실험실에서는 제대로 작동하는 대시보드를 만들 수 있을지 모르지만, 양산에 적합한 배터리를 만들 수는 없습니다.

CAN 데모와 통합 제품의 차이점은 문서화입니다.

펌웨어 작업 시작 전에 OEM이 제공해야 할 사항

공급업체에 필요한 것은 체계적으로 정리된 기술 자료 한 세트입니다. 이메일 대화 스레드 열 개도 아니고, 오래된 서비스 도구의 스크린샷도 아닙니다. 그리고 신호 이름의 절반이 지정되지 않은 DBC 파일은 더더욱 아닙니다. 예약됨.

다음은 지게차 배터리 BMS 통합을 승인하기 전에 제가 요구할 최소한의 인계 사항입니다.

DBC는 중요합니다.

그러나 DBC 데이터베이스는 일반적으로 메시지와 신호를 기술할 뿐이며, 배터리 상태 기계, 접촉기 시퀀스, 사이버 보안 모델, 진단 권한 또는 통신 중단 시 차량의 대응 방식 등을 완전히 포착하는 경우는 드물기 때문에, OEM은 인터페이스 제어 문서와 승인 계획도 별도로 제출해야 합니다.

코어스파크의 OEM/ODM 배터리 엔지니어링 역량 이미 맞춤형 BMS 구성, 통신 옵션, 커넥터 설계, 충전기 매칭, 시제품 개발 및 테스트 지원을 포괄하고 있습니다. 이러한 워크플로는 OEM이 첫 번째 시제품이 실패한 후가 아니라 초기 단계에서 통제된 인터페이스 데이터를 제공할 때 비로소 효율성을 발휘합니다.

DBC 파일은 컴파일 시 사용할 수 있을 만큼 충분히 완전해야 합니다.

배터리 공급업체가 사용할 수 있는 CAN 버스 DBC 파일에는 배터리가 송수신하는 모든 신호가 명시되어야 합니다.

최소한 각 신호 항목에는 다음이 포함되어야 합니다:

• CAN 식별자 및 프레임 형식
• 송신 및 수신 노드
• DLC
• 시작 비트 및 비트 길이
• 인텔 또는 모토로라 바이트 순서
• 부호 있는 형식 또는 부호 없는 형식
• 축척 및 오프셋
• 엔지니어링 부서
• 유효한 최소값 및 최대값
• 초기값 또는 사용할 수 없는 값
• 메시지 처리 시간
• 타임아웃 임계값
• 열거된 상태 정의
• 다중화 규칙
• 롤링 카운터 논리
• CRC 또는 체크섬 알고리즘
• 적용 가능한 작동 상태
• 소프트웨어 버전

체크섬에 대한 설명은 각별히 주의해야 합니다. 단순히 “CRC-8”이라고만 적어서는 안 됩니다.

공급업체는 다항식, 초기값, 최종 XOR 값, 반사 규칙, 보호 대상 바이트 범위, 식별자 포함 규칙, 활성 카운터 위치 및 검증된 입출력 예시 하나씩을 제출해야 합니다. CRC-8/SAE-J1850과 CRC-8/AUTOSAR는 모두 8비트 연산이지만, 서로 호환되지는 않습니다.

매개변수 하나만 빠져도 며칠을 허비할 수 있습니다.

그리고 아니요, CAN 트레이스는 대체재가 아닙니다. 트레이스를 통해 동작을 확인할 수는 있지만, 예약된 모든 값, 오류 상태, 타임아웃, 스케일링 규칙, 체크섬 시드 또는 모델별 변형을 모두 파악할 수 있는 경우는 거의 없습니다.

DBC, CANopen 및 J1939는 동일한 산출물이 아닙니다

OEM은 실제 상위 계층 프로토콜을 식별해야 합니다.

독점적인 CAN 시스템의 경우 일반적으로 DBC 파일과 인터페이스 제어 문서가 필요합니다. CANopen 구현의 경우 EDS 또는 DCF 파일, 객체 사전, PDO 매핑, SDO 동작, NMT 상태, 하트비트 타이밍, 노드 ID 규칙 및 비상 메시지 정의가 필요할 수 있습니다.

그리고 CiA 418 장치 프로파일 이는 CANopen 배터리 모듈과 충전기 간의 상호 운용성을 지원하기 위해 특별히 고안된 것으로, CiA 419를 기반으로 구현된 충전기도 포함됩니다. 이는 유용한 지침이지만, 단순히 “CANopen 호환”이라고 표기한다고 해서 공급업체가 해당 지게차가 실제로 어떤 선택적 객체, 매핑, 노드 ID 또는 타이밍 규칙을 사용하는지 알 수는 없습니다.

J1939 기반 트럭에는 PGN, SPN, 소스 주소, 주소 청구 동작, 전용 PGN, 반복률, 전송 프로토콜 요구 사항 및 네트워크 관리 규칙 등 자체적인 패키지가 필요합니다.

“CAN을 사용한다”는 말은 사실상 아무런 정보도 주지 않습니다.

프로토타입은 대개 상태 기계에서 좌초된다

대부분의 통합 문제는 트럭이 정상적으로 주행하는 동안에는 발생하지 않습니다. 이러한 문제는 주행 상태가 전환되는 과정에서 발생합니다.

기동. 사전 충전. 충전기 연결. 시동 끄기 지연. 비상 정지. 저전압 차단. 통신 복구.

OEM은 각 전환을 단순히 신호 목록으로 나열하는 것이 아니라 시퀀스 형태로 문서화해야 합니다.

간단히 정리한 시작 순서는 다음과 같을 수 있습니다:

1. 키 스위치 또는 차량 제어기가 배터리 깨우기 신호를 전송합니다.
2. BMS가 부팅되고 내부 점검을 수행합니다.
3. BMS가 하트비트 및 상태 메시지 전송을 시작합니다.
4. 트럭이 작동 모드 요청을 전송합니다.
5. BMS는 전압, 온도, 절연 상태 및 접촉기의 작동 준비 상태를 확인합니다.
6. 프리차지 경로가 닫힙니다.
7. DC-링크 전압이 OEM이 정의한 임계값에 도달합니다.
8. 주 접촉기가 닫힙니다.
9. BMS가 “주행 준비 완료”를 확인합니다.”
10. 이 트럭은 트랙션 시스템을 작동시킵니다.

자, 이제 불편한 질문을 던져 보세요.

BMS의 자가 진단이 완료되기 전에 차량 요청이 도착하면 어떻게 되나요? 프리차지(precharge)는 얼마나 오래 지속될 수 있나요? BMS는 콘택터를 닫기 전에 유효한 프레임 3개를 수신해야 하나요? 프리차지가 완료된 것으로 간주되는 DC-링크 비율은 85%, 90%, 아니면 95% 중 어느 것입니까? 트럭이 주행 중일 때 차량 하트비트가 500밀리초 동안 사라지면 어떻게 됩니까?

해답은 배터리 공급업체의 상상력에서 나올 수 없다.

모든 상태에는 진입 조건, 종료 조건 및 실패 조건이 필요합니다.

OEM은 각 작동 상태에 대해 다음 사항을 정의해야 합니다:

• 참가 자격
• 허용되는 메시지
• 필수 감사의 말
• 최대 전환 시간
• 접점기 상태
• 충전기 상태
• 견인 허가
• 표시 동작
• 진단 가능 여부
• 종료 조건
• 타임아웃 응답
• 회복 조건

수면에도 같은 원칙이 적용됩니다.

일부 트럭은 시동 입력 신호를 즉시 차단합니다. 반면 다른 트럭들은 차량이 작동 데이터를 기록하거나, 최종 메시지를 전송하거나, 텔레매틱스 데이터 업로드를 완료할 수 있도록 배터리가 10초, 30초 또는 120초 동안 전원을 유지하기를 기대합니다.

너무 일찍 절전 모드로 전환되는 배터리는 보호 하드웨어가 완벽하게 작동하고 있음에도 불구하고 결함이 있는 것처럼 보일 수 있습니다.

충전을 위해서는 3자 계약이 필요합니다

많은 팀이 트럭과 배터리에 대해서는 논의하면서도 충전기는 부속품 정도로만 취급합니다.

그건 실수입니다.

통합형 리튬 지게차 시스템에서 충전기는 다음을 수신해야 할 수 있습니다:

• 허용 최대 충전 전압
• 허용 최대 충전 전류
• 요청된 충전 전류
• 패키지 전압
• 충전 상태
• 셀의 최고 및 최저 온도
• 충전 활성화 상태
• 접점기 상태
• 정격 하향 조정 사유
• 충전 중지 명령
• 결함 심각도
• 배터리 정보 및 소프트웨어 버전

또한 배터리에는 충전기의 출력 전압, 사용 가능한 전류, 충전기 상태, 오류 코드 및 커넥터 상태 정보가 필요할 수 있습니다.

그러면 트럭이 두 장치 위에 정차한 상태에서 주차 브레이크 상태, 키 위치, 인터록 상태, 운전자의 유무, 커넥터 감지 여부 또는 창고 운영 규칙을 바탕으로 충전이 허용되는지 여부를 판단할 수 있습니다.

누가 책임자인가요?

OEM은 이에 대해 서면으로 답변해야 합니다.

코어스파크의 지게차 배터리 솔루션 충전 구역 설계, 기회 충전, 교대 근무 기반 용량 산정, 안전 및 전환 계획을 다룹니다. 이러한 주제는 CAN 통합과 직접적으로 연관되어 있는데, 올바른 리튬 지게차 배터리 프로토콜은 단순히 디스플레이에 SOC를 표시하는 데 그치지 않고 실제 충전 전략을 지원해야 하기 때문입니다.

전압 표시는 통합 문제를 감출 수 있다

“48V 지게차”로 판매되는 트럭은 공칭 전압 51.2V의 LFP 구조 리튬 배터리 팩을 사용할 수 있습니다. 일반적인 16-시리즈 LiFePO₄ 구성은 공칭 전압이 약 3.2V인 셀을 사용하지만, 트럭 컨트롤러는 판매 라벨이 아닌 전체 작동 범위를 고려합니다.

OEM은 다음을 제공해야 합니다:

• 최소 작동 전압
• 공칭 전압
• 최대 회생 전압
• 충전기 최대 전압
• 저전압 경고 임계값
• 저전압 차단 임계값
• 과전압 대응
• DC-링크 정전용량 또는 사전 충전 요건
• 시동 온(key-on) 및 시동 오프(key-off) 상태에서 허용되는 전압

그런 다음 공급업체는 이러한 한계치를 셀 화학 특성, 셀 수, BMS 보호 임계값 및 충전기 설정과 대조하여 매핑합니다.

단어 “48V”를 맞추는 것은 공학이 아닙니다.

결함은 정의된 차량 동작을 유발해야 한다

고장 매트릭스는 각 배터리 상태를 명확한 차량 반응과 연결해야 합니다.

예를 들어:

“오류 비트를 전송한다”는 것은 오류 대응 전략이 아닙니다.

OEM은 차량이 BMS 신호를 수신한 후 어떻게 동작할지 정의해야 합니다. 공급업체는 차량이 BMS 신호를 무시할 경우 BMS가 어떻게 동작할지 정의해야 합니다.

두 번째 경우는 권한에 대한 의문을 제기하기 때문에 회의에서 종종 회피되곤 합니다. 하지만 여전히 이에 대한 답변이 필요합니다.

이는 IT상의 선호 문제가 아니라 안전 및 책임 문제입니다.

OSHA의 2024년 중상 보고서에 따르면 2015년부터 2024년까지 지게차와 관련된 중상 사고 5,186건, 또는 대략 주당 9건의 중상 연방 데이터 세트에 포함된 고용주들 중에서. 또한 이 보고서는 해당 데이터 세트가 미국 노동 인구의 일부만을 다루고 있으므로, 이를 전국적인 전체 통계로 간주해서는 안 된다고 경고하고 있다. OSHA의 2024년 중상해 보고서 읽어보기.

그 부상들 모두가 배터리나 통신 오류와 관련된 것은 아니었습니다. 그게 요점이 아닙니다.

요점은 지게차가 보행자, 선반, 하역장, 공중에 떠 있는 화물, 좁은 통로 주변에서 운행된다는 점입니다. 원인을 알 수 없는 구동력 중단, 잘못된 저 충전량(SOC) 계산, 회생 제동 제한 해제, 또는 접촉기 개방 현상은 단순히 사용자 경험이 나쁘다는 문제 그 이상입니다.

이는 안전한 운전에 지장을 줄 수 있습니다.

규정 문구 또한 직설적이다. ~에 따라 OSHA 29 CFR 1910.178(a)(4), 동력 산업용 트럭의 적재 용량이나 안전한 운행에 영향을 미치는 개조 작업의 경우, 제조사의 사전 서면 승인을 받아야 하며, 이에 따라 명판, 태그 또는 스티커도 갱신해야 합니다.

그렇기 때문에 어떤 리튬 전환 프로그램이든 다음부터 시작해야 합니다. 납산에서 리튬 지게차로 전환 체크리스트 그리고 OEM의 서면 승인 절차. CAN 통합이라고 해서 배터리 중량, 고정 방식, 수납 공간 치수, 밸러스트, 커넥터 및 정격 용량과 관련된 기계적 고려 사항이 사라지는 것은 아닙니다.

그리고 지게차 배터리 무게 및 균형 규칙 이 점이 특히 중요합니다. 기술적으로 완벽한 CAN 인터페이스라 하더라도, 트럭의 승인된 배터리 중량 범위를 벗어난 교체용 배터리 팩의 문제를 해결할 수는 없습니다.

검증 후에는 사이버 보안을 추가할 수 없습니다

연결된 배터리는 소프트웨어로 제어되는 ECU입니다.

그들을 그렇게 대하세요.

배터리는 CAN 진단, 블루투스, RS485, USB, 서비스 소프트웨어, 텔레매틱스 데이터 또는 펌웨어 업데이트 기능을 노출할 수 있습니다. 각 인터페이스에 따라 위험 모델이 달라집니다.

그리고 NHTSA 차량 사이버 보안 지침 공급업체에 명확한 사이버 보안 기준을 전달하고, 소프트웨어 구성 요소 및 버전 기록을 유지 관리하며, 제품을 테스트하고, 설계 결정을 문서화하고, 진단 접근 권한을 보호하며, 가능한 경우 안전 관련 메시지에 인증 절차를 적용하고, 네트워크 분할 또는 필터링을 사용할 것을 권장합니다. 이 문서는 도로용 차량을 대상으로 하고 있지만, 그 엔지니어링 논리는 CAN으로 연결된 산업용 장비에도 직접 적용됩니다.

이 문제를 진지하게 받아들여야 할 실질적인 선례가 있습니다.

2015년 7월, 피아트 크라이슬러는 약 140만 대의 미국 차량 연구진이 Uconnect 시스템을 통해 네트워크로 연결된 차량 제어 장치에 원격으로 접속하는 것을 시연한 이후. 로이터 통신은 연구진이 엔진, 조향 장치, 브레이크에 영향을 미치는 명령을 내릴 수 있었다고 보도했다.

지게차 배터리는 지프 체로키가 아닙니다. 하지만 CAN 네트워크에는 한 가지 우려스러운 공통점이 있습니다. 신뢰할 수 없는 인터페이스가 제대로 분할되지 않은 제어 버스에 도달하면, 사소한 통신 기능 하나만으로도 안전 관련 기능으로 침투할 수 있는 경로가 될 수 있습니다.

따라서 OEM은 다음 사항을 정의해야 합니다:

• 어떤 진단 서비스가 허용되는가
• 프로덕션 디버그 액세스가 비활성화되어 있는지 여부
• 펌웨어의 서명 및 인증 방식
• 업데이트 승인 권한은 누구에게 있습니까?
• 특정 자격 증명이 모든 팩에서 통용되는지 여부
• 소프트웨어 및 DBC 버전의 추적 방법
• 외부 장치가 트랙션 버스로 신호를 전송할 수 있는지 여부
• 게이트웨이가 허용하는 메시지 ID는 무엇인가요?
• 이벤트 로그의 저장 및 조회 방식
• 승인되지 않은 메시지가 감지되면 어떻게 되나요?

커넥터의 불투명성에 의존하는 보안은 진정한 보안이 아니다.

리버스 엔지니어링은 검증 도구여야 하며, 출발점이 되어서는 안 된다

기존 OEM 업체가 완전한 문서를 제공하지 못하는 정당한 사유가 있는 경우도 있습니다. 원래 컨트롤러 공급업체가 더 이상 존재하지 않을 수도 있습니다. DBC가 불완전할 수도 있습니다. 해당 트럭 플랫폼에는 15년 동안 문서화되지 않은 펌웨어 변경 사항이 누적되어 있을 수도 있습니다.

리버스 엔지니어링이 도움이 될 수 있습니다.

그러나 이는 OEM 협력의 값싼 대체 수단이 아니라, 일정한 한계가 있는 체계적인 엔지니어링 프로젝트로 다루어져야 한다.

제대로 된 리버스 엔지니어링 프로그램에는 다음이 필요할 수 있습니다:

• 여러 대의 동일한 트럭
• 여러 가지 배터리 SOC 수준
• 냉시동 및 온시동
• 적재 및 비적재 주행
• 회생 제동 시험
• 충전기 연결 및 분리
• 오류 주입
• 메시지 숨기기
• 재현 테스트
• 비트 상관 분석
• 하드웨어 측정값
• 서비스 도구 관련 관찰 사항
• 최종 OEM 승인 또는 자격을 갖춘 엔지니어의 승인

그렇다 하더라도, 일부 조건은 수집된 데이터에 전혀 나타나지 않을 수도 있습니다. 심각한 절연 결함, 접촉기 용착 현상, 셀 온도 센서 고장, 부트로더 복구 또는 드문 충전기 오류 등은 정상적인 관측 중에는 발생하지 않을 수 있습니다.

침묵이 증거는 아니다.

더 나은 방법은 기록된 CAN 트레이스를 활용하여 작성된 사양을 검증하는 것입니다. 트레이스와 문서의 내용이 일치하지 않을 경우, OEM은 해당 불일치를 해결하고 버전 관리가 적용된 수정된 정의서를 발행해야 합니다.

시제품이 도착하기 전에 수용 테스트에 대해 합의해야 합니다.

신뢰할 수 있는 OEM 배터리 통합 프로그램에는 서명된 승인 매트릭스가 필요합니다.

시험은 단순히 “트럭 시동 및 주행” 이상의 내용을 포함해야 합니다.”

통신 테스트

확인:

• 올바른 비트레이트 및 프레임 형식
• 최대 버스 부하 시 메시지 전송 타이밍
• 스타트업 지연
• 타임아웃 감지
• 카운터 및 체크섬 처리
• 버스 오프 복구
• 게이트웨이 라우팅
• 수면 및 기상 행동
• 진단 통신
• 소프트웨어 및 프로토콜 버전 정보 제공

작동 상태 테스트

테스트:

• 키를 켤 때 시작
• 반복적인 키 입력
• 프리차지 성공 및 실패
• 구동 활성화
• 주차 및 시동 끄기
• 비상 정지 작동
• 시동 키 온/오프 상태에서의 충전기 연결
• 충전 완료
• 낮은 SOC 상태에서의 출력 저하
• 재생 전류 제한
• 주차 중 통신 중단
• 이동 중 통신 중단

오류 주입 테스트

연결 해제 또는 시뮬레이션:

• 팩 전압 센서
• 전지 전압 입력
• 온도 센서
• 전류 센서
• 접촉기 피드백
• 인터록
• 충전기 CAN
• 차량 CAN
• 깨우기 신호
• 보조 전원

그런 다음 배터리, 트럭, 충전기 및 디스플레이가 모두 동일한 고장 매트릭스에 따라 정상적으로 반응하는지 확인하십시오.

공급업체에게 최종 차량 시험 단계에서 합격 기준을 파악하도록 요구해서는 안 됩니다. 이는 ‘깜짝 조달’에 해당합니다.

코어스파크의 LiFePO₄ 배터리 프로젝트 사례 연구 및 검증 과정 대량 생산에 앞서 전압, 용량, 팩 치수, BMS 구성, 충전 방식 및 커넥터 사양 등을 포함한 샘플 검토를 철저히 수행해야 합니다. CAN이 통합된 지게차 프로젝트의 경우, 생산용 펌웨어가 확정되기 전에 동일한 검증 단계에서 프로토콜 적합성 및 차량 수준의 오류 테스트를 포함해야 합니다.

OEM 업체들이 비밀유지계약(NDA)에 따라 보호할 수 있는 사항

OEM 업체들은 배터리와는 무관한 독점 신호가 포함되어 있기 때문에, 전체 CAN 데이터베이스를 공개하는 것을 종종 꺼립니다.

그런 우려는 타당합니다. 하지만 일반적인 대응 방식은 그렇지 않습니다.

OEM은 모든 조향, 유압, 구동 또는 텔레매틱스 신호를 공개할 필요는 없습니다. 다만 배터리 공급업체가 할당된 인터페이스를 안전하게 구현하고 검증할 수 있도록 충분한 정보를 제공해야 합니다.

실용적인 모델은 세 가지가 있습니다:

제한된 DBC

OEM은 배터리, 충전기, 게이트웨이 및 필수 진단 메시지가 포함된 필터링된 데이터베이스를 제공합니다. 관련 없는 신호는 제거되거나 이름이 변경됩니다.

인터페이스 제어 문서

OEM은 배터리에 필요한 신호, 순서, 타이밍, 오류 및 진단 서비스만을 정의한 관리 문서를 제공합니다.

OEM 소유의 게이트웨이

OEM은 게이트웨이 뒤에 전용 차량 프로토콜을 배치하고, 배터리 공급업체에 안정적이고 문서화된 인터페이스를 제공합니다. 게이트웨이의 타임아웃 및 오류 처리 방식이 완전히 명시되어 있다면, 이는 대개 가장 명확한 장기적 분리를 가능하게 합니다.

비공개 계약(NDA)은 기밀 정보를 보호할 수 있습니다.

이는 기술 정보를 대체할 수 없습니다.

프로젝트를 중단해야 할 위험 신호

OEM 업체가 다음 중 어느 하나라도 언급할 경우, 저는 엔지니어링 작업을 일시 중단할 것입니다:

• “원래 배터리를 그대로 복사하기만 하면 됩니다.”
• “CAN 프로토콜은 표준입니다.”
• “DBC를 공유해 드릴 수는 없지만, 스니핑은 하실 수 있습니다.”
• “기존 팩과 동일한 SOC 메시지를 사용하십시오.”
• “충전기가 알아서 처리할 거예요.”
• “상태 기계는 없습니다.”
• “트럭이 운행된 후에도 오류 처리 기능을 추가할 수 있습니다.”
• “모든 48V 모델은 동일한 소프트웨어를 사용합니다.”
• “테스트를 마친 후에 승인 여부를 결정하겠습니다.”
• “예전 배터리 공급업체는 이런 걸 요구한 적이 없었어요.”

마지막 진술은 특히 위험합니다. 이는 이전 공급업체가 더 완벽한 문서를 받았거나, 문서화되지 않은 임시 해결책을 적용했거나, 공식적으로 평가된 적이 없는 통합 위험을 감수했을 가능성을 시사할 수 있습니다.

과거의 침묵이 인터페이스가 훌륭하다는 증거는 아니다.

자주 묻는 질문

지게차 배터리 CAN 버스 통합이란 무엇인가요?

지게차 배터리의 CAN 버스 통합이란, 배터리 관리 시스템, 트럭 컨트롤러, 충전기, 디스플레이 및 진단 도구가 정의된 메시지를 주고받고, 동일한 상태 전환 기계를 따르며, 한계치, 오류, 깨우기 명령, 충전 요청 및 통신 단절 상황에 안전하게 대응하도록 하는 공학적 과정을 말합니다.

이 작업에는 물리 계층 구성, 신호 매핑, 메시지 타이밍, 접촉기 로직, 충전 제어, 진단, 소프트웨어 관리 및 차량 수준 검증 등이 포함됩니다. 정상 작동과 오류 발생 시의 동작이 모두 문서화된 승인 기준을 충족해야만 이 작업이 완료된 것으로 간주됩니다.

CAN 버스 DBC 파일이란 무엇인가요?

CAN 버스 DBC 파일은 공급업체가 구현해야 하는 모든 CAN 프레임과 신호를 정의하는 기계 판독 가능 데이터베이스로, 여기에는 메시지 식별자, 바이트 위치, 비트 길이, 바이트 순서, 스케일링, 오프셋, 단위, 전송 속도, 다중화 규칙, 유효 범위, 그리고 경우에 따라 값 테이블이나 체크섬 필드 등이 포함됩니다.

DBC는 인터페이스의 일부에 불과합니다. 상태 전환, 충전기 연동, 오류 대응, 타임아웃 동작, 진단, 사이버 보안 제어 및 인수 테스트는 별도의 사양서에서 정의해야 합니다.

OEM은 지게차 배터리 공급업체에 무엇을 제공해야 할까요?

OEM은 배터리 공급업체에 해당 지게차 모델에 대한 완전한 인터페이스 계약서를 제공해야 합니다. 여기에는 전기 핀 배열, 물리 계층 설정, DBC 또는 이에 상응하는 신호 맵, 네트워크 소유권, 메시지 타이밍, 상태 전환, 충전 핸드셰이크, 오류 대응, 진단 접근, 소프트웨어 버전 규정, 테스트 트레이스, 그리고 서면으로 작성된 수용 기준이 포함되어야 합니다.

또한 OEM은 해당되는 모든 모델, 컨트롤러 버전, 충전기 버전 및 지역별 변형을 파악해야 합니다. 특정 48V 트럭 한 대에서 검증된 프로토콜을 제품군 전체에 무작정 적용해서는 안 됩니다.

리튬 지게차 배터리는 CAN 통신 없이도 작동할 수 있나요?

지게차 배터리는 지게차와 충전기가 BMS가 접촉기와 보호 기능을 독립적으로 제어하는 독립형 배터리를 지원하도록 설계된 경우에만 CAN 통신 없이 작동할 수 있습니다. 많은 최신 지게차의 경우, CAN 메시지가 누락되면 인터록, 림프 모드, 충전 거부, 경고 코드 발생 또는 구동력 완전 상실 등의 현상이 발생합니다.

독립형 배터리라 하더라도 차량의 전압 범위, 전류 요구량, 커넥터, 배터리 중량 요건, 충전 시스템 및 안전 제어 장치와 호환되어야 합니다. “CAN 불필요”라고 해서 “바로 교체 가능한 호환성”을 의미하는 것은 아닙니다.”

지게차 배터리 CAN 통합을 위한 모범 사례는 무엇인가요?

지게차 배터리 CAN 통합을 위한 모범 사례는, 버전 관리가 이루어지는 하나의 인터페이스 사양을 확정하고, 실제 CAN 트레이스 및 하드웨어-인-더-루프(HIL) 또는 지게차 테스트 벤치를 통해 이를 검증하며, 타임아웃 및 센서 오류를 인위적으로 발생시켜 충전기의 동작을 확인한 후, 공급업체가 양산용 펌웨어를 출시하기 전에 승인 매트릭스에 서명하는 것입니다.

또한 OEM 및 공급업체는 프로토콜 버전의 추적성을 유지하고, 모든 펌웨어 변경 사항을 검토하며, 진단 접근 권한을 관리하고, 승인된 각 지게차·배터리·충전기 조합에 대한 테스트 증거를 보관해야 합니다.

UN 38.3 관련 문서는 CAN 통합의 일부인가요?

UN 38.3 문서는 CAN 프로토콜의 요구 사항이 아닙니다. 이는 리튬 전지 또는 배터리 설계가 운송에 투입되기 전에 ‘UN 시험 및 기준 매뉴얼’ 제3부 제38.3절에 명시된 해당 시험을 통과했음을 입증하는 운송 적합성 증거입니다.

그리고 미국 파이프라인 및 위험물 안전청 해당 규정에 따라 제조업체와 후속 유통업체는 리튬 배터리 시험 요약서를 공개해야 한다고 명시하고 있습니다. 프로토콜 검증 결과와 운송 서류는 모두 프로젝트 공개 자료에 포함되어야 하지만, 두 문서의 용도는 서로 다릅니다.

견적 요청 전에 인터페이스 패키지를 보내주십시오

전압, 암페어시(Ah) 및 커넥터 사진만 가지고는 지게차 배터리 CAN 버스 통합 프로젝트를 시작해서는 안 됩니다.

네트워크 아키텍처, DBC 또는 EDS 파일, 메시지 소유권 매트릭스, 작동 상태 머신, 충전 핸드셰이크, 오류 대응 테이블, 핀 배열, 참조 CAN 트레이스, 소프트웨어 버전 목록 및 수용 기준을 준비하십시오. 관련된 정확한 트럭 모델과 충전기를 파악하십시오.

그런 다음 해당 패키지를 엔지니어링 검토를 위해 보내주십시오.

자격을 갖춘 배터리 공급업체는 비밀유지계약(NDA)에 따라 독점 파일을 보호하고, 누락된 정보를 지적하며, BMS 및 통신 아키텍처를 제안하고, 통제된 환경에서 시제품을 제작하며, 실제 차량을 대상으로 결과를 검증할 수 있습니다.

하지만 공급업체는 OEM이 공개한 적이 없는 정보를 만들어낼 수는 없다.

CoreSpark Battery에 귀사의 지게차 모델, 배터리 전압, 용량, CAN 프로토콜, 충전기 사양, 커넥터 도면 및 목표 수량을 알려주시면, 또 다른 리버스 엔지니어링이라는 모험이 아닌, 문서화된 OEM 통합 검토를 시작할 수 있습니다.