KR20220054369A - Can 버스 데이터를 압축하는 방법 - Google Patents

Can 버스 데이터를 압축하는 방법 Download PDF

Info

Publication number
KR20220054369A
KR20220054369A KR1020227010331A KR20227010331A KR20220054369A KR 20220054369 A KR20220054369 A KR 20220054369A KR 1020227010331 A KR1020227010331 A KR 1020227010331A KR 20227010331 A KR20227010331 A KR 20227010331A KR 20220054369 A KR20220054369 A KR 20220054369A
Authority
KR
South Korea
Prior art keywords
message
series
messages
compression
command
Prior art date
Application number
KR1020227010331A
Other languages
English (en)
Inventor
에얄 카미르
알렉산더 포크
리란 츠비켈
Original Assignee
에니그마토스 리미티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 에니그마토스 리미티드 filed Critical 에니그마토스 리미티드
Publication of KR20220054369A publication Critical patent/KR20220054369A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40071—Packet processing; Packet format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3068—Precoding preceding compression, e.g. Burrows-Wheeler transformation
    • H03M7/3071—Prediction
    • H03M7/3073—Time
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3068—Precoding preceding compression, e.g. Burrows-Wheeler transformation
    • H03M7/3077—Sorting
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/70—Type of the data to be coded, other than image and sound
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Traffic Control Systems (AREA)

Abstract

CAN 버스 메시지의 흐름을 압축하는 방법으로서, (A) 트레이닝 단계 동안: (a) 적어도 하나의 시리즈 타입 패턴을 결정하고; (b) 패턴 각각에 대해 압축된 시리즈 타입 커맨드를 정의하고 - 각 커맨드는 (b.1) 제1 메시지의 타임스탬프; (b.2) 메시지 ID; (b.3) 패턴 타입; (b.4) 메시지 내의 필드의 표시; (b.5) 제1 메시지에서의 파라미터 값; (b.6) 메시지 간의 기간; 및 (b.7) 메시지의 수;의 파라미터를 포함함 - ; (B) 압축 단계 동안: (c) CAN 버스 메시지의 기록을 동일한 메시지 ID의 그룹들로 나누고; (d) 각 그룹 내에서, 동일한 패턴의 메시지를 검색하고; (e) 각 시리즈에 대해서, 적어도 몇 개의 파라미터에 대한 값으로 정의된 형식으로 압축 커맨드를 형성하고; 그리고 (C) 압축 해제 단계 동안: (f) 시리즈 타입 압축 커맨드를 이용하여 시리즈의 메시지의 콘텐츠를 재구성하는 것을 포함한다.

Description

CAN 버스 데이터를 압축하는 방법
본 발명은 일반적으로 CAN 버스와 같은 차량의 컴퓨터화된 시스템을 모니터링, 유지 관리, 및 보호하기 위한 방법 및 시스템에 관한 것이다. 보다 구체적으로, 본 발명은 CAN 버스 데이터를 외부 유닛으로 효율적으로 전달하기 위한 시스템 및 방법에 관한 것이다.
차량은 옮겨 다니는 컴퓨터의 복잡한 네트워크이다 - 오늘 날의 차량은 수십 개(대부분의 경우 50개 이상)의 ECU(Electronic Control Unit) 및 1억개 이상의 코드 라인을 가진다. 오늘 날의 자동차는 서로간에, 그리고 도로 표지판, 신호등, 제조업체 서버 등과 서로 통신하도록 이미 설계되어 있다. 이러한 모든 운용이 가능하려면, 신뢰할 수 있는 차량의 컴퓨터화된 시스템에 대한 필요성이 매우 중요하다.
CAN(Controller Area Network) 버스는 호스트 컴퓨터가 없는 애플리케이션에서 마이크로컨트롤러와 디바이스가 서로 통신할 수 있도록 설계된 가장 일반적이고 강건한 차량 버스 표준이다. 차량에 탑재되어 이용되는 다른 프로토콜로는, 예를 들면, Can-FD, Flexray, 및 자동차 이더넷 표준(Automotive Ethernet Standards)이 있다. CAN 버스는 자동차 내의 다중 전기 배선을 위해 설계된 메시지 기반 프로토콜이다. CAN 버스는 노드라고도 알려진 복수의 ECU(Electronic Control Unit) 간의 통신을 가능하게 한다. 통신을 위해서는 CAN 네트워크 상에 둘 이상의 노드가 요구된다. 노드의 복잡성은 단순한 I/O 디바이스부터 CAN 인터페이스와 정교한 소프트웨어가 있는 임베디드 컴퓨터에 이르기까지 다양하다. 또한 노드는 범용 컴퓨터(예로써 랩톱 또는 메인터넌스 장치)가 USB 또는 이더넷 포트를 통해 CAN 네트워크 상의 디바이스와 통신 가능하게 하는 게이트웨이일 수 있다. CAN 버스의 모든 노드는 전형적으로 2선식 연결을 통해서 버스에 연결된다. 이 배선은 120Ω(공칭) 특성 임피던스를 가진 트위스트 페어이다.
CAN 버스의 각 노드는 메시지를 송신 및 수신하도록 구성되지만 동시적이지는 않다. CAN 버스 메시지는 주로 메시지 ID, 최대 8 바이트 데이터, CRC, ACK(acknowledge) 슬롯, 및 메시지의 일부인 기타 오버헤드 슬롯으로 구성된다. 개선된 CAN FD 프로토콜은 메시지의 데이터 필드의 길이를 프레임당 최대 64 바이트까지 확장한다. 메시지는 NRZ(non-return-to-zero) 포맷을 사용하여 버스 상에 직렬로 전송되며, 모든 노드가 수신할 수 있다. CAN 네트워크로 연결되어 있는 디바이스는 전형적으로 센서, 액추에이터, 및 기타 제어 디바이스이다. 이러한 디바이스는 호스트 프로세서, CAN 컨트롤러, 또는 CAN 트랜시버(본 명세서에서는 모두 "ECU"라고 함)를 통해 버스에 연결된다.
CAN 버스의 안전성 및 무결성(integrity)을 모니터링 및 보호하고, 유지 관리를 수행하기 위해서, 일부의 안전성 및 메인터넌스 프로그램은 네트워크 상의 트래픽을 빈번히 기록하고, 트래픽 기록을 무선으로(예로써, 모바일 통신으로) 원격 제어 센터나 클라우드 엔티티로 내보내거나, 또는 하드와이어적 통신으로 로컬 메인터넌스 장치로 내보낸다. CAN 버스의 50-100개의 ECU 각각은 대략 수 ㎲에서 최대 수십 ㎲의 주기로 주기적인 전송을 발행한다(일부 예외가 아래에서 논의될 것이다). 수백 또는 수천 개의 서로 다른 메시지가 매 초당 전송된다. 대역폭이 1Mb/s인 단일의 CAN-C 네트워크 세그먼트는 하루에 대략 10MB의 데이터를 발생시킬 수 있다. 최신 차량은 이런 네트워크 세그먼트가 5-10개 포함되어, 차량당 하루에 50-100MB의 데이터를 발생시킬 수 있다. 최근 도입된 CAN FD 프로토콜은, 사용되었을 경우, 이 전송 사이즈가 몇 자릿수 더 증가한다. 오늘날 공공 클라우드 인프라 및 4G 셀룰러 기술 보급에도 불구하고, 전 차량에 대해 이러한 양의 데이터를 업로드하고 저장하는 것은 어려운 문제이다. 일부 경우에, 향후 검증을 위해서 CAN 버스 데이터의 긴 기록을 로컬적으로(즉, 차량 내에) 저장해야 할 필요성도 발생한다. 위의 모든 경우에 효율적인 압축의 필요성이 요망된다.
종래 기술은 CAN 버스 메시지의 데이터를 압축하거나 줄이기 위한 두 가지 주요 접근법을 제안했다. 구문 압축(syntactic compression) 접근법은 바이트 스트림 데이터의 저레벨 표현으로 동작하고 콘텐츠의 특정 의미와 관계없이 수행된다. 시맨틱 압축(semantic compression) 접근법은 압축되는 데이터를 해석하고 데이터를 압축하기 위해 그 특정 의미를 이용한다.
25회 국제 회의 SoftCOM(Software, Telecommunications and Computer Networks)(2017년 9월)의, Andras Gazdag 등의, "Efficient Lossless Compression of CAN Traffic Logs"에는, CAN 버스 데이터의 시맨틱 압축 접근법을 제안했다.
본 발명의 목적은 CAN 버스 기록 메시지를 포함하는 파일의 사이즈를 현저히 줄여서, 원격 제어 센터 또는 메인터넌스 장치로 파일의 효율적인 전달 및 저장을 가능하게 하는 방법을 제공하는 것이다.
본 발명은 CAN 버스 메시지의 흐름을 압축하는 방법에 관한 것으로, (A) 트레이닝 단계 동안: (a) 메시지의 트레이닝 흐름 내에서 적어도 하나의 시리즈 타입 패턴을 결정하고 - 각 시리즈 타입 패턴은 동일한 메시지 ID를 가지는 순차적인 시리즈의 CAN 버스 메시지의 데이터 필드에 나타나는 데이터 값에 걸쳐 있음(spanning) - ; (b) 패턴 각각에 대해 압축된 시리즈 타입 커맨드를 정의하고 - 각 시리즈 타입 커맨드는: (b.1) 시리즈 내 제1 메시지의 타임스탬프; (b.2) 시리즈의 메시지 ID; (b.3) 패턴 타입; (b.4) 패턴이 나타나는 메시지 내의 필드 또는 그 일부의 표시(indication); (b.5) 시리즈 내 제1 메시지에서의 파라미터 값; (b.6) 시리즈의 메시지 간의 기간; 및 (b.7) 시리즈 내 메시지의 수;의 파라미터를 포함함 - ;
(B) 압축 단계 동안:
(c) CAN 버스 메시지의 흐름의 기록을 그룹들로 나누고 - 각 그룹은 동일한 메시지 ID를 가지는 메시지와 관련됨 - ; (d) 각 그룹 내에서, 동일한 패턴의 하나 이상의 시리즈의 메시지를 검색하고 - 각 시리즈는 적어도 5개의 메시지에 걸쳐 있음 - ; (e) 검색된 시리즈의 메시지 각각에 대해서, 트레이닝 단계에서 정의된 형식으로 시리즈 타입 압축 커맨드를 형성하고 - 압축된 시리즈 타입 커맨드는 트레이닝 단계 동안 해당 커맨드에 대해 정의된 적어도 복수의 파라미터에 대한 값을 포함함 - ; 그리고
(C) 압축 해제 단계 동안:
(f) 각각의 시리즈 타입 압축 커맨드를 이용하여 각각의 시리즈의 메시지의 콘텐츠의 적어도 일부를 재구성하는 것을 포함하며, 여기서 압축 커맨드는 재구성된 메시지의 각 개체의 각각의 필드 또는 그 일부 내에 각각의 값을 채운다(populate).
일 실시예에서, 패턴 타입은 메시지의 데이터 필드 또는 그 일부 내에 나타나는 펑션(function)이다.
일 실시예에서, 펑션은 값의 패턴이 각각 연속적인 메시지의 데이터 필드 또는 그 일부 내에 나타나게 하는 카운터 또는 데이터 필드 CRC이며, 압축 해제 단계는 재구성된 시리즈의 메시지의 각각의 필드 내에 해당 값을 채운다.
일 실시예에서, 패턴 타입은 메시지의 데이터 필드 또는 그 일부 내에 나타나는 상수 값이고, 압축 해제 단계는 재구성된 시리즈의 메시지의 각각의 필드 내에 상수 값을 채운다.
일 실시예에서, 트레이닝 단계는: (a) 메시지의 데이터 필드 또는 그 일부에서 통계적으로 여러 번 반복되는 복수의 상수 값을 결정하는 스텝; (b) 가장 공통적으로 나타나는 상수를 순차적으로 인덱싱하는 스텝을 더 포함하고; 그리고 (c) 압축 단계 동안 각 상수 타입 커맨드는 상수 자체가 아니라 상수의 인덱스를 포함한다.
일 실시예에서, 이 방법은: (a) CAN 버스 메시지의 트레이닝 흐름에서 모든 ID를 순차적으로 인덱싱하는 스텝; 및 (b) 압축 단계 동안 CAN 버스에 본래 나타나는 실제 메시지 ID가 아니라, ID의 인덱스를 각 압축 커맨드 내에 포함시키는 것을 더 포함한다.
일 실시예에서, 이 방법은 각각의 시리즈 내 커맨드 간의 알려진 기간에 기초하여 예상된 타임스탬프에 상대적인 하나 이상의 딜레이 표시를 시리즈 타입 압축 커맨드 내에 포함시키는 것을 더 포함한다.
일 실시예에서, 이 방법은 개개의 재구성된 메시지의 데이터 필드 내에 하나 이상의 특정 값을 전송하기 위한 하나 이상의 압축 커맨드를 더 포함한다.
일 실시예에서, 압축 커맨드 내에 패턴을 파라미터 값으로 표시하는 것 대신에, 각 패턴에 대해 서로 다른 압축 커맨드가 할당된다.
일 실시예에서, 압축 커맨드의 압축 해제는 압축 위치로부터 압축 해제 위치로 전달되는 메타데이터를 사용한다.
일 실시예에서, 메타데이터는 메시지 ID의 인덱싱 정보, 상수의 인덱싱 정보, 및 필요에 따라, 압축 해제 측에서 커맨드의 펑션을 서로 다른 재구성된 메시지의 데이터 필드 내의 데이터 값으로 적절히 변환할 수 있게 하는 특정 펑션 동작에 대한 세부 정보(예를 들면, 데이터 필드 CRC 펑션)를 포함한다.
도 la는 종래 기술에 따른 종래의 CAN 버스의 구조를 개괄적으로 나타낸 도면이다.
도 lb는 종래 기술에 따른 CAN 버스 메시지의 구조를 개괄적으로 나타낸 도면이다.
도 2는 본 발명의 일 실시예에 따른 CAN 버스의 구조를 개괄적으로 나타낸 도면이다.
도 3은 본 발명의 일 실시예에 따른 트레이닝 절차를 개괄적으로 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른 압축 유닛의 동작 단계를 개괄적으로 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 원격 모니터링 센터에서 수행되는 압축 해제 프로세스를 설명한 도면이다.
아래의 개시된 발명의 설명은 도면에 예시되거나 및/또는 아래 설명으로 나타내는 컴포넌트 및/또는 방법/프로세스의 구성 및 배열의 세부사항에 대한 응용으로 반드시 한정되는 것은 아니다.
통상의 기술자라면 이해할 수 있는 바와 같이, 본 개시의 양태는 시스템, 방법/프로세스 또는 컴퓨터 프로그램이나 제품으로 구현될 수 있다. 따라서, 본 개시의 양태는 전체적으로 하드웨어 구현, 전제적인 소프트웨어 구현(펌웨어, 레지던트 소프트웨어, 마이크로 코드 등 포함) 또는 본 명세서에서 "회로", "모듈" 또는 "시스템"으로 모두 포괄적으로 지칭될 수 있는 소프트웨어와 하드웨어 결합 구현 양태의 형태를 취할 수 있다. 또한, 본 개시의 양태는 내부에 구현된 컴퓨터 판독 가능 프로그램 코드를 가지는 하나 이상의 비일시적 컴퓨터 판독가능 (저장) 매체(들)로 구현된 컴퓨터 프로그램 제품의 형태를 취할 수 있다.
실시예는 개시된 발명의 예시 또는 구현이다. "하나의 실시예", "일 실시예" 또는 "일부 실시예"의 다양한 형태가 반드시 모두 동일한 실시예를 나타내는 것은 아니다. 개시된 발명의 다양한 특징이 단일의 실시예의 맥락에서 설명될 수 있지만, 이 특징들은 개별적으로 또는 임의의 적절한 조합으로 제공될 수도 있다. 반대로, 개시된 발명은 명확성을 위해 별개의 실시예들의 맥락에서 여기에 설명될 수 있지만, 개시된 발명은 단일의 실시예에서 구현될 수도 있다.
본 명세서에서 "하나의 실시예", "일 실시예", "일부 실시예" 또는 "다른 실시예"에 대한 참조는 그 실시예와 관련하여 설명되는 특정 특징, 구조, 또는 특성이 적어도 하나의 실시예에 포함되지만, 반드시 본 개시의 모든 실시예에 포함되는 것은 아님을 의미한다. 본 명세서에서 사용되는 어구 및 용어는 제한하는 것으로 해석되어서는 안 되며, 설명 목적만을 위한 것임을 이해해야 한다.
아래의 설명은, 특별히 CAN-C 프로토콜로 언급되고 있지만, 또한 CAN-FD 프로토콜에도 준용하여 적용 가능하다.
이 문서 전체에 걸쳐, 상표 및 도메인 이름에 대한 많은 텍스트 및 그래픽 참조가 이루어질 때, 이들 상표 및 도메인 이름은 각각의 해당 소유자의 자산이며, 본 명세서에서는 설명 목적만을 위해 참조된다.
도 la는 차량의 전형적인 컴퓨터화된 서브시스템을 도식적인 형태로 개괄적으로 나타낸다. 서브시스템(10)은 복수의 ECU("노드"라고도 알려짐)(11a-11n)를 포함하며, 각각은 가속 페달, 브레이크 페달, 스티어링 휠, 실내 온도, 에어백, 기어 상태 등과 같은, 차량의 하나 이상의 디바이스 또는 스킴의 상태를 제어하거나 모니터링한다. 차량은 수십 개의 이런 ECU를 포함할 수 있는 한편, ECU(11a-11n)는 CAN 버스(13)를 통해서 서로 그리고 관련 제어 또는 모니터링되는 디바이스나 스킴과 통신한다.
CAN 버스(13)는 메시지 기반 프로토콜이다. CAN 버스 메시지(20)의 구조를 도식적으로 도시하는 도 1b를 참조한다. 메시지(20)는 SF(Start of Field)(21), 메시지 ID(23), 제어(25), 데이터(27), CRC(29), Ack(31), 및 EF(End of Frame)(33)의 필드를 포함한다. 메시지 ID(23)는 전형적으로 메시지의 타입(예를 들면, 에어백 메시지, 기어 제어 메시지, 휠 드라이브 메시지 등) 및 데이터 프로토콜 내에서 ID의 우선순위 레벨을 정의한다. 사실상, 메시지 ID는 메시지의 발신자를 어느 정도 정의한다(각 ECU는 하나 또는 여러 개의 다른 메시지 ID를 사용할 수 있기 때문임). 사용되고 있는 특정 포맷에 따라, 메시지 ID의 길이는 표준 포맷에서 11비트(2바이트), 또는 확장 CAN 버스 포맷에서 29비트(4바이트)일 수 있다. SF 필드(21)는 두 포맷(11 또는 29비트) 중 어느 것이 메시지 ID에 사용되는지를 나타낸다. 체크 필드라고도 알려진, 제어 필드(25)는, 데이터 필드에 포함된 정보의 아이템 수를 표시한다. 제어 필드는 메시지의 임의의 수신자가 수신된 메시지에 모든 정보가 전송되었는지 여부를 체크할 수 있게 한다. 길이가 0-8바이트 사이의 범위인 데이터 필드(27)는 버스(13) 상에 전송된 실제 정보, 즉 임의의 다른 ECU(11)가 읽을 수 있는 정보를 포함한다. CRC 필드(30)는 15비트의 순환 중복 검사(Cyclic Redundancy Check) 코드를 포함하는 순환 중복 검사 필드이다. ACK 필드(32), 즉, Acknowledge 필드는, 전송된 메시지의 임의의 수신자가 메시지를 올바르게 수신했다는 신호를 메시지 발신자에게 보낼 수 있게 한다. 에러가 검출되는 경우, 수신자는 메시지 발신자에게 즉시 통지한다. 그러면 메시지 발신자는 메시지를 재전송할 수 있다. 용어 "자동차(car)" 및 "차량(vehicle)"은 본 명세서에서 상호 교환적으로 사용된다.
위에서 언급한 바와 같이, CAN 버스의 안전성 및 무결성을 모니터링 및 보호하고, 유지 관리를 수행하기 위해서, 네트워크 상의 트래픽의 적어도 일부를 기록하고, 이 트래픽 기록을 무선으로(예로써, 모바일 통신으로) 원격 제어 센터로, 또는 하드와이어적 연결에 의해 로컬 메인터넌스 장치로 내보내는 것이 빈번히 필요하다. 차량의 50-100개의 ECU 각각은 대략 수 ㎲에서 수십 ㎲ 마다 하나의 메시지로 주기적으로 메시지 전송을 발행한다. 전형적으로 수백 또는 수천 개의 서로 다른 메시지가 매 초당 전송된다. 대역폭이 1Mb/s인 단일의 CAN-C 네트워크 세그먼트는 하루에 대략 10MB의 데이터를 발생시킬 수 있다. 최신 차량은 이런 네트워크 세그먼트가 5-10개 포함되어, 차량당 하루에 50-100MB의 데이터를 발생시킬 수 있다. 최근 도입된 CAN-FD 프로토콜은 이 전송 사이즈를 몇 자릿수는 증가시킨다. 오늘날 공공 클라우드 인프라 및 4G 셀룰러 기술 보급에도 불구하고, 전 차량에 대해 이러한 양의 기록 데이터를 업로드하고 저장하는 것은 어려운 문제이다. 본 발명은 원격 모니터링 센터 또는 메인터넌스 장치에서 기록 데이터의 매우 큰 축소, 및 압축 전송 기록의 복구를 가능하게 하는 압축 방법을 제공한다(이하, 간소화하기 위해 아래의 설명은 원격 모니터링 센터의 경우를 가정하지만, 동일한 방법이 하드와이어적 연결된 메인터넌스 장치의 경우에도 마찬가지로 적용될 수 있다).
CAN 버스 트래픽은 실제로 일련의 메시지이다. CAN 버스에서 각 ECU는 전형적으로 자신에 대해 정의된 일정한 기간에, 자체 메시지 ID와 함께, 자체 메시지를 발행한다(몇가지 예외가 있음). 두 개의 ECU가 자체 메시지를 버스 상에 동시에 전송하려고 시도하는 경우가 있다. 이러한 충돌을 해결하기 위해, CAN 버스 프로토콜은 보다 낮은 메시지 ID를 가지는 메시지에 우선순위를 주는 중재 절차를 가진다. 그러면 "거절된" ECU는 그 직후에 "거절된" 메시지를 재발행한다. 따라서, 많은 경우에 특정 ECU에 의해 다음 메시지가 발행될 시간을 예측할 수 있지만, 동시적 타입의 충돌로 인해 발행된 메시지가 "거절"되는 경우, 이 특정 ID의 모든 다음 메시지의 발행 시간은 한번 딜레이되지만, 다음 메시지에 대한 주기는 여전히 유지된다.
메시지 기록을 모니터링하기 위해, 원격 제어 센터는 많은 경우에 다음의 3개의 메시지 필드에 의해 충족될 수 있다고 본 발명자들은 결론 내렸다. (a) 버스 상에 각 메시지의 출현 시간을 나타내는 타임스탬프(이 타임스탬프는 실제로 CAN 버스에서 전송된 원본 메시지의 일부는 아니지만, 검사 및 모니터링 목적으로 이후에 추가되어야 함); (b) 메시지 ID(원래, 2 또는 4바이트); 및 (c) 데이터 필드(원래 최대 8바이트). 원본 메시지의 나머지 필드는 전형적으로 네트워크 세그먼트의 로컬 적정 운영을 위한 제어 데이터만을 포함하며, 보안(security), 예측 유지 관리(predictive maintenance), 또는 기타 데이터 기반 외부 애플리케이션과 같은 차량 모니터링 애플리케이션에 필요하지 않다. 이 관점은 본 발명을 제한해서는 안 되는데, 일부 경우에는 원본 메시지의 추가적인 필드를 원격 제어 스테이션에서 필요로 할 수 있으며, 이에 따라 이것들은 원격 위치로의 전송에 포함될 수 있기 때문이다.
본 발명자들은 방대한 양의 CAN 버스 메시지가, 각각이 메시지의 데이터 필드 또는 그 일부 내에서, 값이 대체되는 몇 개의 미리 정의된 펑션에 기초한다는 사실이, 특히, 데이터를 원격 위치로 전달할 필요가 있는 경우, 매우 효율적인 압축의 기초로 이용될 수 있다는 점을 알아냈다. 예를 들어, 많은 CAN 버스 메시지는 다음의 펑션을 이용한다:
(a) 카운터: 많은 연속적인 메시지가 자신의 데이터 필드에 카운터를 적용한다. 일부 경우에, 카운터는 데이터 필드의 일부(예를 들면, 2바이트)를 차지하지만, 다른 경우에는, 카운터는 전체 데이터 필드를 차지한다. 카운터가 관찰되는 경우, 단일 압축 커맨드는, 예를 들면, 제1 메시지 인스턴스에 카운터의 값 및 순차적인 출현 수를 포함시킴으로써, 500개의 연속적인 CAN 버스 카운터 타입 메시지를 기술할 수 있다. 압축 커맨드 내에 이 정보를 전송함으로써, 이러한 예시적인 500개의 메시지를 형성하는 데이터 세트 내의 각각의 모든 CAN 메시지는 이 단일의 압축 커맨드에 기초하여 원격 위치에서 재구성될 수 있다.
(b) 상수: 많은 CAN 버스 메시지는 자신의 데이터 필드, 또는 그 일부에 상수 값을 포함한다. 즉: 데이터 필드 내의 적어도 몇 바이트는 많은 메시지에서 여러 번 반복된다. 따라서, 많은 인스턴스에서 반복되는 것으로 확인되는 이러한 바이트가 사전 동작 상태에서 인덱싱되면, 전체(또는 부분적) 데이터 필드가 원격 위치로 전송되는 압축 커맨드에서 몇 비트 사이즈의 대체 인덱스에 의해 지정될 수 있다.
(c) 데이터 필드 CRC(이 용어 "데이터 필드 CRC"는 데이터 필드의 일부, 예를 들면, 데이터 필드의 단일 바이트 내에 나타나는 CRC 코드를 나타내며, 메시지 프레임 내에 2바이트가 CAN 버스 메시지의 표준 필드로 할당되는 "메시지 CRC"와 구별됨): 모든 메시지가 로컬 버스를 통해 적절하게 전송되고 수신되었는지를 확인하기 위해 수신하는 ECU에 의해 기술적으로 사용되는 메시지 CRC의 2바이트 필드 외에, 데이터 필드 내에 하나 이상의 바이트가 메시지를 인증하는데 추가로 사용되는 경우가 많다. 데이터 필드 CRC는 CAN 버스 내의 모든 ECU에 내부적으로 알려져 있는 펑션의 산물이며, 모든 ECU는, 각각, 메시지를 생성하고 인증하기 위해 동일한 미리 정의된 펑션으로 동작한다. 이 펑션 데이터 필드가 알려져 있고, 데이터 필드 CRC 값이 CAN 버스의 메시지 내에서 검색되면, 이 CRC 펑션을 원격 모니터링 센터에 압축 커맨드로 (특정 시리즈의 메시지, 또는 관련된 모든 메시지에 대해) 한 번만 보고하는 것으로 충분하고, 이 보고는 수신하는 모니터링 센터에서 많은 데이터 필드 CRC를 재구성하고, 원격 모니터링 센터에서 재구성된 메시지 내에서 그것들을 대체하는데 충분하다.
(d) 기타 펑션: CAN 버스 메시지 내에 적용되는 전용 또는 표준의 기타 펑션이 있으며, 그 중 일부는 특정 사례, 즉, 특정 제조업체, 모델 등에 따라 달라지며, 나머지는 모든 차량에서 표준이다. 이러한 모든 펑션은, 알려진 경우, CAN 버스 상에서 연속적 또는 비연속적인 메시지에서 나타나는 많은 데이터 필드를 기술하도록 단일의 새로 생성된 압축 커맨드에 사용될 수 있다.
요약하면, 펑션이 알려진 경우, 50,000개의 메시지의 데이터 필드(또는 그 일부)라도 새로 구성된 압축 커맨드의 단일 라인에 의해 기술될 수 있으며, 그 데이터 필드는 이 압축 커맨드에 기초하여 원격 위치에서 재구성될 수 있다.
일반적으로 2-4바이트를 차지하는 메시지 ID 필드도 압축될 수 있다. 전형적으로, CAN 버스는 최대 100개의 ECU를 포함하며, 각 ECU는 기껏해야 몇 개의 다른 메시지 ID를 발행할 수 있다. 따라서, 여러 메시지 ID가 최대 4바이트에 걸쳐 있더라도(순차적이지 않기 때문에), 대략 6-7비트(즉, 바이트 사이즈 미만)를 차지하는 순차적 리스트를 형성하도록 인덱싱될 수 있다.
도 2는 본 발명의 일 실시예에 따른 차량의 컴퓨터화된 서브시스템을 일반적인 도식적 형태로 나타낸다. 종래 기술의 서브시스템(10)과 유사하게, 본 발명의 서브시스템(100)은 복수의 ECU(111a-111n)를 포함하며, 각각은 가속 페달, 브레이크 페달, 스티어링 휠, 실내 온도, 에어백 등과 같은, 차량의 하나 이상의 디바이스 또는 스킴의 상태를 제어한다. ECU(111a-111n)는 CAN 버스(113)를 통해서 서로 또는 각각의 제어되거나 모니터링되는 디바이스나 스킴과 통신한다. 또한, 서브시스템(100)은 압축 유닛(115)을 포함한다. ECU 형태를 가질 수 있는 압축 유닛(115)은, 일반적으로 압축 엔진(117), 센서(119), 및 기록 스토리지(121)를 포함한다. 압축 유닛(115)은 2개의 작동 상태인, 트레이닝 상태 및 동작 상태를 갖는다. 전형적으로 한 번만 수행되는 트레이닝 상태 동안, 압축 유닛(115)은 CAN 버스(113)를 통한 메시지의 흐름을 기록하도록 활성화된다. 보다 구체적으로, 센서(119)는 예를 들어, 1시간의 기간 T1 동안, CAN 버스를 통해 정보의 흐름을 "리슨(listen)"한다. 기간 T1 동안 메시지의 흐름은 압축 엔진(117)에 의해 기록되고 기록 스토리지(121) 내에 저장된다. 다음으로, 여전히 트레이닝 상태 동안, 압축 엔진(117)(또는 CAN 버스의 외부에 있을 수 있는 임의의 다른 프로세서)은 이 흐름을 분석하고, 기록 내에서 여러 타입의 펑션을 결정하며, 도 3과 관련하여 설명될 메시지 프레임 내에서 여러 값과 필드에 대한 인덱싱을 수행한다. 전송 유닛(123)은 압축된 CAN 버스 데이터를 내보내도록 원격 위치 또는 로컬 메인터넌스 디바이스와 통신한다.
일반적으로, 본 발명은 CAN 버스 메시지의 흐름을 압축하는 방법에 관한 것으로, 다음의 스텝을 포함한다.
트레이닝 단계 동안:
- 메시지의 트레이닝 흐름 내에서 적어도 하나의 시리즈 타입 패턴을 결정하는 것 - 각 시리즈 타입 패턴은 동일한 메시지 ID를 가지는 순차적인 시리즈의 CAN 버스 메시지의 데이터 필드에 나타나는 데이터 값에 걸쳐 있음 -. 이 패턴은 일부 펑션 패턴을 따르는 값이거나, 또는 동일한 메시지 ID를 가지는 순차적인(시리즈의) 메시지의 데이터 필드(또는 그 일부) 내에 반복적으로 나타나는 특정(상수) 값일 수 있다;
- 패턴 각각에 대해 압축된 시리즈 타입 커맨드를 정의하는 것 - 각 시리즈 타입 커맨드는: (a) 시리즈 내 제1 메시지의 타임스탬프; (b) 시리즈의 메시지 ID; (c) 패턴 타입; (d) 패턴이 나타나는 메시지 내의 필드 또는 그 일부의 표시; (d) 시리즈 내 제1 메시지에서의 파라미터 값; (e) 시리즈의 메시지 간의 주기; 및 (f) 시리즈 내 메시지의 수; 중에서 선택된 파라미터를 포함함 -;
압축 단계 동안:
- CAN 버스 메시지의 흐름의 기록을 그룹들로 나누는 것 - 각 그룹은 동일한 메시지 ID를 가지는 메시지와 관련됨 - ;
- 각 그룹 내에서, 동일한 패턴의 하나 이상의 시리즈의 메시지를 검색하는 것 - 각 시리즈는, 예를 들면, 적어도 5개의 메시지에 걸쳐 있음 -. 일부 패턴을 충족하는 시리즈의 메시지는 일반적으로 5개보다 훨씬 더 많으며, 수백, 수천 개의 메시지에 이를 수 있음에 유의해야 한다;
- 검색된 시리즈의 메시지 각각에 대해서, 트레이닝 단계에서 정의된 형식으로 시리즈 타입 압축 커맨드를 형성하는 것 - 압축된 시리즈 타입 커맨드는 트레이닝 단계 동안 해당 커맨드에 대해 정의된 적어도 복수의 파라미터에 대한 값을 포함함 - ; 및
압축 해제 단계 동안:
- 각각의 시리즈 타입 압축 커맨드를 이용하여 각각의 시리즈의 메시지의 콘텐츠의 적어도 일부를 재구성하는 것, 여기서 압축 커맨드는 재구성된 메시지의 각 개체의 각각의 필드 또는 그 일부 내에 각각의 값을 채운다.
도 3은 본 발명의 트레이닝 절차(200)를 개괄적으로 나타낸다. 스텝 202에서, CAN 버스 상의 메시지의 흐름이 기록되고 저장된다. 스텝 204에서, 메시지 ID와 관계없이 메시지 흐름 기록 내에서 여러 번 반복되는 것으로 검색되는 특정 데이터 값(이후, "상수(constants)"라고도 함)이 결정된다. 이들 결정된 데이터 값은 메시지 프레임의 전체 데이터 필드(27)(도 1b) 또는 그 일부에 걸쳐 있을 수 있다. 가장 공통적인 것으로 검색되는 이들 데이터 값은 인덱싱된다. 예를 들어, 이런 반복되는 데이터 값이 32개가 검색되면, 그것들은 5비트에 걸쳐 있는 인덱스 공간인 0부터 31까지의 구별된 인덱스를 받는다. 이런 식으로, 통상적으로, 예를 들면, 6 또는 8바이트에 걸쳐 있는 데이터 값(패턴)은 5비트로 표현될 수 있다. 이들 패턴이 여러 번, 때로는 CAN 메시지의 1분 간의 기록 내에서 수천 번 반복된다는 사실은 상당한 압축으로 이어진다.
다음으로, 전체 기록은 복수의 서브 흐름으로 나뉘며(스텝 206), 각 서브 흐름은 단일 메시지 ID의 메시지만을 나타낸다. 그 다음에 기록 내에서 검색되는 모든 메시지 ID의 컬렉션이 순차적으로 인덱싱된다(스텝 208). 메시지 ID 필드가 메시지 프레임에서 최대 4바이트(11비트 또는 29비트)에 걸쳐 있지만(도 1b 참조), 네트워크에서 평균적으로 64개 이하의 서로 다른 메시지 ID가 있다고 가정하면, 모든 메시지 ID의 전체 공간은 6비트(또는 비교적 드문 경우에는 7비트)만으로 나타내질 수 있다. 이 메시지 ID의 인덱싱은 또한 상당한 압축으로 이어진다.
다음으로, 스텝 210에서 메시지 내에 나타나는 여러 타입의 펑션이 결정된다. 펑션은 y = (f)x로 정의된다. 펑션이 결정되어 알려지고, 동일한 ID와 관련된 시리즈의 메시지의 메시지 내 데이터 필드가 이 펑션을 따르는 경우, 하나의 메시지의 단일 값이 주어지면, 전체 시리즈의 메시지 내의 모든 데이터 필드 값을 결정할 수 있게 된다. 다음은 CAN 버스 트래픽 내에서 전형적으로 나타나는 펑션의 예시일 뿐이다: (a) 상수: (b) 카운터; (c) CRC 등. 또한, 특정 압축 커맨드는, 이하에 설명되는 바와 같이, 스텝 210에서 각 펑션에 대해, 각각, 정의된다.
스텝 212에서 헤더가 정의된다. 헤더는 압축 데이터와 함께, 압축 엔진(117)으로부터 원격 제어 센터로의 각각의 압축된 기록에 대해 전송되는 메타데이터를 포함한다. 메타데이터는, 예를 들면, 다양한 인덱싱 테이블, 펑션의 정의, 및 데이터 파일의 압축 커맨드가 주어지면, 모니터링 센터에서 메시지를 재구성하는데 필요할 수 있는 임의의 기타 정보를 포함한다.
도 4는 압축 유닛(115)의 동작 단계(300)를 개괄적으로 나타낸다. 단계 302에서, CAN 버스를 통한 메시지의 트래픽이 기록되고 압축 유닛의 기록 스토리지(121) 내에 저장된다. 다음으로, 스텝 304에서, 기록된 메시지의 흐름은 별개의 그룹으로 나뉘고, 각 그룹은 동일한 메시지 ID의 메시지를 포함한다. 스텝 306에서, 각각의 그룹의 원본 메시지는, 각자의 데이터 필드가 도 2의 스텝 210에서 정의된 임의의 펑션을 반영하는지 여부를 확인하도록, 개별적으로 분석된다. 앞서 언급된 바와 같이, 펑션은, 예를 들면, 카운터 펑션, 데이터 필드 CRC 펑션, 상수 펑션, 또는 임의의 다른 정의된 펑션일 수 있다. 펑션이 전체 그룹을 형성하는 시리즈의 메시지 내에서, 또는 그룹의 일부를 형성하는 시리즈의 메시지 내에서 실제로 검색되는 경우, 검색된 전체 시리즈를 기술하도록 특정 압축된 펑션 타입 커맨드가 압축 엔진(117)에 의해 형성된다. 이 단계에서는 커맨드가 아직 완성되지 않고, 이어지는 하나 이상의 스텝에서 완성되기를 기다린다. 일부 경우에, 펑션이 시리즈의 메시지에서 데이터 필드의 일부만을 차지할 때, 데이터 필드의 나머지는, 예를 들면, 동일한 압축 커맨드 내의 상수의 인덱스에 의해, 또는 이들 상수를 개별로 타깃으로 하는 추가적인 압축 커맨드에 의해, 완성될 수 있다.
스텝 308에서, 압축 엔진(117)은 도 2의 스텝 204에서 검색되고, 인덱싱되고, 저장된 이전에 인덱싱된 상수 중 어느 것을 포함하는지 여부를 검색하도록 각 메시지 그룹을 계속해서 조사한다. 두 가지 경우가 있을 수 있다. 첫 번째 경우, 상수는 원본 메시지의 데이터 필드의 일부와 관련된다(데이터 필드의 나머지는 펑션 타입 데이터를 포함할 수 있음). 이런 경우에, 해당 상수의 인덱스는 스텝 306에서 이미 생성되어 있는 각각의 압축된 펑션 타입 커맨드에 추가될 수 있다. 또 다른 경우에, 상수가 전체 데이터 필드와 관련되는 경우, 상수의 인덱스를 포함하는 별개의 상수 타입 커맨드가, 데이터 필드가 동일한 데이터 값을 포함하는 시리즈의 원본 메시지를 하나의 커맨드로 기술하도록 형성된다. 스텝 310에서, 상수 또는 펑션 조건을 충족하지 않는 임의의 나머지 메시지에 대해, 각각의 원본 메시지의 전체 데이터 필드를 포함하는 개별 압축 커맨드가 생성된다.
스텝 312에서, 그룹에 형성되어 있는 각 압축 커맨드에 대해서, 해당 그룹의 메시지 ID의 각각의 인덱스가 (도 2의 스텝 208에서 준비된 바와 같은) 메시지 ID 인덱스 테이블로부터 추출되고, 각각의 압축 커맨드에서 대체된다. 언급한 대로, 이 대체는, 원본 CAN 버스 메시지의 11 또는 29비트와 비교하여, 6 또는 7비트를 차지한다.
위의 절차는 기록 내 모든 ID 그룹에 대해 개별적으로 반복된다. 다음으로, 스텝 314에서 타임스탬프가 생성된 압축 커맨드 각각에 추가된다. 시리즈의 메시지와 관련된 임의의 펑션 또는 상수 타입 메시지에 대해, 제1 메시지의 타임스탬프가 포함된다. 반복 횟수와 메시지가 나타나는 주기도 추가되어 모니터링 센터에서 전체 시리즈의 메시지를 재구성하는데 충분하다. 그러나, 시리즈 내의 메시지의 주기적 반복이 한번 이상 딜레이되는 예외적인 경우가 있을 수 있다. 앞서 언급한 바와 같이, 이 딜레이는, 예를 들면, 두 개의 개별 ECU가 버스에 자신의 메시지를 동시에 전송하려고 시도하는 충돌의 경우로 인해 발생할 수 있다. 이런 경우에, 보다 낮은 메시지 ID를 가지는 메시지가 먼저 전송된다. 나머지 메시지는 딜레이되어 그 직후에 전송된다. 이 문제를 해결하여 모니터링 센터에서 별개의 메시지 각각에 그들의 정확한 타임스탬프를 정확히 할당할 수 있도록 특수 메커니즘이 제공된다. 이 메커니즘은 예시로서 설명된다.
예시 1
펑션 타입 메시지가 500개의 메시지와 관련되어 있다고 가정한다. 시리즈 내 제1 메시지는 타임스탬프 0.00에서 시작하고, 시리즈 내 임의의 두 메시지 간의 주기는 10㎲이다. 초기 타임스탬프 t1 및 주기 P를 포함하면, 수신하는 모니터링 센터는, 예를 들면, 시리즈 내 101번째 메시지는 시간 1000㎲에서 발생했으며, 500번째 메시지(즉, 시리즈 내 마지막 메시지)는 4990㎲의 타임스탬프를 수신해야 한다고 결론을 내릴 수 있다.
예시 2
이전 예시와 유사하게, 펑션 타입 메시지가 500개의 메시지와 관련되어 있다고 가정한다. 시리즈 내 제1 메시지는 타임스탬프 0.00에서 시작하고, 시리즈 내 임의의 두 메시지 간의 주기는 10㎲이다. 그러나, 101번째 메시지에서 3㎲의 첫 번째 딜레이가 발생하고, 301번째 메시지에서 2㎲의 두 번째 딜레이가 발생했다. 따라서, 시리즈 타입 압축 메시지에는, 앞서 언급한 초기 타임스탬프 t1 및 주기 P에 더하여, 두 개의 딜레이 파라미터 (DL:101,+3) 및 (DL:301,+2)도 포함할 것이다. 이는 모니터링 유닛에서 시리즈 내 첫 100개의 메시지는 딜레이 없이 나타났으며(즉, 100번째 메시지는 990㎲의 타임스탬프를 가짐), 101번째부터 300번째까지의 모든 메시지는 예상에 비해 3㎲의 딜레이된 타임스탬프를 가지고(즉, 300번째 메시지는 2993㎲의 타임스탬프를 수신해야 함), 301번째부터 500번째까지의 모든 메시지는 5㎲의 딜레이된 타임스탬프를 가져야 한다(즉, 500번째 메시지는 4995㎲의 타임스탬프를 수신해야 함)고 결론을 내릴 수 있을 것이다. 딜레이의 표시는 바람직하게는 (계산된 바와 같은) 예상 타이밍에 대해 상대적이며, 딜레이는 포지티브(+) 또는 일부 경우에는 네거티브(-)의 딜레이를 가질 수 있다는 점에 유의해야 한다. 전역(global)이 아닌 상대적 값이 사용된다는 사실은 추가적인 몇 비트(예를 들면, 최대 3-4비트)만을 소모한다. 그러나, 일부 경우에는, 타임스탬프의 절대 값이 압축 커맨드에 사용될 수 있다. 또한, 임의의 수의 DL 파라미터가 단일 압축 커맨드 내에 포함될 수 있다.
위의 절차는 스텝 316에서 모든 서로 다른 그룹에 대해 개별적으로 반복된다. 다음으로, 스텝 318에서 헤더 섹션이 준비된다. 헤더 섹션은, 모든 압축 커맨드가 주어지면, 전체적인 메시지의 기록을 재구성하는데 필요한 임의의 정보를 모니터링 센터에 제공한다. 예를 들어, 헤더는, 그 중에서도, 모든 인덱스 테이블, 압축 커맨드를 구성하는 동안 사용된 펑션의 간략 설명, 및 필요하다고 판단될 수 있는 임의의 기타 정보 또는 통상적인 정의를 포함할 수 있다. (예를 들어 동일한 자동차 또는 유사한 차량에 대한 메시지 기록의 이전 전송으로 인해) 모니터링 센터가 이미 헤더에 포함되어 있는 모든 필요 정보를 가지고 있는 경우에는, 헤더는 압축 파일로부터 제거될 수 있다는 점에 유의해야 한다. 마지막으로, 스텝 320에서 헤더를 포함하는 압축 파일, 및 압축 커맨드가 원격 위치로 전송된다. 언급한 바와 같이, 일부 경우에, 압축 파일은 하드와이어 방식으로 전송될 수 있으며, 나중에 사용되기 위해 시스템 내에 로컬적으로 저장된다.
본 발명의 방법은 극동 및 미국에서 다양한 차량에서 테스트되었다. 두 경우 모두에서 96%-98%의 압축률을 확인하였다.
도 5는 본 발명의 일 실시예에 따른 원격 모니터링 센터에서 수행되는 압축 해제 프로세스(400)를 설명한다. 스텝 402에서, 모니터링 센터에서 압축 파일이 수신된다. 스텝 404에서, 헤더가 압축 커맨드에서 분리된다. 스텝 406에서, 헤더 정보 및 압축 커맨드가 주어지면, 메시지의 흐름은 각 ID에 대해 개별적으로 재구성된다. 마지막으로, 스텝 408에서 이전에 각 ID에 대해 재구성되어 있는 개개의 흐름이 결합되어 차량에 기록되어 있던 원래 흐름과 유사한 전체 흐름을 재구성한다.
예시 3
일례로, 다음의 압축 커맨드가 사용될 수 있다:
● IDN(ID, TS, DLC, DATA, TI, N, DL)
이 압축 커맨드는 시리즈의 메시지를 생성하도록 설계되고, 각 메시지는 동일한 상수 데이터 값을 가진다.
ID - CAN 메시지 인덱싱된 ID;
TS - 시리즈 내 제1 메시지의 타임스탬프(전역 타임스탬프);
DLC - 데이터 길이(바이트);
DATA - 데이터 바이트 콘텐츠;
TI - 커맨드 간 시간 간격(P);
N - 시리즈 내 커맨드의 수;
DL - 하나 이상의 딜레이(예상과 비교한 상대적 기간);
● BYTE_DATA_CONST(ID, TS, DI, DATA, TI, N, DL)
이 압축 커맨드는 동일한 ID의 시리즈의 메시지에서 데이터 바이트/들 DI1-n을 주어진 값 DATA로 채우도록 설계된다.
TS - 시리즈 내 제1 메시지의 타임스탬프(전역 타임스탬프);
ID - CAN 메시지 인덱싱된 ID;
DI1-n - 데이터 바이트 인덱스/인덱스들;
DATA - 바이트/들 데이터 값/들;
TI - 커맨드 간 시간 간격(P);
N - 시리즈 내 커맨드의 수;
DL - 하나 이상의 딜레이(예상과 비교한 상대적 기간);
● BYTE_DATA_COUNTER(ID, TS, DI1-n, IN_VALUE, TI, N, TS)
이 압축 커맨드는 동일한 ID의 시리즈의 메시지에서 데이터 바이트/들 DI1-n을 카운터 값으로 채우도록 설계된다.
ID - CAN 메시지 인덱싱된 ID;
TS - 시리즈 내 제1 메시지의 타임스탬프(전역 타임스탬프);
DI1-n - 데이터 바이트 인덱스/인덱스들;
IN_VALUE - 초기 카운터 값;
N - 시리즈 내 커맨드의 수;
TI - 커맨드 간 시간 간격(P);
DL - 하나 이상의 딜레이(예상과 비교한 상대적 기간);
● BYTE_DATA CRC(ID, TS, DI1-n, IN_VALUE, TI, N, TS)
이 압축 커맨드는 동일한 ID의 시리즈의 메시지에서 데이터 바이트/초 DI1-n을 CRC 펑션 값으로 채우도록 설계된다.
ID - CAN 메시지 인덱싱된 ID;
TS - 시리즈 내 제1 메시지의 타임스탬프(전역 타임스탬프);
DI1-n - 데이터 바이트/들 인덱스/인덱스들;
IN_VALUE - 초기 카운터 값;
N - 시리즈 내 커맨드의 수;
TI - 커맨드 간 시간 간격(P);
DL - 하나 이상의 딜레이(예상과 비교한 상대적 기간);
● BYTE_INDEXED_DATA(ID, TS, DI1-n, DATA_INDEX, TI, N, TS)
이 압축 커맨드는 동일한 ID의 시리즈의 메시지에서 데이터 바이트/들 DI1-n을 인덱싱된 데이터 값으로 채우도록 설계된다.
ID - CAN 메시지 인덱싱된 ID;
TS - 시리즈 내 제1 메시지의 타임스탬프(전역 타임스탬프);
DI1-n - 데이터 바이트/들 인덱스/인덱스들;
INDEXED_DATA - 데이터 값의 인덱스;
N - 시리즈 내 커맨드의 수;
TI - 커맨드 간 시간 간격(P);
DL - 하나 이상의 딜레이(예상과 비교한 상대적 기간);
대안으로, 적절한 파라미터 값이 커맨드의 타입을 나타내는 단일 압축 커맨드가 사용될 수 있다. 예를 들면, 파라미터는 다음의 대체 값을 포함할 수 있다: CRC, 카운터, 상수 등.
예시 4
4개의 서로 다른 CAN 버스에 대해 본 발명의 방법으로 여러 실험이 수행되었다. 다음은 Gzip 압축과 비교한 결과이다. 알 수 있는 바와 같이, 원본 파일은 본 발명에 의해 자신의 원본 사이즈의 약 2.4%-3.4%로, 각각, 압축되었다. CAN 버스는 초당 대략 2000개의 메시지를 포함했다.
본 방법
 Gzip* 압축
 원본 로그
압축률 파일 사이즈(KB) 압축률 압축된 Gzip(KB) 파일 사이즈(KB) 메시지 수 고유 ID 수 테스트 번호
2.4% 2,579 17.08% 18,334 107,352 1,582,986 131 파일 1
2.4% 3,142 17.33% 22,410 129,300 1,906,057 98 파일 2
3.2% 7,020 14.80% 32,247 217,904 3,404,755 129 파일 3
3.4% 7,973 15.45% 36,234 234,503 3,664,108 97 파일 4
*Gzip은 최신의 구문 압축 방법이다.
보여지는 바와 같이, 본 발명은 CAN 버스의 메시지 흐름을 압축하는 매우 효율적인 방법을 제공한다. 실험에서 96%-98%의 압축률이 얻어졌다. 본 발명은 메시지의 전체적인 원래 흐름을 기술하도록 몇 개의 압축 커맨드를 사용하여 수행될 수 있다.
본 발명의 일부 실시예가 예시적으로 설명되었지만, 본 발명은 본 발명의 기술 사상을 벗어나거나 청구범위를 벗어나는 일 없이, 다양한 수정, 변형, 및 개조하여, 그리고 통상의 기술자의 범위 내에 있는 다수의 동등 또는 대안 솔루션의 사용으로 실행될 수 있음이 명백할 것이다.

Claims (12)

  1. CAN 버스 메시지의 흐름을 압축하는 방법으로서,
    트레이닝 단계 동안:
    - 메시지의 트레이닝 흐름 내에서 적어도 하나의 시리즈 타입 패턴을 결정하고 - 각 시리즈 타입 패턴은 동일한 메시지 ID를 가지는 순차적인 시리즈의 CAN 버스 메시지의 데이터 필드에 나타나는 데이터 값에 걸쳐 있음 - ;
    - 상기 패턴 각각에 대해 압축된 시리즈 타입 커맨드를 정의하고 - 각 시리즈 타입 커맨드는: (a) 시리즈 내 제1 메시지의 타임스탬프; (b) 시리즈의 메시지 ID; (c) 패턴 타입; (d) 패턴이 나타나는 메시지 내의 필드 또는 그 일부의 표시; (d) 시리즈 내 제1 메시지에서 값 표시를 위한 파라미터; (e) 시리즈의 메시지 간의 기간; 및 (f) 시리즈 내 메시지의 수; 중에서 선택된 파라미터를 포함함 - ;
    압축 단계 동안:
    - CAN 버스 메시지의 흐름의 기록을 그룹들로 나누고 - 각 그룹은 동일한 메시지 ID를 가지는 메시지와 관련됨 - ;
    - 각 그룹 내에서, 동일한 패턴의 하나 이상의 시리즈의 메시지를 검색하고 - 각 시리즈는 적어도 5개의 메시지에 걸쳐 있음 - ;
    - 상기 검색된 시리즈의 메시지 각각에 대해서, 상기 트레이닝 단계에서 정의된 형식으로 시리즈 타입 압축 커맨드를 형성하고 - 상기 압축된 시리즈 타입 커맨드는 상기 트레이닝 단계 동안 해당 커맨드에 대해 정의된 상기 파라미터의 적어도 몇 개에 대한 값을 포함함 - ; 그리고
    압축 해제 단계 동안:
    - 각각의 상기 시리즈 타입 압축 커맨드를 이용하여 각각의 시리즈의 메시지의 콘텐츠의 적어도 일부를 재구성하는 것을 포함하며, 상기 압축 커맨드는 상기 재구성된 메시지의 각 개체의 각각의 필드 또는 그 일부 내에 각각의 값을 채우는 방법.
  2. 청구항 1에 있어서,
    상기 패턴 타입은 상기 메시지의 데이터 필드 또는 그 일부 내에 나타나는 펑션인 방법.
  3. 청구항 2에 있어서,
    상기 펑션은 각각, 값의 패턴이 연속적인 메시지의 데이터 필드 또는 그 일부 내에 나타나게 하는 카운터 또는 데이터 필드 CRC이며, 상기 압축 해제 단계는 상기 재구성된 시리즈의 메시지의 각각의 필드 내에 상기 값을 채우는 방법.
  4. 청구항 1에 있어서,
    상기 패턴 타입은 메시지의 데이터 필드 또는 그 일부 내에 나타나는 상수 값이고, 상기 압축 해제 단계는 상기 재구성된 시리즈의 메시지의 각각의 필드 내에 상기 상수 값을 채우는 방법.
  5. 청구항 4에 있어서,
    상기 트레이닝 단계는:
    - 메시지의 데이터 필드 또는 그 일부에서 통계적으로 여러 번 반복되는 복수의 상수 값을 결정하는 스텝;
    - 가장 공통적으로 나타나는 상수를 순차적으로 인덱싱하는 스텝을 더 포함하고; 그리고
    - 상기 압축 단계 동안의 각 상수 타입 커맨드는 상기 상수 자체가 아니라 상기 상수의 인덱스를 포함하는 방법.
  6. 청구항 1에 있어서,
    - 상기 CAN 버스 메시지의 상기 트레이닝 흐름에서 모든 ID를 순차적으로 인덱싱하는 스텝; 및
    - 상기 압축 단계 동안 상기 CAN 버스에 본래 나타나는 실제 메시지 ID가 아니라, ID의 인덱스를 각 압축 커맨드 내에 포함시키는 것을 더 포함하는 방법.
  7. 청구항 1에 있어서,
    각각의 시리즈 내 커맨드 간의 알려진 기간에 기초하여, 예상된 타임스탬프에 상대적인 하나 이상의 딜레이 표시를 상기 시리즈 타입 압축 커맨드 내에 포함시키는 것을 더 포함하는 방법.
  8. 청구항 1에 있어서,
    개개의 재구성된 메시지의 데이터 필드 내에 하나 이상의 특정 값을 도입하기 위한 하나 이상의 압축 커맨드를 더 포함하는 방법.
  9. 청구항 1에 있어서,
    복수의 압축 커맨드는 단일의 CAN 버스 메시지를 재구성하는 방법.
  10. 청구항 1에 있어서,
    상기 압축 커맨드 내에서 상기 패턴을 파라미터 값으로 표시하는 것 대신에, 각 패턴에 대해 서로 다른 압축 커맨드가 할당되는 방법.
  11. 청구항 1에 있어서,
    상기 압축 커맨드의 압축 해제는 헤더 내에 압축 위치로부터 압축 해제 위치로 전달되는 메타데이터를 사용하는 방법.
  12. 청구항 10에 있어서
    상기 헤더의 메타데이터는 (a) 상기 메시지 ID의 인덱싱 정보, (b) 상수의 인덱싱 정보, 및 (c) 압축 해제 측에서 커맨드를 서로 다른 재구성된 메시지의 필드 내의 값으로 적절히 변환할 수 있게 하는 특정 펑션 동작에 대한 세부 정보 중 하나 이상을 포함하는 방법.
KR1020227010331A 2019-08-29 2020-08-30 Can 버스 데이터를 압축하는 방법 KR20220054369A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962893192P 2019-08-29 2019-08-29
US62/893,192 2019-08-29
US202063026162P 2020-05-18 2020-05-18
US63/026,162 2020-05-18
PCT/IL2020/050939 WO2021038570A1 (en) 2019-08-29 2020-08-30 Method for compressing can-bus data

Publications (1)

Publication Number Publication Date
KR20220054369A true KR20220054369A (ko) 2022-05-02

Family

ID=74685296

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227010331A KR20220054369A (ko) 2019-08-29 2020-08-30 Can 버스 데이터를 압축하는 방법

Country Status (4)

Country Link
US (1) US20220303362A1 (ko)
KR (1) KR20220054369A (ko)
IL (1) IL280514B (ko)
WO (1) WO2021038570A1 (ko)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8010704B2 (en) * 2008-05-29 2011-08-30 GM Global Technology Operations LLC Method of efficient compression for measurement data
US9219499B2 (en) * 2014-05-16 2015-12-22 Robert Bosch Gmbh Run time compression method for a vehicle communication bus
US20170072876A1 (en) * 2015-09-14 2017-03-16 Broadcom Corporation Hardware-Accelerated Protocol Conversion in an Automotive Gateway Controller
US10706642B2 (en) * 2015-09-24 2020-07-07 Ford Global Technologies, Llc Efficient telematics data upload
US10880409B2 (en) * 2017-02-20 2020-12-29 Cisco Technology, Inc. Mixed qualitative, quantitative sensing data compression over a network transport

Also Published As

Publication number Publication date
IL280514A (en) 2021-03-01
WO2021038570A1 (en) 2021-03-04
US20220303362A1 (en) 2022-09-22
IL280514B (en) 2022-05-01

Similar Documents

Publication Publication Date Title
US10227053B2 (en) In-vehicle network system, electronic control unit, and update processing method
JP2713446B2 (ja) 多重伝送方式
RU2596582C2 (ru) Способ и устройство для адаптируемой к размерам памяти последовательной передачи данных
DE102017121049A1 (de) Kommunikationsverfahren, welches auf einer Fahrzeugsicherheitsintegritätsstufe im Fahrzeugnetzwerk basiert, und Vorrichtung für dasselbige
US10291482B2 (en) ECU for transmitting large data in HiL test environment, system including the same and method thereof
CN106168796B (zh) 一种用于阻止机动车辆网络中的欺骗的方法和系统
CN101587634B (zh) 无线机车信号车载设备控制程序及参数在线实时更新方法
EP3827364B1 (en) Message source detection in a vehicle bus system
CN111181732A (zh) 车载网络系统、电子控制单元及不正常检测方法
CN110554930B (zh) 一种数据存储方法及相关设备
CN103401955A (zh) 一种车辆总线设备地址配置方法及装置
CN104580425A (zh) 一种客户端数据同步方法及系统
KR20220054369A (ko) Can 버스 데이터를 압축하는 방법
JP3770053B2 (ja) 車両用ネットワークの通信復帰判定方法
CN110266808A (zh) 一种基于车载远程通讯模块文件上传的方法和系统
Yazdani et al. Memory-aware online compression of CAN bus data for future vehicular systems
EP4057574A1 (en) Microcontroller circuit, corresponding device, system and method of operation
CN115580471A (zh) 不正当检测方法、不正当检测装置以及存储介质
KR101704300B1 (ko) Can 메시지 송수신 방법 및 이를 실행하는 시스템
JPH0398338A (ja) 遠方監視制御装置の伝送方法
CN110727448B (zh) 用于充电桩的ota空中升级方法
CN110962883B (zh) 一种轨道车辆的数据通信方法、装置及相关设备
US20230353417A1 (en) Can module, can transceiver, can system and method for can module
KR20200052746A (ko) 차량 게이트웨이 시스템 및 그 제어 방법
DE102018114218B4 (de) Verfahren zum Betreiben einer Sensoranordnung in einem Kraftfahrzeug auf Basis eines DSI-Protokolls