WO2018196655A1 - 一种车载电子处理单元系统公共网络通讯方法 - Google Patents

一种车载电子处理单元系统公共网络通讯方法 Download PDF

Info

Publication number
WO2018196655A1
WO2018196655A1 PCT/CN2018/083344 CN2018083344W WO2018196655A1 WO 2018196655 A1 WO2018196655 A1 WO 2018196655A1 CN 2018083344 W CN2018083344 W CN 2018083344W WO 2018196655 A1 WO2018196655 A1 WO 2018196655A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
address
processing unit
bit
function
Prior art date
Application number
PCT/CN2018/083344
Other languages
English (en)
French (fr)
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 WO2018196655A1 publication Critical patent/WO2018196655A1/zh

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
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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

Definitions

  • the invention relates to a communication method, in particular to a public network communication method of an in-vehicle electronic processing unit system.
  • SAE J1939 is a controller area network (CAN: Controller Area Network) developed by Bosch, Germany, and recommended by the American Automotive Engineering Association (SAE) for network communication standards between electronic components on heavy road vehicles. It describes a network application for heavy vehicle fieldbus, including CAN network physical layer (J1939-11), data link layer (J1939-21), network layer (J1939-31), application layer (J1939-71), Protocols such as fault diagnosis (J1939-73) and network management (J1939-81) have a communication rate of 250Kbps. SAE J1939 is widely used in commercial vehicles, ships, rail locomotives, agricultural machinery and large engines.
  • Ethernet technology originally created by Xerox and gradually adopted by the network technology, uses the 802.3 standard developed by the Institute of Electrical and Electronics Engineers (IEEE) to manage the transmission of information on the network bus by various network devices. After decades of rapid development, it has become the most widely used and most common network technology in the world, and is widely used in local area networks and enterprise backbone networks around the world. Moreover, in order to enable Ethernet to have real-time transmission capability and meet the requirements of industrial field use, industrial Ethernet, which is improved on the basis of existing Ethernet, has emerged. The most representative industrial Ethernet is Siemens PROFINET. , B&R POWERLINK, Germany's Beckhoff EtherCAT, etc. These industrial Ethernet solutions address the environmental, safety and real-time data communication requirements of industrial sites.
  • IEEE Institute of Electrical and Electronics Engineers
  • the existing technology does not have a complete set of on-board computer system network implementation technology, and there is no network communication protocol that is completely suitable for the on-board computer system.
  • the on-board computer system (or in-vehicle electronic products) on the market has a messy product. Independent of each other, incompatible with each other, single function, resources can not be shared and many other issues.
  • the in-vehicle electronic processing unit system is an open and extensible public platform for on-board computers.
  • the mainframe only integrates basic hardware functions and operating systems, and other peripheral in-vehicle electronic products (such as GPS navigation, driving records, visual reversing, reversing radar, etc.)
  • a function module it is attached to the CAN network or Ethernet network of the system expansion to form a complete in-vehicle electronic processing unit system.
  • a network communication method suitable for an in-vehicle electronic processing unit system is adopted, and the in-vehicle electronic processing unit system and each extended function module are connected into an organic whole through the dedicated network communication method to realize data inter-use and resources. Sharing is the problem that needs to be solved now.
  • the present invention aims to provide a public network communication method for an in-vehicle electronic processing unit system to solve the problem that the in-vehicle electronic peripheral function modules are mutually independent, mutually incompatible, and resources cannot be shared.
  • a public network communication method for an in-vehicle electronic processing unit system comprises the following steps:
  • the first function module initiates a command or request communication to the second function module according to its actual demand, first establishes a 4-bit data type, a 4-bit function type, and an 8-bit data type according to the characteristics and requirements of the data communication, the module function and the module type.
  • Source module number or source address and actual transmission data including multiple data numbers, and establish TCP/UDP data fields according to Ethernet data format requirements and encapsulate them into Ethernet frames, or establish a 29-bit identifier ID according to CAN network format requirements.
  • an 8-byte data field to form a CAN extended frame;
  • the first function module sends an Ethernet frame or a CAN extended frame.
  • the second function module when the Ethernet frame or the CAN extension frame arrives at the second function module, the second function module receives and disassembles the Ethernet frame to obtain a TCP/UDP data field, or receives the CAN extension frame;
  • the second function module analyzes the TCP/UDP data field, or the CAN extension frame, and obtains a 4-bit data type, a 4-bit function type, an 8-bit source module number or a source address, and an actual transmission data including a plurality of data numbers;
  • the second function module performs a successful response or a failure response according to the analysis result, and thereby establishes a 4-bit data type, a 4-bit function type, an 8-bit source module number or a source address, and an actual transmission data including a plurality of data numbers. And according to the Ethernet data format requirements, establish a TCP/UDP data field and package it into a response Ethernet frame, and then send a response Ethernet frame; or create a 29-bit identifier ID and an 8-byte data field according to the CAN network format requirements to form a CAN. Responding to the extended frame, and then transmitting the CAN response extended frame;
  • the second function module needs to execute a command or a request according to the requirement of the first function module; if the data of the second function module needs to be acquired in the command or the request, the second function module needs to go to the first function.
  • the module sends the requested data;
  • the second function module does not execute the command or request required by the first function module, and returns directly.
  • the public network communication method of the in-vehicle electronic processing unit system divides each functional module into detailed divisions according to its function characteristics and data characteristics by data type, function type and module number, and is an in-vehicle electronic processing unit system.
  • the public network communication method developed by this patent makes the basic structure contents such as the nominal character, data type, function type, module number and parameter number of each functional module completely unified and communicates with each other.
  • the frame format and Ethernet data field format of CAN network are defined in detail, and the CAN network function module source is realized by address declaration, address success, address failure and address inquiry method.
  • the public network communication method of the in-vehicle electronic processing unit system sets the data type, the function type, the parameter number and the like in the communication data, and also proposes the calculation formula of the source address of the CAN network function module, and realizes the declaration method and response method of the preferred address. And the inquiry method; and the data type, function type, source module number, parameter number and data are also added in the corresponding Ethernet data communication, so that the public network of the in-vehicle electronic processing unit system can be converted into each other in the CAN network and the Ethernet communication.
  • FIG. 1 is a flow chart of a public network communication method of an in-vehicle electronic processing unit system of the present invention.
  • FIG. 2 is a schematic diagram showing the structure of an extended frame of a CAN network of the in-vehicle electronic processing unit system of the present invention.
  • FIG. 3 is a flow chart of obtaining a CAN network source address of the present invention.
  • FIG. 4 is a schematic diagram of data types of the in-vehicle electronic processing unit system of the present invention.
  • FIG. 5 is a schematic diagram showing the function types and module numbers of the in-vehicle electronic processing unit system of the present invention.
  • FIG. 6 is a schematic diagram showing the structure of a function module nominal symbol in the in-vehicle electronic processing unit system of the present invention.
  • FIG. 7 is a schematic structural diagram of a CAN network function module address declaration structure of the in-vehicle electronic processing unit system of the present invention.
  • a public network communication method for an in-vehicle electronic processing unit system includes the following steps: S1.
  • the first function module initiates an instruction to the second function module according to its actual requirement.
  • Request communication first according to the characteristics and requirements of data communication, module function and module type to establish 4-bit data type, 4-bit function type, 8-bit source module number or source address and actual transmission data including multiple data numbers, and according to Ethernet
  • the network data format requires the establishment of a TCP/UDP data field and encapsulation into an Ethernet frame, or a 29-bit identifier ID and an 8-byte data field according to the CAN network format requirements to form a CAN extension frame;
  • the first functional module transmits the Ethernet a network frame or a CAN extension frame;
  • S3 when the Ethernet frame or the CAN extension frame arrives at the second function module, the second function module receives and disassembles the Ethernet frame to obtain a TCP/UDP data field, or receives a CAN extension frame;
  • S4 The second function module analyze
  • the second function module makes a successful response or a failure response according to the analysis result, and thereby establishes a 4-bit data type, a 4-bit function type, an 8-bit source module number or a source address, and a plurality of data numbers including Actually send data, and establish a TCP/UDP data field according to the Ethernet data format requirements and encapsulate it into a response Ethernet frame, and then send a response Ethernet frame; or establish a 29-bit identifier ID and 8-byte data according to the CAN network format requirements.
  • the domain forms a CAN response extension frame, and then sends a CAN response extension frame; S6, if it is a successful response, the second function module also needs to execute a command or a request according to the requirements of the first function module; if the command or the request needs to acquire the second function
  • the data of the module, the second function module also needs to send the required data to the first function module; S7, if it is a failure response, the second function module does not execute the command or request required by the first function module, and returns directly.
  • the method includes the data type, the function type, the module number and the like in the data frame of the communication, and performs detailed division of each function module according to its function characteristics and data characteristics, and uses the communication method to make the communication information include the same format.
  • the content enables the various functional modules of the in-vehicle electronic to obtain corresponding data information, and reserves ample space for the future development of the in-vehicle electronic processing unit system.
  • the 29-bit identifier ID includes 3-bit priority (P), 1-bit reserved bit (R), and 1-bit data page (DP). ), 8-bit PDU format (PF), 8-bit PDU specific domain (PS) and 8-bit source address (SA) are six parts.
  • the 8-bit PDU specific domain is divided into two parts, of which the upper 4 bits are data types and the lower 4 bits are function types.
  • the source address obtaining step includes: S1, the function module sends a usage statement to the CAN network for its preferred address, the source address (SA) of the address declaration frame uses the preferred address, and the address declaration frame is sent by broadcast, Notifying all the functional modules in the CAN network; if the preferred address is not occupied, the preferred address is used as its source address, if the preferred address is occupied, then proceeds to step S2; S2, the in-vehicle electronic processing unit host assigns a function module The address first selects other unoccupied addresses of the same function type.
  • the in-vehicle electronic processing unit host assigns the existing empty address to the function module. If there is no empty address of the same function type, the process proceeds to step S3. S3, the vehicle electronic processing unit host will select the unoccupied address from the entire range as the address of the function module. If the existing address is empty, the in-vehicle electronic processing unit host will assign the existing empty address to the function module, if the entire range is all The addresses are occupied, and the host computer processing unit will give the function module Address failed to send frames.
  • the 4-bit data type can define 16 types of data communication types, and according to the size of the data type value, it is further divided into the highest priority, the high priority, the general priority, and The low priority has four types of priority levels; the four-bit function type can be divided into 16 categories according to the functions of each functional module, and the specific definition is the function type of the in-vehicle electronic processing unit host and various functional modules.
  • an embodiment of the present invention can specifically specify a data communication type according to the nature and use of the actual communication data of the function module, for example, the fault (0000) data type has the highest priority. Since the data type is located at the upper 4 bits of the PS, high-priority data type arbitration will succeed according to the principle of bit-by-bit arbitration in the case of CAN bus access violations. At the same time, the definition of the data type is appropriately reserved for subsequent expansion.
  • the data types are divided into two types, one is to communicate by using a global message, the other is to communicate to a specific destination address, the global type does not need to specify the destination address, and the 1-3 bytes of the data field are parameter numbers or data, and When a specific type needs to indicate the destination address (DA), the first byte of its data field is used as the DA, followed by the parameter number or data.
  • data types include commands, requests, success responses (ACK), and failure responses (NACK).
  • the basic format is the same, the difference is that the definition of the specific data of the data domain is different.
  • a global type of command or request whose response is also a global type, a specific type of command or request, and its response is also of a specific type.
  • an embodiment of the present invention can be divided into 16 categories according to functions of each functional module, and the specific definition is an in-vehicle electronic processing unit host and driving safety, personal safety, vehicle anti-theft, recording equipment, detecting components, and faults. Diagnostics, audio and video equipment, navigation and positioning, network communications, air environment, entertainment equipment, development equipment and reserved function types.
  • the present invention defines a uniform nominal for Ethernet and CAN networks.
  • the nominal length is 8 bytes
  • the nominal symbol includes 1 bit of network type, 1 address of source address, 2 bits reserved, 4 bits of function type, 8 bits of module number, 3 bytes of manufacturer code, identity number 3 bytes.
  • the function module adopts the CAN network interface, the network type is 0, and the function module adopts the Ethernet network interface, and the network type is 1.
  • the nominal length of the CAN network of the in-vehicle electronic processing unit system is 8 bytes
  • the network type is 1 bit
  • the source address is declared 1 bit
  • the function type is 4 bits
  • the module number is 8 bits.
  • the network type is 0, indicating the CAN network.
  • the source address is declared as 0, it indicates that the source address of the function module directly uses the preferred address.
  • the source address is declared as 1, it indicates that the source address of the function module requires an address declaration to be used.
  • the reserved bit should be set. Zero.
  • the manufacturer code and identity number are different from the defined lengths in SAE J1939-81 but have the same meaning.
  • the nominal length of the Ethernet of the in-vehicle electronic processing unit system is 8 bytes
  • the network type is 1 bit
  • the source address is declared 1 bit
  • the function type is 4 bits
  • the module number is 8 bits.
  • manufacturer code 3 bytes identity number 3 bytes.
  • the network type is 1, indicating Ethernet
  • the source address is declared as 0, and the reserved bit should be set to zero.
  • the length is 48 bits, of which the first 24 bits are the code of the network hardware manufacturer, and the last 24 bits are the network products manufactured by the manufacturer ( For example, the serial number of the network card (ie, the product ID number), therefore, the last 48 bits of the function module identifier are the same as their MAC addresses. That is, the nominal character of the Ethernet module of the in-vehicle electronic processing unit system function module can directly utilize the existing MAC address and add the inherent characteristics of the 2-byte function module.
  • CAN network or Ethernet network There must be at least one network interface (CAN network or Ethernet network) for a function module with at least one identifier.
  • the same functional module may extend both the CAN network and the Ethernet interface (such as a gateway), which allows the same functional module to have multiple different nominals, representing different interfaces, and one interface corresponding to an identifier.
  • the function module nominal character is the manufacturer code and the identity number.
  • the CAN network or the Ethernet network must be unique and cannot overlap.
  • gateway 00H
  • WIFI module 01H
  • GSM module Term Evolution
  • 3G module 3G module
  • 4G module 4G module
  • the invention further comprises a 1-3 byte destination address, a parameter number or data in the data field of the Ethernet frame or the CAN extension frame, and the rest is the communication data of the in-vehicle electronic processing unit system.
  • the destination address is 1 byte, and the destination address is not required.
  • the parameter number (1-2 bytes), the parameter number is not required, and its length is 1-2 bytes, and a maximum of 65536 different parameters are allowed. According to the specific data transmission requirements of each function module, different parameter numbers can be selected, and one (or group) parameter corresponds to one number. If the function module has only one (or group) parameter and the meaning is clear, the parameter number can be omitted.
  • For the CAN network parameter number is its data field 1-3 bytes, after the Ethernet parameter number is followed by its 8-bit source module number.
  • the communication process between the vehicle electronic processing unit host and the CAN network ultrasonic parking sensor module is as follows:
  • SA source address
  • the in-vehicle electronic processing unit host sends a success response frame in a broadcast manner, and all functional modules in the CAN network can listen and receive, regardless of whether the source address is empty, the address 01H will be registered, the parking radar module After receiving the address success frame, the address 01H is used as its source address;
  • the in-vehicle electronic processing unit host will select the unoccupied address from the entire range (1-255) as the address of the parking sensor module, assuming that the 9AH address is empty, the in-vehicle electronic processing unit The host assigns the new address 9AH to the parking sensor module and sends the address success frame in broadcast mode. All function modules in the CAN network can listen and receive. Regardless of whether the source address is empty, the address 9AH will be registered, and the parking radar module will be registered. After receiving the address success frame, the address 9AH is used as its source address;
  • the in-vehicle electronic processing unit host will send an address failure frame to the function module to announce all the function modules, and the parking sensor module will stop working after receiving the address failure.
  • the anti-hijacking module can send an address query frame by broadcast, when the parking radar receives the address query frame is an inquiry.
  • the reversing radar broadcasts the address declaration frame to announce all the functional modules in the CAN network.
  • the source address (SA) in the frame is 9AH
  • the data field is the reversing radar nominal.
  • other functional modules including the in-vehicle electronic processing unit host
  • the address declaration frame is received for the function module with the address of 10H. And thereby obtain the content of the nominal character in the address declaration frame data field, thereby determining and identifying the address 9AH as the CAN network parking sensor.
  • SA successful source address
  • ACK response
  • ACK 00H
  • the source address (SA) is 00H
  • the destination address (DA) is 01H
  • the open command is 01H
  • the 29-bit identifier ID and the 8-byte data field are established, and then Sended to the CAN network
  • the parking radar module receives the frame data, it first analyzes the PS high 4 bits for a specific command request (0110), and then analyzes the PS lower 4 bits (0000) for the host or driving safety function type, and then
  • the analysis source address (SA) is 00H, indicating that it is a command sent by the host of the in-vehicle electronic processing unit, and continues to analyze the first byte destination address (DA) of the data field to be 01H, and determines that the command is sent to the parking sensor, and then analyzes
  • the second byte of the data field is 01H, indicating that the command is to enable the reverse radar ranging function.
  • the reversing radar then turns on the reversing radar ranging function and saves the
  • the host of the in-vehicle electronic processing unit When the host of the in-vehicle electronic processing unit receives the frame data, it first analyzes the PS high 4 bits for a specific command request (0110), and then analyzes the lower 4 bits (0000) of the PS. Host or driving safety function type, then analyze the source address (SA) to 01H, indicating the response sent by the parking sensor module. Continue to analyze the first byte destination address (DA) of the data field to 00H, and determine that the response is sent to the vehicle. The electronic processing unit host then analyzes the second byte of the data field to E0H, indicating that the response is a successful response (ACK). At this point, the onboard electronic processing unit host determines that the open command it sent has been received by the parking sensor module.
  • SA source address
  • DA destination address
  • ACK successful response
  • the host electronic processing unit host sends a shutdown command to the ultrasonic parking sensor module and the NACK response communication process of the ultrasonic parking sensor module to the command is similar to the above.
  • the communication process between the vehicle electronic processing unit host and the Ethernet ultrasonic parking sensor module is as follows:
  • the host of the in-vehicle electronic processing unit sends an open command to the parking sensor module, transmits by UDP protocol, and establishes a UDP data field according to the format requirement, the first byte is high 4-bit data type (0101) and low 4-bit function type (0000), second The byte is the source module number 00H, the third byte is the open command 01H, the source port number in the UDP header is the in-vehicle electronic processing unit host port and the destination port number is the parking sensor module port, and finally encapsulated into the Ethernet frame by the sending port.
  • the Ethernet ultrasonic reversing radar receiving port receives the Ethernet frame sent by the host of the in-vehicle electronic processing unit, and the UDP data field is obtained by the reversing radar.
  • the reversing radar first obtains the UDP source port and the destination port and analyzes the UDP.
  • the first byte of the data field, the high 4-bit data type (0101) and the lower 4-bit function type (0000), are known to be commands sent by the host of the in-vehicle electronic processing unit, and then the source module number is 00H and the command is confirmed again.
  • the car's electronic processing unit sent the host, and finally analyzed the third byte is 01H.
  • Reversing radar ranging function command is turned on, and the reversing radar is then opened.
  • Reversing radar ranging function stores the ON state, each subsequent reversing radar ranging and automatic reversing radar vehicle distance data transmission after power.
  • the reversing radar module sends a successful response (ACK) to the in-vehicle electronic processing unit host, and transmits by UDP protocol, and establishes a UDP data field according to the format requirement, the first byte high 4-bit data type (0101) and the lower 4-bit function type (0000)
  • the second byte is the source module number 01H
  • the third byte is the open success response (ACK) is E0H
  • the source port number in the UDP header is the parking sensor module port and the destination port number is the host computer port of the in-vehicle electronic processing unit.
  • the encapsulated Ethernet frame is sent to the Ethernet by the sending port, and the host receiving port of the in-vehicle electronic processing unit receives the Ethernet frame sent by the Ethernet ultrasonic reversing radar, and is detached and assembled by the in-vehicle electronic processing unit to obtain the UDP data field.
  • the host of the electronic processing unit first obtains the UDP source port and the destination port and analyzes the first byte of the UDP data field, the high 4-bit data type (0101) and the lower 4-bit function type (0000), and learns that the response is from the parking sensor module, and then The analysis source module number is 01H and it is confirmed again that the response is sent by the parking sensor module. Finally, the third byte is analyzed as E0H, indicating that the response is a successful response (ACK). At this point, the onboard electronic processing unit host determines that the open command it sent has been received by the parking sensor module.
  • Ultrasonic reversing collects the distance data in real time, and transmits the parking distance data of the reversing radar in real time. It is transmitted by UDP protocol.
  • the UDP data field is established according to the format requirements.
  • the first byte is high 4-bit data type (0100) and low 4-bit function type (0000).
  • the second byte is the source module number 01H, followed by channel A, channel B, channel C and channel D with a total of 4 bytes of distance data.
  • the source port number in the UDP header is the parking sensor module port and the destination port number.
  • the host computer port of the in-vehicle electronic processing unit is finally packaged into an Ethernet frame and sent to the Ethernet by the sending port.
  • the host receiving port of the in-vehicle electronic processing unit receives the Ethernet frame sent by the Ethernet ultrasonic reversing radar, and is disassembled by the host of the in-vehicle electronic processing unit. After obtaining the UDP data field, the host of the in-vehicle electronic processing unit first obtains the UDP source port and the destination port and analyzes the UDP data field first byte high 4-bit data type (0100) and 4-bit function type (0000) to learn that it is a parking sensor module. The distance data sent is then analyzed.
  • the source module number is 01H and the data is again confirmed as real-time data sent by the parking sensor module, and then the value of the last 4 bytes is read 105,1 07,108,110, compare and obtain the minimum value of 105 of 4 channels, and then calculate and restore to the actual distance of 1.05 meters for corresponding processing.
  • the host electronic processing unit host sends a shutdown command to the ultrasonic parking sensor module and the NACK response communication process of the ultrasonic parking sensor module to the command is similar to the above.

Abstract

本发明所述的一种车载电子处理单元系统公共网络通讯方法通过数据类型、功能类型、模块编号将各功能模块按其功能特点和数据特点进行了详细的划分，并为车载电子处理单元系统的未来发展预留了充足的空间。通过提取CAN网络和以太网的共性部分，本专利制定的公共网络通讯方法使得各功能模块的标称符、数据类型、功能类型、模块编号和参数编号等基本结构内容实现了完全统一，相互通信，由此实现车载电子处理单元主机与各功能模块，以及各功能模块之间的数据互用、资源共享，解决了目前市场上的车载电脑系统(或车载电子产品)存在产品杂乱纷呈、互相独立、互不兼容、功能单一、资源不能共享等诸多问题。

Description

一种车载电子处理单元系统公共网络通讯方法 技术领域
本发明涉及一种通讯方法，尤其涉及一种车载电子处理单元系统公共网络通讯方法。
背景技术
SAE J1939是基于德国Bosch公司开发的控制器局域网络(CAN：Controller Area Network)，并由美国汽车工程协会(SAE)推荐用于重型道路车辆上电子部件间的网络通讯标准。它描述了重型车辆现场总线的一种网络应用，包括CAN网络物理层(J1939-11)、数据链路层(J1939-21)、网络层(J1939-31)、应用层(J1939-71)、故障诊断(J1939-73)和网络管理(J1939-81)等协议，其通讯速率可达到250Kbps。SAE J1939在商用车辆、舰船、轨道机车、农业机械和大型发动机中得到了广泛的应用。而以太网技术最初由Xerox公司创建，并被逐步普遍采用的网络技术，它采用电气和电子工程师协会(IEEE)制订的802.3标准，管理各个网络设备在网络总线上传送信息。经过几十年的飞速发展，它已成为世界上应用最广泛、最为常见的网络技术，广泛应用于世界各地的局域网和企业骨干网。并且，为了使以太网具有实时传输的能力，能满足工业现场使用的要求，在现有以太网的基础上进行改进的工业以太网也应运而生，最具代表性的工业以太网有西门子PROFINET，贝加莱POWERLINK，德国Beckhoff公司EtherCAT等，这些工业以太网解决了工业现场的环境、安全和实时性数据通讯的要求。
但是，现有的技术没有一套完整的车载电脑系统网络实现技术，也没有一套完全适合车载电脑系统的网络通讯协议，目前市场上的车载电脑系统(或车载电子产品)存在产品杂乱纷呈、互相独立、互不兼容、功能单一、资源不能共享等诸多问题。车载电子处理单元系统是一种开放式可扩展的车载电脑公共平台，主机只集成了基本硬件功能和操作系统，其他外围车载电子产品(如GPS导航、行车记录、可视倒车、倒车雷达等)作为功能模块挂接在系统扩展的CAN网络或以太网络上，从而组成一个完整的车载电子处理单元系统。有鉴于此，采取一种适合于车载电子处理单元系统的网络通讯方法，通过这种专用的网络通讯方法将车载电子处理单元系统与各扩展功能模块连成一个有机整体从而实现数据互用、资源共享，便是目前亟待解决的问题。
发明内容
为了解决上述技术问题，本发明目的在于提供一种车载电子处理单元系统公共网络通讯方法解决目前车载电子外围功能模块互相独立、互不兼容、资源不能共享的问题。
本发明所述的一种车载电子处理单元系统公共网络通讯方法，包括以下步骤：
S1，第一功能模块根据其实际需求，发起对第二功能模块的命令或请求通讯，先根据数据通讯的特点和要求，模块功能和模块种类建立4位数据类型，4位功能类型，8位源模块编号或源地址以及包括多个数据编号的实际发送数据，并根据以太网数据格式要求建立TCP/UDP数据域并封装成以太网帧，或根据CAN网络格式要求建立29位的标识符ID和8字节数据域，形成CAN扩展帧；
S2，第一功能模块发送以太网帧或CAN扩展帧；
S3，当以太网帧或CAN扩展帧抵达第二功能模块时，由第二功能模块接收并拆装以太网帧得到TCP/UDP数据域，或接收CAN扩展帧；
S4，第二功能模块分析TCP/UDP数据域，或CAN扩展帧，获取4位数据类型，4位功能类型，8位源模块编号或源地址和包括多个数据编号的实际发送数据；
S5，第二功能模块根据分析结果做出成功响应或失败响应，并以此建立4位数据类型，4位功能类型，8位源模块编号或源地址以及包括多个数据编号的实际发送数据，并根据以太网数据格式要求建立TCP/UDP数据域并封装成响应以太网帧，接着发送响应以太网帧；或根据CAN网络格式要求建立29位的标识符ID和8字节数据域，形成CAN响应扩展帧，接着发送CAN响应扩展帧；
S6，如果是成功响应ACK，第二功能模块还需根据第一功能模块的要求执行命令或请求；如果命令或请求中需要获取第二功能模块的数据，第二功能模块还需向第一功能模块发送要求的数据；
S7，如果是失败响应，第二功能模块不执行第一功能模块要求的命令或请求，直接返回。
本发明所述的一种车载电子处理单元系统公共网络通讯方法通过数据类型、功能类型、模块编号将各功能模块按其功能特点和数据特点进行了详细的划分，并为车载电子处理单元系统的未来发展预留了充足的空间。通过提取CAN网络和以太网的共性部分，本专利制定的公共网络通讯方法使得各功能模块的标称符、数据类型、功能类型、模块编号和参数编号等基本结构内容实现了完全统一，相互通信。同时又根据CAN网络和以太网通讯的特点和差异，详细制订了CAN网络的帧格式和以太网数据域格式，并通过地址声明、地址成功、地址失败和地址询问方法实现了CAN网络功能模块源地址的获取和查询。该种车载电子处理单元系统公共网络通讯方法在通信数据中设置数据类型、功能类型、参数编号等部分，还提出了CAN网络功能模块源地址计算公式，并实现了首选地址的声明方法、应答方法以及询问方法；并在相应的以太网数据通讯也增加数据类型、功能类型、源模块编号、参数编 号和数据几部分，使得车载电子处理单元系统公共网络可在CAN网络和以太网络通信中相互转化，适合于车载电子处理单元系统的统一的通讯信息，由此实现车载电子处理单元主机与各功能模块，以及各功能模块之间的数据互用、资源共享，解决了目前市场上的车载电脑系统(或车载电子产品)存在产品杂乱纷呈、互相独立、互不兼容、功能单一、资源不能共享等诸多问题。
附图说明
图1是本发明的车载电子处理单元系统公共网络通讯方法的流程图。
图2是本发明的车载电子处理单元系统CAN网络扩展帧结构示意图。
图3是本发明的CAN网络源地址的获取流程图。
图4是本发明的车载电子处理单元系统数据类型的示意图。
图5是本发明的车载电子处理单元系统功能类型及模块编号示意图。
图6是本发明的车载电子处理单元系统中功能模块标称符结构示意图。
图7是本发明的车载电子处理单元系统CAN网络功能模块地址申明结构示意图。
具体实施方式
根据图1、图2所示，本发明所述的一种车载电子处理单元系统公共网络通讯方法，包括以下步骤：S1，第一功能模块根据其实际需求，发起对第二功能模块的命令或请求通讯，先根据数据通讯的特点和要求，模块功能和模块种类建立4位数据类型，4位功能类型，8位源模块编号或源地址以及包括多个数据编号的实际发送数据，并根据以太网数据格式要求建立TCP/UDP数据域并封装成以太网帧，或根据CAN网络格式要求建立29位的标识符ID和8字节数据域，形成CAN扩展帧；S2，第一功能模块发送以太网帧或CAN扩展帧；S3，当以太网帧或CAN扩展帧抵达第二功能模块时，由第二功能模块接收并拆装以太网帧得到TCP/UDP数据域，或接收CAN扩展帧；S4，第二功能模块分析TCP/UDP数据域，或CAN扩展帧，获取4位数据类型，4位功能类型，8位源模块编号或源地址和包括多个数据编号的实际发送数据；S5，第二功能模块根据分析结果做出成功响应或失败响应，并以此建立4位数据类型，4位功能类型，8位源模块编号或源地址以及包括多个数据编号的实际发送数据，并根据以太网数据格式要求建立TCP/UDP数据域并封装成响应以太网帧，接着发送响应以太网帧；或根据CAN网络格式要求建立29位的标识符ID和8字节数据域，形成CAN响应扩展帧，接着发送CAN响应扩展帧；S6，如果是成功响应，第二功能模块还需根据第一功能模块的要求执行命令或请求；如果命令或请求中需要获取第二功能模块的数据，第二功能模块还需向第一功能模块发送要求的数据；S7，如果是失败响应，第二功能模块不执行 第一功能模块要求的命令或请求，直接返回。该方法通过在通信的数据帧内包含数据类型、功能类型、模块编号等内容，将各功能模块按其功能特点和数据特点进行了详细的划分，使用该种通讯方法使得通讯信息包含同一格式的内容，使得车载电子的各个功能模块都可以获取相应数据信息，并为车载电子处理单元系统的未来发展预留了充足的空间。
如图2所示，车载电子处理单元主机采用CAN网络数据进行通讯时，所述的29位标识符ID包括3位优先级(P)，1位保留位(R)，1位数据页(DP)，8位PDU格式(PF)、8位PDU特定域(PS)和8位源地址(SA)共六部分。在本发明中选定3位优先级(P)，1位保留位(R)，1位数据页(DP)，8位PDU格式(PF)分别为P＝3或6，R＝0，DP＝0，PF＝255。其中8位PDU特定域分成两部分，其中高4位为数据类型，低4位为功能类型。
任何CAN总线功能模块在正常工作前必须先获得成功的源地址(SA)。如图3所示，源地址的获取步骤包括：S1，功能模块对其首选地址向CAN网络发送使用声明，地址声明帧的源地址(SA)使用首选地址，地址声明帧采用广播方式发送，以通告CAN网络中所有的功能模块；如果该首选地址没有被占用，该首选地址作为其源地址使用，如果该首选地址被占用，则进入步骤S2；S2，车载电子处理单元主机给功能模块分配一个地址，首先选用相同功能类型的其他未被占用的地址，如果存在地址为空，车载电子处理单元主机将存在的空地址分配给功能模块，如果不存在相同功能类型的空地址，则进入步骤S3；S3，车载电子处理单元主机将从全部范围中选用未被占用的地址作为功能模块的地址，如存在地址为空，车载电子处理单元主机将存在的空地址分配给功能模块，如果整个范围所有地址均被占用，车载电子处理单元主机将给功能模块发送地址失败帧。
该种车载电子处理单元系统公共网络通讯方法中，所述4位数据类型，可定义16种数据通讯类型，根据数据类型数值的大小，又划分成最高优先级、高优先级、一般优先级和低优先级共四类优先等级；所述4位功能类型，可根据各功能模块的功能不同分成16类，具体定义是车载电子处理单元主机和各种功能模块的功能类型。
如图4所示，本发明的一种实施例可根据功能模块实际通讯数据的性质和用途对数据通讯类型做出了具体规定，如：故障(0000)数据类型优先级最高。由于数据类型位于PS的高4位，在CAN总线访问冲突时根据逐位仲裁的原则，高优先级的数据类型仲裁将获得成功。同时数据类型的定义为后续的扩充做了适当的预留。并且，数据类型分成两种，一种采用全局消息进行通讯，一种是对特定目的地址进行通讯，全局类型不需要指明目的地址，其数据域第1-3字节为参数编号或数据，而对于特定类型需要指明目的地址(DA)时，其数据域第一字节作为DA，其后才是参数编号或数据。对于命令请求(0101和0110)数据类型 包括了命令、请求、成功响应(ACK)和失败响应(NACK)四种。其基本格式相同，区别在于数据域具体数据的定义不同。全局类型的命令或请求，对其响应也为全局类型，特定类型的命令或请求，对其响应也为特定类型。
如图5所示，本发明的一种实施例可根据各功能模块的功能不同分成16类，具体定义是车载电子处理单元主机和行驶安全、人身安全、车辆防盗、记录设备、检测部件、故障诊断、影音设备、导航定位、网络通讯、空气环境、娱乐设备、开发设备和预留功能类型。
如图6所示，为了准确确定车载电子处理单元系统中的各个功能模块，本发明针对以太网和CAN网络定义了统一的标称符。所述标称符长度为8字节，标称符包括网络类型1位，源地址声明1位，预留2位，功能类型4位，模块编号8位，制造商代码3字节，身份编号3字节。本发明中限定功能模块采用CAN网络接口则网络类型为0，功能模块采用以太网络接口则网络类型为1。
对于CAN网络接口的功能模块，车载电子处理单元系统CAN网络的标称符长度为8字节，网络类型1位，源地址声明1位，预留2位，功能类型4位，模块编号8位，制造商代码3字节，身份编号3字节。其中网络类型为0，表示CAN网络，源地址声明为0时，表示功能模块源地址直接使用首选地址，源地址声明为1时，表示功能模块源地址需要地址声明才能使用，预留位应设为零。制造商代码和身份编号与SAE J1939-81中的定义长度不同但其含义相同。
对于以太网络接口的功能模块，车载电子处理单元系统以太网的标称符长度为8字节，网络类型1位，源地址声明1位，预留2位，功能类型4位，模块编号8位，制造商代码3字节，身份编号3字节。其中网络类型为1，表示以太网，源地址声明为0，预留位应设为零。由于以太网网卡的MAC地址由IEEE(电气与电子工程师协会)分配，长度为48位，其中前24位是网络硬件制造商的代码，而后24位为该制造商所制造的某个网络产品(如网卡)的系列号(即产品的身份编号)，因此，功能模块标称符的后48位与其MAC地址相同。也即车载电子处理单元系统功能模块以太网的标称符可直接利用现有的MAC地址，并在其前添加2字节功能模块的固有特性构成。
对于一个功能模块必须至少有一种网络接口(CAN网络或以太网络)，至少有一个标称符。但同一个功能模块可能同时扩展了CAN网络和以太网络接口(如网关)，这样允许同一个功能模块有多个不同的标称符，代表着不同的接口，一个接口对应一个标识符。功能模块标称符其后48位为制造商代码和身份编号，无论是CAN网络还是以太网络各自都必须具有唯一性，不能重叠。
本发明标称符包括模块编号8位，其一种实施方式可如图5所示，其中，功能类型＝0，模块编号＝00H为车载电子处理单元主机(属于特殊的功能模块)专用。如：网络通讯，功能类型＝1000，其模块编号范围为0-255,目前定义了网关(00H)、WIFI模块(01H)、GSM模块(02H)、3G模块(03H)和4G模块(04H)共5种模块编号，其余模块编号为后续功能模块所预留。模块编号长度为8位，它是同类型功能模块的编排序号，即每种功能类型可分配多达256种不同的模块编号，这样车载电子处理单元系统总共可容纳16*256＝4096种不同的功能模块设备。
本发明在以太网帧或CAN扩展帧的数据域中还包括1-3字节目的地址、参数编号或数据，其余部分为车载电子处理单元系统的通讯数据。所述目的地址1字节，目的地址不是必须的。所述参数编号(1-2字节)，参数编号不是必须的，其长度为1-2字节，最多允许有65536种不同参数。根据各功能模块具体数据传送要求，可选用不同的参数编号，一个(或组)参数对应一个编号。如果功能模块只有一个(或组)参数且意义明确，参数编号可以省略。对于CAN网络参数编号为其数据域第1-3字节，对于以太网参数编号紧随其8位源模块编号之后。
以下，以CAN网络超声波倒车雷达和以太网超声波倒车雷达的通讯为一实施例，具体介绍本发明方法。
车载电子处理单元主机与CAN网络超声波倒车雷达模块通讯过程如下：
车载电子处理单元主机采用CAN网络数据进行通讯时，由于任何CAN网络功能模块在正常工作前必须先获得成功的源地址(SA)，即首先确定该功能模块的源地址(SA)。
如图7所示，CAN网络倒车雷达模块上电后由于其源地址为空，首先需要计算其首选地址＝(功能分类*16)异或(模块编号)＝(0*16)异或(01H)＝01H，即倒车雷达模块首选地址为01H，接着倒车雷达模块利用这个首选地址作为源地址(SA)向CAN网络发送地址声明帧，由于地址声明为广播方式发送，CAN网络中的所有功能模块都能监听和接收，车载电子处理单元主机接收倒车雷达模块的地址声明帧后，检查地址01H是否被其他功能模块占用。
如果地址01H没有被占用，车载电子处理单元主机以广播方式发送成功应答帧，CAN网络中的所有功能模块都能监听和接收，无论其源地址是否为空，都将登记地址01H，倒车雷达模块收到地址成功帧后将地址01H作为其源地址使用；
如果地址01H被占用，车载电子处理单元主机就试图给倒车雷达模块分配一个地址，首先选用相同功能类型(0000)的其他未被占用的地址(地址＝(功能分类*16)异或(模块编 号)，由此计算公式可知每种功能类型共可分配16个地址)，假定05H地址为空，车载电子处理单元主机将新地址05H分配给倒车雷达模块，并以广播方式发送成功应答帧，CAN网络中的所有功能模块都能监听和接收，无论其源地址是否为空，都将登记地址05H，倒车雷达模块收到地址成功帧后将地址05H作为其源地址使用；
如果相同功能类型的16个地址全部被占用，车载电子处理单元主机将从整个范围(1-255)中选用未被占用的地址作为倒车雷达模块的地址，假定9AH地址为空，车载电子处理单元主机将新地址9AH分配给倒车雷达模块，并以广播方式发送地址成功帧，CAN网络中的所有功能模块都能监听和接收，无论其源地址是否为空，都将登记地址9AH，倒车雷达模块收到地址成功帧后将地址9AH作为其源地址使用；
如果整个范围(1-255)所有地址均被占用，车载电子处理单元主机将给功能模块发送地址失败帧，通告所有功能模块，倒车雷达模块收到地址失败后将停止工作。
当某个功能模块(如防劫持模块地址10H)监听到一个处于正常使用状态下不可识别的地址9AH时，防劫持模块可通过广播方式发送地址询问帧，当倒车雷达接收到地址询问帧是询问自己时，倒车雷达采用广播方式发送地址声明帧以通告CAN网络中所有功能模块，其帧中的源地址(SA)为9AH，数据域为倒车雷达标称符。此时对于CAN网络中其他的功能模块(包括车载电子处理单元主机)先监听，再分析得知此地址声明帧是对地址询问的应答而丢弃，而对于地址为10H的功能模块接收地址声明帧，并由此获得地址声明帧数据域中标称符内容，从而确定并识别地址9AH为CAN网络倒车雷达。
当CAN网络倒车雷达模块获得成功的源地址(如：SA＝01H)后，才能进入正常使用工作状态，车载电子处理单元主机(SA＝00H)可向倒车雷达模块发送控制命令，倒车雷达模块也可向车载电子处理单元主机发送响应(ACK)和倒车雷达模块车距数据，从而实现数据通讯。具体通讯过程如下：
车载电子处理单元主机向倒车雷达模块发送开启命令，使用CAN2.0B扩展帧格式，其中P＝3，R＝0，DP＝0，PF＝FFH，同时，开启命令采用特定命令请求(0110)发送，其功能类型为0000，PS＝60H，源地址(SA)为00H，目的地址(DA)为01H，开启命令为01H，并以此建立29位的标识符ID和8字节数据域，然后发送至CAN网络中，当倒车雷达模块接收到该帧数据后，先分析PS高4位为特定命令请求(0110)，接着分析PS的低4位(0000)为主机或行驶安全功能类型，接着分析源地址(SA)为00H，表明是车载电子处理单元主机发来的命令，继续分析数据域第一字节目的地址(DA)为01H，确定该命令是发给倒车雷达的，接着再分析数据域第二字节为01H，表明该命令是要求开启倒车雷达测距 功能。倒车雷达随即开启倒车雷达测距功能，并保存开启状态，以后倒车雷达每次上电后自动测距并发送倒车雷达车距数据。
随后倒车雷达模块向车载电子处理单元主机发送成功响应(ACK)，使用CAN2.0B扩展帧格式，其中P＝3，R＝0，DP＝0，PF＝FFH，同时，ACK采用特定命令请求(0110)发送，其功能类型为0000，PS＝60H，源地址(SA)为01H，目的地址(DA)为00H，成功响应(ACK)为E0H，并以此建立29位的标识符ID和8字节数据域，然后发送至CAN网络中，当车载电子处理单元主机接收到该帧数据后，先分析PS高4位为特定命令请求(0110)，接着分析PS的低4位(0000)为主机或行驶安全功能类型，接着分析源地址(SA)为01H，表明是倒车雷达模块发来的响应，继续分析数据域第一字节目的地址(DA)为00H，确定该响应是发给车载电子处理单元主机的，接着再分析数据域第二字节为E0H，表明该响应是成功响应(ACK)。至此车载电子处理单元主机确定其发送的开启命令已被倒车雷达模块接收。
超声波倒车实时采集车距数据，并实时发送倒车雷达车距数据，使用CAN2.0B扩展帧格式，其中P＝3，R＝0，DP＝0，PF＝FFH，同时，车距数据采用实时数据(0100)发送，其功能类型为0000，PS＝40H，源地址(SA)为01H，数据域为通道A,通道B，通道C和通道D共4字节距离数据。并以此建立29位的标识符ID和8字节数据域，然后发送至CAN网络中，当车载电子处理单元主机接收到该帧数据后，先分析PS高4位为实时数据(0100)，接着分析PS的低4位(0000)为主机或行驶安全功能类型，接着分析源地址(SA)为01H，表明是倒车雷达模块发来的实时数据，然后读取数据域前4字节的值105,107,108,110，比较并获取4个通道的最小值105，再计算还原成实际距离1.05米用以做相应处理。
车载电子处理单元主机向超声波倒车雷达模块发送关闭命令和超声波倒车雷达模块对命令的NACK响应通讯过程与以上相类似。
车载电子处理单元主机与以太网超声波倒车雷达模块通讯过程如下：
车载电子处理单元主机向倒车雷达模块发送开启命令，采用UDP协议传送，按格式要求建立UDP数据域，第一字节高4位数据类型(0101)和低4位功能类型(0000)，第二字节为源模块编号00H，第三字节为开启命令01H，UDP头中的源端口号为车载电子处理单元主机端口和目的端口号为倒车雷达模块端口，最后封装成以太网帧由发送端口发送到以太网中，以太网超声波倒车雷达接收端口接收到车载电子处理单元主机发送的以太网帧，由倒车雷达拆装后得到UDP数据域，倒车雷达先获得UDP源端口和目的端口并分析UDP数据域第一 字节高4位数据类型(0101)和低4位功能类型(0000)得知是车载电子处理单元主机发给自己的命令，接着分析源模块编号为00H并再次确认此命令是车载电子处理单元主机发出的，最后分析第三字节为01H，得知是开启倒车雷达测距功能命令，倒车雷达随即开启倒车雷达测距功能，并保存开启状态，以后倒车雷达每次上电后自动测距并发送倒车雷达车距数据。
随后倒车雷达模块向车载电子处理单元主机发送成功响应(ACK)，采用UDP协议传送，按格式要求建立UDP数据域，第一字节高4位数据类型(0101)和低4位功能类型(0000)，第二字节为源模块编号01H，第三字节为开启成功响应(ACK)为E0H，UDP头中的源端口号为倒车雷达模块端口和目的端口号为车载电子处理单元主机端口，最后封装成以太网帧由发送端口发送到以太网中，车载电子处理单元主机接收端口接收到以太网超声波倒车雷达发送的以太网帧，由车载电子处理单元主机拆装后得到UDP数据域，车载电子处理单元主机先获得UDP源端口和目的端口并分析UDP数据域第一字节高4位数据类型(0101)和低4位功能类型(0000)得知是倒车雷达模块发来的响应，接着分析源模块编号为01H并再次确认此响应是倒车雷达模块发出的，最后分析第三字节为E0H，表明该响应是成功响应(ACK)。至此车载电子处理单元主机确定其发送的开启命令已被倒车雷达模块接收。
超声波倒车实时采集车距数据，并实时发送倒车雷达车距数据，采用UDP协议传送，按格式要求建立UDP数据域，第一字节高4位数据类型(0100)和低4位功能类型(0000)，第二字节为源模块编号01H，其后为通道A,通道B，通道C和通道D共4字节距离数据，UDP头中的源端口号为倒车雷达模块端口和目的端口号为车载电子处理单元主机端口，最后封装成以太网帧由发送端口发送到以太网中，车载电子处理单元主机接收端口接收到以太网超声波倒车雷达发送的以太网帧，由车载电子处理单元主机拆装后得到UDP数据域，车载电子处理单元主机先获得UDP源端口和目的端口并分析UDP数据域第一字节高4位数据类型(0100)和4位功能类型(0000)得知是倒车雷达模块发来的车距数据，接着分析源模块编号为01H并再次确认此数据是倒车雷达模块发来的实时数据，然后读取其后4字节的值105,107,108,110，比较并获取4个通道的最小值105，再计算还原成实际距离1.05米用以做相应处理。
车载电子处理单元主机向超声波倒车雷达模块发送关闭命令和超声波倒车雷达模块对命令的NACK响应通讯过程与以上相类似。

Claims (8)

  1. 一种车载电子处理单元系统公共网络通讯方法，其特征在，包括以下步骤：
    S1，第一功能模块根据其实际需求，发起对第二功能模块的命令或请求通讯，先根据数据通讯的特点和要求，模块功能和模块种类建立4位数据类型，4位功能类型，8位源模块编号或源地址以及包括多个数据编号的实际发送数据，并根据以太网数据格式要求建立TCP/UDP数据域并封装成以太网帧，或根据CAN网络格式要求建立29位的标识符ID和8字节数据域，形成CAN扩展帧；
    S2，第一功能模块发送以太网帧或CAN扩展帧；
    S3，当以太网帧或CAN扩展帧抵达第二功能模块时，由第二功能模块接收并拆装以太网帧得到TCP/UDP数据域，或接收CAN扩展帧；
    S4，第二功能模块分析TCP/UDP数据域，或CAN扩展帧，获取4位数据类型，4位功能类型，8位源模块编号或源地址和包括多个数据编号的实际发送数据；
    S5，第二功能模块根据分析结果做出成功响应或失败响应，并以此建立4位数据类型，4位功能类型，8位源模块编号或源地址以及包括多个数据编号的实际发送数据，并根据以太网数据格式要求建立TCP/UDP数据域并封装成响应以太网帧，接着发送响应以太网帧；或根据CAN网络格式要求建立29位的标识符ID和8字节数据域，形成CAN响应扩展帧，接着发送CAN响应扩展帧；
    S6，如果是成功响应，第二功能模块还需根据第一功能模块的要求执行命令或请求；如果命令或请求中需要获取第二功能模块的数据，第二功能模块还需向第一功能模块发送要求的数据；
    S7，如果是失败响应，第二功能模块不执行第一功能模块要求的命令或请求，直接返回。
  2. 根据权利要求1所述的一种车载电子处理单元系统公共网络通讯方法，其特征在于，所述CAN网络采用SAE J1939扩展帧格式，即包括3位优先级，1位保留位，1位数据页，8位PDU格式、8位PDU特定域、8位源地址和8字节数据域。
  3. 根据权利要求2所述的一种车载电子处理单元系统公共网络通讯方法，其特征在于，所述8位PDU特定域分成两部分，其中高4位为数据类型，低4位为功能类型。
  4. 根据权利要求1-3任一项所述的一种车载电子处理单元系统公共网络通讯方法，其特征在于，所述源地址的获取步骤包括：
    S1，功能模块对其首选地址向CAN网络发送使用声明，地址声明帧的源地址使用首选地址，地址声明帧采用广播方式发送，以通告CAN网络中所有的功能模块；如果该首选地址没有被占用，该首选地址作为其源地址使用，如果该首选地址被占用，则进入步骤S2；
    S2，车载电子处理单元主机给功能模块分配一个地址，首先选用相同功能类型的其他未被占用的地址，如果存在地址为空，车载电子处理单元主机将存在的空地址分配给功能模块，如果不存在相同功能类型的空地址，则进入步骤S3；
    S3，车载电子处理单元主机将从全部范围中选用未被占用的地址作为功能模块的地址，如存在地址为空，车载电子处理单元主机将存在的空地址分配给功能模块，如果整个范围所有地址均被占用，车载电子处理单元主机将给功能模块发送地址失败帧。
  5. 根据权利要求1-3任一项所述的一种车载电子处理单元系统公共网络通讯方法，其特征在于，所述4位数据类型，可定义16种数据通讯类型，根据数据类型数值的大小，又划分成最高优先级、高优先级、一般优先级和低优先级共四类优先等级；所述4位功能类型，可根据各功能模块的功能不同分成16类，具体定义是车载电子处理单元主机和各种功能模块的功能类型。
  6. 根据权利要求1-3任一项所述的一种车载电子处理单元系统公共网络通讯方法，其特征在于，所述标称符包括网络类型1位，源地址声明1位，预留2位，功能类型4位，模块编号8位，制造商代码3字节，身份编号3字节。
  7. 根据权利要求6所述的一种车载电子处理单元系统公共网络通讯方法，其特征在于，功能模块采用CAN网络接口则网络类型为0，功能模块采用以太网络接口则网络类型为1。
  8. 根据权利要求1-3任一项所述的一种车载电子处理单元系统公共网络通讯方法，其特征在于，所述数据域包括1-3字节目的地址、参数编号或数据，其余部分为车载电子处理单元系统的通讯数据。
PCT/CN2018/083344 2017-04-26 2018-04-17 一种车载电子处理单元系统公共网络通讯方法 WO2018196655A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710280263.6 2017-04-26
CN201710280263.6A CN107094109B (zh) 2017-04-26 2017-04-26 一种车载电子处理单元系统公共网络通讯方法

Publications (1)

Publication Number Publication Date
WO2018196655A1 true WO2018196655A1 (zh) 2018-11-01

Family

ID=59637080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/083344 WO2018196655A1 (zh) 2017-04-26 2018-04-17 一种车载电子处理单元系统公共网络通讯方法

Country Status (2)

Country Link
CN (1) CN107094109B (zh)
WO (1) WO2018196655A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110989416A (zh) * 2019-08-26 2020-04-10 西南交通大学 一种基于实时以太网总线的整车控制系统
CN113359680A (zh) * 2021-06-28 2021-09-07 潍柴动力股份有限公司 一种数据采集方法及车载终端
CN115550311A (zh) * 2022-11-28 2022-12-30 永联智慧能源科技(常熟)有限公司 基于can通讯的地址自识别方法、装置、介质及电子设备

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107094109B (zh) * 2017-04-26 2020-07-07 广州睿嵌电子技术有限公司 一种车载电子处理单元系统公共网络通讯方法
JP6935273B2 (ja) * 2017-08-30 2021-09-15 矢崎総業株式会社 有線無線複合通信システム及び有線無線複合通信方法
CN109995892B (zh) * 2019-03-29 2021-09-07 中铁二院工程集团有限责任公司 一种多通信系统兼容性编号方法
KR20200136751A (ko) * 2019-05-28 2020-12-08 현대자동차주식회사 차량 진단 통신 장치, 그를 포함한 시스템 및 그 방법
CN110381173A (zh) * 2019-06-26 2019-10-25 惠州市德赛西威智能交通技术研究院有限公司 一种车载雷达动态分配ip地址的方法
JP2021175096A (ja) * 2020-04-27 2021-11-01 株式会社ミツトヨ ネットワーク装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101417636A (zh) * 2008-03-14 2009-04-29 北京理工大学 基于三路can总线的纯电动客车通信系统和方法
CN103780697A (zh) * 2014-01-23 2014-05-07 广州睿嵌电子技术有限公司 车载电子处理单元公共平台系统及其数据通讯方法
US20140126584A1 (en) * 2012-11-06 2014-05-08 Electronics And Telecommunications Research Institute Frame conversion apparatus for converting controller area network frame into ethernet frame and frame conversion method thereof
CN104852893A (zh) * 2014-02-13 2015-08-19 现代自动车株式会社 用于以太网和can通讯之间信号转换的车载设备及其控制方法
CN107094109A (zh) * 2017-04-26 2017-08-25 广州睿嵌电子技术有限公司 一种车载电子处理单元系统公共网络通讯方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101977094B (zh) * 2010-10-18 2012-09-26 航天东方红卫星有限公司 一种适于多主通信的星载can总线通信方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101417636A (zh) * 2008-03-14 2009-04-29 北京理工大学 基于三路can总线的纯电动客车通信系统和方法
US20140126584A1 (en) * 2012-11-06 2014-05-08 Electronics And Telecommunications Research Institute Frame conversion apparatus for converting controller area network frame into ethernet frame and frame conversion method thereof
CN103780697A (zh) * 2014-01-23 2014-05-07 广州睿嵌电子技术有限公司 车载电子处理单元公共平台系统及其数据通讯方法
CN104852893A (zh) * 2014-02-13 2015-08-19 现代自动车株式会社 用于以太网和can通讯之间信号转换的车载设备及其控制方法
CN107094109A (zh) * 2017-04-26 2017-08-25 广州睿嵌电子技术有限公司 一种车载电子处理单元系统公共网络通讯方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110989416A (zh) * 2019-08-26 2020-04-10 西南交通大学 一种基于实时以太网总线的整车控制系统
CN110989416B (zh) * 2019-08-26 2023-06-20 西南交通大学 一种基于实时以太网总线的整车控制系统
CN113359680A (zh) * 2021-06-28 2021-09-07 潍柴动力股份有限公司 一种数据采集方法及车载终端
CN113359680B (zh) * 2021-06-28 2023-05-23 潍柴动力股份有限公司 一种数据采集方法及车载终端
CN115550311A (zh) * 2022-11-28 2022-12-30 永联智慧能源科技(常熟)有限公司 基于can通讯的地址自识别方法、装置、介质及电子设备
CN115550311B (zh) * 2022-11-28 2023-03-10 永联智慧能源科技(常熟)有限公司 基于can通讯的地址自识别方法、装置、介质及电子设备

Also Published As

Publication number Publication date
CN107094109B (zh) 2020-07-07
CN107094109A (zh) 2017-08-25

Similar Documents

Publication Publication Date Title
WO2018196655A1 (zh) 一种车载电子处理单元系统公共网络通讯方法
CN109491357B (zh) 在多个控制器上执行诊断操作的设备以及相关方法和车辆
CN107707418B (zh) 一种通信诊断系统以及通信诊断刷新方法
CN108303964B (zh) 一种网络连接器及车辆诊断方法
EP3125579B1 (en) Intelligent bluetooth® beacon i/o expansion system
US9813525B2 (en) In-vehicle apparatus for signal conversion between ethernet and CAN communication and control method thereof
CN110083088B (zh) 信号控制转换装置以及信号控制转换方法
CN106878124A (zh) 用于控制车辆内大容量诊断通信的方法和车辆控制器
CN105388858A (zh) 网络中通信节点的操作方法
US9026711B2 (en) Motor vehicle control system with simplified information exchange
JP2005529531A (ja) 車両に関するテレマティークサービスのための方法および装置
US20090070488A1 (en) Data Communication Method
Tuohy et al. Next generation wired intra-vehicle networks, a review
KR20140076692A (ko) 차량 진단 게이트웨이 장치 및 이를 포함하는 시스템
US20190296937A1 (en) Central Data Store in Vehicle Electrical System
CN205890794U (zh) 一种分布式电动汽车车载网络终端平台
Hbaieb et al. In-car gateway architecture for intra and inter-vehicular networks
EP2869538A1 (en) Communication bridge between bus networks
CN109660436B (zh) 一种双can通道数据处理方法、网关设备及系统
CN112965463B (zh) 远程诊断系统及远程诊断方法
CN206096835U (zh) 非独占式汽车通信系统
CN102710479B (zh) 用于通信协议逆向解析的汽车网关系统
US20230013950A1 (en) Data acquisition device for mobile devices, method for conducting a preliminary analysis in a data acquisition device, a vehicle, and computer program configured accordingly
Manoj et al. Automotive Networks: A Review
Jiansen et al. The application of SAE j1939 protocol in automobile smart and integrated control system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18790396

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18790396

Country of ref document: EP

Kind code of ref document: A1