CN112019440B - CAN bus multicast method based on identifier multiplexing - Google Patents

CAN bus multicast method based on identifier multiplexing Download PDF

Info

Publication number
CN112019440B
CN112019440B CN202010733700.7A CN202010733700A CN112019440B CN 112019440 B CN112019440 B CN 112019440B CN 202010733700 A CN202010733700 A CN 202010733700A CN 112019440 B CN112019440 B CN 112019440B
Authority
CN
China
Prior art keywords
multicast
code
address
node
bus
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN202010733700.7A
Other languages
Chinese (zh)
Other versions
CN112019440A (en
Inventor
刘松
施亮
张源潮
卜文俊
李正民
徐伟
尹礼航
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Naval University of Engineering PLA
Original Assignee
Naval University of Engineering PLA
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 Naval University of Engineering PLA filed Critical Naval University of Engineering PLA
Priority to CN202010733700.7A priority Critical patent/CN112019440B/en
Publication of CN112019440A publication Critical patent/CN112019440A/en
Application granted granted Critical
Publication of CN112019440B publication Critical patent/CN112019440B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • 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/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Abstract

The invention discloses a CAN bus multicast method based on identifier multiplexing, which is characterized in that the lengths of multicast codes and address codes are determined according to actual requirements at the initial stage of network establishment; a multicast sender generates a multicast code and an address code corresponding to the multicast code according to multicast needs to form an identifier, and the multicast sender sends a data packet containing the multicast code and the address code to a CAN bus; after a node on the CAN bus receives a data packet by monitoring the CAN bus, a multicast code and an address code are separated by analyzing an identifier, the node receiving the data packet uses the own address code to calculate with the multicast code in the data packet, the calculation result is compared with the address code of the data packet, and if the calculation result is the same as the address code of the data packet, the node is a multicast receiver. The system is compatible with the existing CAN bus protocol standard, and the existing hardware structure does not need to be changed; and multicast data acquisition and group control mechanisms are provided, and the bus bandwidth utilization rate is effectively improved.

Description

CAN bus multicast method based on identifier multiplexing
Technical Field
The invention relates to the technical field of industrial field CAN (controller Area network) bus transmission price, in particular to a CAN bus multicast method based on identifier multiplexing.
Background
The CAN bus is an international standardized serial communication protocol, has the advantages of strong real-time performance, long transmission distance, strong anti-electromagnetic interference capability, low cost and the like, and is widely applied to the fields of automatic control, aerospace, robots, numerical control machines, medical instruments, sensors and the like. Compared with other field buses, the CAN has the following characteristics: by adopting a multi-master competition type bus structure, free communication can be realized among all communication nodes on the bus, and the communication is not limited to the communication between a master station and a slave station; the system has a priority arbitration function, and when a plurality of nodes initiate communication simultaneously, the avoidance priority with low priority is high, so that the communication congestion phenomenon is reduced; the communication distance can reach 10Km at the farthest, and the transmission rate can be selected from a plurality of transmission rates of 5 Kbps-1 Mbps, so that the method can be suitable for short-distance transmission of large data volume and long-distance transmission of small data volume; and the node has a function of automatically exiting the bus in the case of serious errors.
The CAN bus standard is mainly divided into two parts, CAN 2.0A and CAN 2.0B. CAN 2.0A is part a of the CAN protocol, which defines an identification area of 11 bits. And CAN 2.0B is an extension of the CAN protocol, defines a 29bit identification area, and is otherwise the same as CAN 2.0A. The CAN standard defines a three-layer protocol specification in accordance with the ISO/OSI model, including a physical layer, a transport layer, and an object layer. The physical layer defines the electrical characteristics of signal transmission and ensures the consistency of bus signal transmission; the transmission layer mainly defines how the CAN node judges that the bus is in an idle state, when the bus transmits a frame, when the frame starts to receive the frame, bus arbitration and other functions; the object layer defines the functions of message filtering, message processing and the like and provides an interface for the application layer. However, the CAN bus standard does not provide the specification of the network layer and application layer protocols, and the transmission frame in the CAN bus does not contain a source address or a destination address, and only uses an identifier to indicate function information and priority information.
In order to fill the blank of CAN bus standard on network layer and network layer, the non-profit organization CiA (CAN in Automation) drafts and plans CANopen protocol, which realizes the protocol above network layer (including network layer) in OSI seven-layer protocol model, including addressing scheme, multiple communication sub-protocol and its application layer. The underlying CANopen device and communication sub-protocol is defined in CiA301, and the different device sub-protocols are extensions on the CiA301 basis, such as CiA402 for motion control. The CANopen device model defines a Communication Object (Communication Object), an Object Dictionary (Object Dictionary), and an Application Object (Application Object). The communication object defines the functions of network management, data transmission and the like, the application layer object defines the function module interacting with the environment, and the object dictionary is the mapping table between the application layer object and the communication object.
When data transmission is performed, CANopen uses a communication identifier (COB-ID) to distinguish communication objects, and divides the identifier into two parts: function codes and node addresses. The function code (4bits) is used for distinguishing the application layer load type, and the load type can be a network management object, a process transmission object or a service transmission object and the like; the node address (7bits) can be used to distinguish up to 127 slave nodes. In CiA301, a function code that predefines a communication destination such as network management, synchronization, and time stamp has a broadcast function, but a multicast function is not defined. In addition, the CANopen device needs to be provided with an object dictionary, the sending end maps the data of the application object into the communication object through the object dictionary, and the receiving end converts the data of the application object into the data needed by the communication object through searching the object dictionary.
However, in a data exchange scenario in the CAN bus, it is often necessary to periodically collect data of a certain type of sensor or control the same set of actuators. At this time, the use of unicast point-to-point mode will cause unnecessary waste of limited bandwidth of the bus, and the use of multicast mode can effectively improve the bandwidth utilization rate. Therefore, it is necessary to design an efficient CAN bus multicast method, which CAN further improve the transmission efficiency of the CAN bus.
Disclosure of Invention
The invention aims to provide a CAN bus multicast method based on identifier multiplexing with high transmission efficiency aiming at the defects of the prior art.
In order to achieve the above object, the CAN bus multicast method based on identifier multiplexing designed by the present invention specifically includes:
1) determining the lengths of the multicast code and the address code according to actual requirements at the initial stage of establishing the network;
2) a multicast sender generates a multicast code and an address code corresponding to the multicast code to form an identifier according to multicast needs, and then the multicast sender sends a data packet containing the multicast code and the address code to a CAN bus;
3) after a node on the CAN bus receives a data packet by monitoring the CAN bus, the node on the CAN bus separates a multicast code and an address code by analyzing an identifier, then the node receiving the data packet operates the address code of the node and the multicast code in the data packet, and compares the operation result with the address code of the data packet, if the operation result is the same as the address code of the data packet, the node is a multicast receiver and further analyzes the data content of the data packet; otherwise, the node is judged to be a non-multicast receiver, and the node discards the data packet.
Further, in step 3), the operation performed between the address code of each node and the multicast code of the data packet specifically includes: and performing logic AND operation on m bits behind the address code of each node, wherein the m bits are the length of the multicast code.
Further, in the step 3), if the priority of the unicast mode is higher than the priority of the multicast mode, the logical and operation is performed on the multicast code of the data packet after bitwise negation and the m bits after the multicast code of the data packet are operated.
Further, in step 1), the method for calculating the lengths of the address code and the multicast code is as follows:
11) recording the number of nodes in the network as N, expressing N as a binary string to obtain the length of the string
Figure BDA0002604240860000031
If only the most significant bit of the N converted binary number string is' 1
Figure BDA0002604240860000032
12) Dividing nodes into M large classes in the network, the multicast code exists between the internal members of the M large classes, expressing M as binary string, and obtaining the length of the string
Figure BDA0002604240860000033
Similarly, if M translates a binary string with only the most significant bit of '1', then
Figure BDA0002604240860000034
13) If 2x-y>11，The length n of the address code is equal to x, and the length m of the multicast code is equal to 11-n; otherwise, the address code length
Figure BDA0002604240860000035
The multicast code length m is 11-n, and the number 11 is the frame identifier length in the CAN network.
Further, after the step 13) determines the length n of the address code and the length m of the multicast code, the node address represented in the network is 2nDivide the node into 2n-mA large class, each of which uses multicast codes of 2mThe groups perform multicast transmission.
Further, the multicast code specifically generating step is:
1) recording a node address set of a data packet to be multicast-transmitted as A, and recording a multicast code set to be selected as B; initializing B as an empty set, wherein the number of nodes in A is K, and the number of bits of '0' in an ideal target multicast code is as follows:
Figure BDA0002604240860000041
taking 2 as a base, solving the logarithm of K, and rounding downwards;
2) adding a multicast code containing L bit '0' into the set B, and if L is 0, the set B is an empty set;
3) if the set B is an empty set, skipping to the step 5), otherwise, selecting a multicast code in the set B and performing logical AND operation on m bits after each address code in the set A, recording the multicast code as B if the operation result is a set C, and deleting the multicast code from the set B;
4) if the set C contains 2LIf the address codes c are the same, adding the records (b, c) with the multicast code b and the address code c into the set R; deleting all addresses which can generate the address code c with the multicast code b from the set A, and jumping to the step 1); if the number of the same address codes in the set C is less than 2LJumping to step 3);
5) jump to step 6) if L is 0, otherwise, it means that the element in set B cannot contain 2 after being accessed onceLMulticast codes with the same address code need to be multicast in a smaller range, and step 2 is skipped to by making L equal to L-1);
6) and sending the multicast data packets according to the record in the set R, and if the set A is not empty, sending the data packets to the nodes in the set A one by one in a unicast mode.
Compared with the prior art, the invention has the following advantages: 1) the system is compatible with the existing CAN bus protocol standard, and the existing hardware structure does not need to be changed; 2) a multicast data acquisition and group control mechanism is provided, and the bus bandwidth utilization rate is effectively improved; 3) each node is not required to record the information of the multicast group, so that the method is convenient to popularize and apply; 4) the multicast code can be flexibly adjusted, and the size of the packet can be changed according to the actual packet requirement; 5) the multicast priority is controllable, and the multicast priority can be controlled by changing the operation mode of the multicast code and the address code.
Drawings
FIG. 1 is a diagram of a frame format for identifier multiplexing in the present invention;
fig. 2 is a schematic diagram illustrating multicast code generation in a multicast sender according to the present invention;
fig. 3 is a schematic diagram illustrating multicast code analysis in a multicast receiver according to the present invention.
Detailed Description
The invention is described in further detail below with reference to the figures and the specific embodiments.
The CAN bus multicast method based on identifier multiplexing divides identifiers into two parts by utilizing the characteristic that CAN bus identifiers CAN be customized, one part is used as a multicast code and is used for dividing nodes into different groups, the other part is used as an address code and is used for identifying the addresses of different nodes, and the purpose of multicast is realized by the cooperation of the multicast code and the address code.
To illustrate the inventive content of the present invention, a few terms used in the present invention are introduced:
multicast code: the binary number string used for indicating the address packet is operated with the address code to obtain the multicast address, which is similar to the mask in the IP network.
Address code: refers to a binary string used for representing the address of a node, and a CAN identifier is multiplexed together with a multicast code, namely the multicast code and the address code have the binary bit length of 11 bits (29 bits in an extension frame), and the purpose of the CAN identifier is similar to that of the address in an IP network.
The multicast sender: refers to a communication node, typically a master station in a CAN communication network, that needs to send a data packet to all members of a multicast group.
Multicast receiver: refers to a group member of a multicast group that CAN receive and parse multicast packets from multicast senders, typically a slave in a CAN communication network.
Fig. 1 is a diagram of a frame format for CAN bus identifier multiplexing. The 11-bit identifier is divided into a multicast code and an address code, and the meaning of other positions of the frame structure is unchanged. Wherein, the multicast code is m bits, and the address code is n bits. In the invention, the multicast code is placed in front of the address code, and the address code can also be placed in front of the address code in the practical implementation process, and the main difference is that the priority of the whole data packet is different when the multicast code is placed at different positions. In addition, the operation mode used by the invention is that the multicast code and the m bits after the node address code are subjected to logic AND operation, and the first n-m bits of the node address code represent the type information of the node.
The CAN bus multicast method based on identifier multiplexing specifically comprises the following steps:
1) determining the lengths of the multicast code and the address code according to actual requirements at the initial stage of establishing the network;
2) the multicast sender generates a multicast code according to multicast needs and an address code corresponding to the multicast code constitutes an identifier. Then, the multicast sending direction CAN bus sends a data packet containing the multicast code and the address code;
3) after the nodes on the CAN bus receive the data packets by monitoring the CAN bus, the nodes on the CAN bus separate the multicast code and the address code by analyzing the identifier. Then, the node receiving the data packet operates its own address code with the multicast code of the data packet, and compares the operation result with the address code of the data packet. If the operation result is the same as the address code in the data packet, the node is a multicast receiver and can further analyze the data content of the data packet; otherwise, the node is judged to be a non-multicast receiver, and the data packet needs to be discarded.
The operation of the address code of each node and the multicast code of the data packet is specifically as follows: and performing logic AND operation on m bits behind the address code of each node, wherein the m bits are the length of the multicast code. For example: the multicast code and the address code of the data packet are binary strings '0 b 1100' and '0 b 0011100', the node address code is '0 b 0011111', the logical and operation result of the multicast code and the node address code is '0 b 0011100', the operation result is the same as the address code of the data packet, the node is judged to be a multicast receiver, otherwise, the node is judged to be a non-multicast receiver.
In addition, it is considered that the higher the CAN bus packet identifier is, the lower the priority is, the unicast priority is made lower than the multicast priority (the unicast multicast code is "0 b 1111") by using a logical and operation method. If the priority of unicast is higher than the priority of multicast, the operation mode can be changed into that the multicast code of the data packet is firstly inverted bit by bit and then is logically AND-operated with the last m bits of the node address code.
The calculation of the lengths of the multicast code and the address code needs to consider two factors: the number of nodes in the network and the requirements for multicasting packets. In order to satisfy the data transmission of the unicast mode preferentially, the number of addresses which can be expressed by the address code is more than the number of nodes in the network; the packet requirement determines the length of the multicast code. When the total length of the multicast code and the address code is larger than 11 bits (29 bits in the extended frame), the address code length requirement is preferably met. The method for calculating the lengths of the address code and the multicast code comprises the following steps:
1) recording the number of nodes in the network as N, expressing N as a binary string to obtain the length of the string
Figure BDA0002604240860000061
If only the most significant bit of the N converted binary number string is' 1
Figure BDA0002604240860000062
For example, when the number of nodes is 32, the binary string is represented as '0 b 100000', and x is 5.
2) Nodes are divided into M large classes in the network, multicast codes exist among internal members of the M large classes, and M is expressed as binary stringTo obtain the length of the string
Figure BDA0002604240860000071
Similarly, if M translates a binary string with only the most significant bit of '1', then
Figure BDA0002604240860000072
3) If 2x-y>11, the address code length n is x, and the multicast code length m is 11-n; otherwise, the address code length
Figure BDA0002604240860000073
(rounded up when there is a decimal point) and the multicast code length m is 11-n, note that here the number 11 is the length of the frame identifier in the CAN network, and the number 11 CAN be replaced with 29 in the extension frame.
After the address code length n and the multicast code length m are determined, the following results can be obtained: the node address represented in the network is 2nDivide the node into 2n-mA large class, each of which uses multicast codes of 2mThe groups perform multicast transmission.
Multicast code and address code generation method. When a multicast sender needs to send a data packet to a group of nodes, the nodes need to be firstly divided into several large classes, and the class information can be determined according to the first (n-m) bits of the node address. And then, calculating and generating a multicast code according to the node address of each large-class internal data packet to be sent. When generating multicast codes, the address range covered by the multicast codes is not larger than the address set of the nodes to be sent, if part of the nodes can not be effectively covered by the multicast codes, the data packets are sent to the nodes in a unicast mode. The multicast code is generated specifically by the following steps:
1) recording a node address set of a data packet to be multicast-transmitted as A, and recording a multicast code set to be selected as B; initializing B as an empty set, wherein the number of nodes in A is K, and the bit number of '0' in an ideal target multicast code is as follows:
Figure BDA0002604240860000074
(base 2, logarithm of K is solved, and rounding is performed downwards);
2) adding a multicast code containing L bit '0' into the set B, and if L is 0, the set B is an empty set;
3) if the set B is an empty set, skipping to the step 5), otherwise, selecting a multicast code in the set B and performing logical AND operation on m bits after each address code in the set A, recording the multicast code as B if the operation result is a set C, and deleting the multicast code from the set B;
4) if the set C contains 2LIf the address codes c are the same, adding the records (b, c) with the multicast code b and the address code c into the set R; deleting all addresses which can generate the address code c with the multicast code b from the set A, and jumping to the step 1); if the number of the same address codes in the set C is less than 2LJumping to step 3);
5) jump to step 6) if L is 0, otherwise, it means that the element in set B cannot contain 2 after being accessed onceLMulticast codes with the same address code need to be multicast in a smaller range, and step 2 is skipped to by making L equal to L-1);
6) and sending the multicast data packets according to the record in the set R, and if the set A is not empty, sending the data packets to the nodes in the set A one by one in a unicast mode.
Note that since one multicast code may not contain the node addresses of all the packets to be sent, several multicast codes and corresponding address codes are generated. In addition, some nodes may not be multicast-transmitted together with other nodes, and these nodes may transmit using a unicast scheme.
Fig. 2 shows a process of generating a multicast code in a multicast sender. Firstly, according to the node address set A of the data packet to be multicast-sent, the bit number L of '0' in the multicast code and the multicast code set B to be selected are obtained through calculation. And then, if the B is not an empty set, evaluating whether available multicast codes exist in the multicast code set B to be selected, adding the available multicast codes and the calculated address codes into the set R together, deleting the related address from the A, and skipping the program again to perform corresponding calculation. And if the B is an empty set, judging whether to reduce the multicast space according to the length of the L. If L >0, B is regenerated and an evaluation is started as to whether there is a multicast code available. Otherwise, if L is 0, it indicates that the multicast code cannot be regenerated. In this case, on the one hand, multicast transmission of packets is performed according to the record in the set R, and on the other hand, the remaining node addresses in a are transmitted using unicast.
For example, if the node address of the packet to be multicast-transmitted is set a ═ 0b0010001,0b0010101,0b0010111,0b0011101,0b0011111}, and there are 5 nodes in total, then the node address of the packet to be multicast-transmitted is set b0010001,0b0010101,0b0010111,0b0011101,0b0011111}, and the total number of the nodes is 5
Figure BDA0002604240860000081
The set of multicast codes to be selected B is {0B0101,0B1100,0B1001,0B0011 }. One multicast code B in B is selected to be 0B0101, and the operation result with the elements in the set a is C ═ {0B0010001,0B0010101,0B0010101,0B0010101,0B0010101}, including 4 × 2LThe same result, c ═ 0b 0010101. Thus, adding (b, c) to set R: r { (0b0101,0b0010101) } and deletes the address in a that can be generated with b to c, at which time a {0b0010001 }. And skipping the program, recalculating L to obtain L which is 0, wherein B is an empty set and indicates that no available multicast code exists, and at the moment, performing multicast transmission according to the record in R and transmitting the rest node addresses in A in a unicast mode.
Fig. 3 shows a process of analyzing a multicast code in a multicast receiver. When the nodes on the CAN bus receive the data packet, the multicast code b and the address code c of the data packet are analyzed according to the lengths of the multicast code and the address code (which are consistent with those of a multicast sender). Then, the local address and the multicast code are used for operation, and the operation result is r. If the address code c is the same as the operation result r, the node is a multicast receiver, and the related content in the data packet can be further analyzed; otherwise, the packet is discarded.
Continuing with the example used in fig. 2, the multicast code and address code resolved by the nodes on the CAN bus are: 0b0101,0b 0010101. When a node 1 (with the address of 0b 0010010010011) receives a data packet, the node address and the multicast code are subjected to logical operation, and the result r is 0b0010001, which is different from the address code, so that the data packet is discarded; when the node 2 (address 0b0010111) receives the data packet, it performs a logical operation on the multicast code and the node point, and as a result, r is 0b0010101, which is the same as the address code, the content of the data packet can be further analyzed.

Claims (4)

1. A CAN bus multicast method based on identifier multiplexing is characterized in that: the method specifically comprises the following steps:
1) determining the lengths of the multicast code and the address code according to actual requirements at the initial stage of establishing the network; the method for calculating the lengths of the address code and the multicast code comprises the following steps:
11) recording the number of nodes in the network as N, expressing N as a binary string to obtain the length of the string
Figure FDA0003582461040000011
If only the most significant bit of the N converted binary number string is' 1
Figure FDA0003582461040000012
12) Dividing nodes into M large classes in the network, the multicast code exists between the internal members of the M large classes, expressing M as binary string, and obtaining the length of the string
Figure FDA0003582461040000013
Similarly, if M translates a binary string with only the most significant bit of '1', then
Figure FDA0003582461040000014
13) If 2x-y>11, the address code length n is x, and the multicast code length m is 11-n; otherwise, the address code length
Figure FDA0003582461040000015
The multicast code length m is 11-n, and the number 11 is the length of the frame identifier in the CAN network;
2) a multicast sender generates a multicast code and an address code corresponding to the multicast code to form an identifier according to multicast needs, and then the multicast sender sends a data packet containing the multicast code and the address code to a CAN bus; the multicast code is specifically generated by the following steps:
1) recording a node address set of a data packet to be multicast-transmitted as A, and recording a multicast code set to be selected as B; initializing B as an empty set, wherein the number of nodes in A is K, and the number of bits of '0' in an ideal target multicast code is as follows:
Figure FDA0003582461040000016
taking 2 as a base, solving the logarithm of K, and rounding downwards;
2) adding a multicast code containing L bit '0' into the set B, and if L is 0, the set B is an empty set;
3) if the set B is an empty set, skipping to the step 5), otherwise, selecting a multicast code in the set B and performing logical AND operation on m bits after each address code in the set A, recording the multicast code as B if the operation result is a set C, and deleting the multicast code from the set B;
4) if the set C contains 2LIf the address codes c are the same, adding the records (b, c) with the multicast code b and the address code c into the set R; deleting all addresses which can generate the address code c with the multicast code b from the set A, and jumping to the step 1); if the number of the same address codes in the set C is less than 2LJumping to step 3);
5) jump to step 6) if L is 0, otherwise, it means that the element in set B cannot contain 2 after being accessed onceLMulticast codes with the same address code need to be multicast in a smaller range, and step 2 is skipped to by making L equal to L-1);
6) sending multicast data packets according to records in the set R, and if the set A is not empty, sending the data packets to nodes in the set A one by one in a unicast mode;
3) after a node on the CAN bus receives a data packet by monitoring the CAN bus, the node on the CAN bus separates a multicast code and an address code by analyzing an identifier, then the node receiving the data packet operates the address code of the node and the multicast code of the data packet, and compares the operation result with the address code of the data packet, if the operation result is the same as the address code of the data packet, the node is a multicast receiver; otherwise, the node is judged to be a non-multicast receiver.
2. The CAN bus multicast method based on identifier multiplexing according to claim 1, wherein: in the step 3), the operation of the address code of each node and the multicast code of the data packet specifically comprises: and performing logic AND operation on the multicast code and m bits behind the address code of each node, wherein the m bits are the length of the multicast code.
3. The CAN bus multicast method based on identifier multiplexing according to claim 1, wherein: in the step 3), if the priority of the unicast mode is higher than that of the multicast mode, the multicast code of the data packet is first inverted bit by bit during operation, and then logical and operation is performed with the last m bits of the node address code.
4. The CAN bus multicast method based on identifier multiplexing according to claim 1, wherein: said step 13) determining the address code length n and the multicast code length m, the node address expressed in the network is 2nDivide the node into 2n-mA large class, each of which uses multicast codes of 2mThe groups perform multicast transmission.
CN202010733700.7A 2020-07-27 2020-07-27 CAN bus multicast method based on identifier multiplexing Active CN112019440B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010733700.7A CN112019440B (en) 2020-07-27 2020-07-27 CAN bus multicast method based on identifier multiplexing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010733700.7A CN112019440B (en) 2020-07-27 2020-07-27 CAN bus multicast method based on identifier multiplexing

Publications (2)

Publication Number Publication Date
CN112019440A CN112019440A (en) 2020-12-01
CN112019440B true CN112019440B (en) 2022-05-20

Family

ID=73499892

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010733700.7A Active CN112019440B (en) 2020-07-27 2020-07-27 CAN bus multicast method based on identifier multiplexing

Country Status (1)

Country Link
CN (1) CN112019440B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113067760A (en) * 2021-03-10 2021-07-02 深圳市智莱科技股份有限公司 Communication method, system, equipment and storage medium of power transformation cabinet
CN114448744B (en) * 2022-01-28 2024-05-03 航天科工火箭技术有限公司 CAN data analysis method, device, equipment and medium for multiplexing identification numbers
CN115174304B (en) * 2022-06-24 2023-12-22 南京国电南自维美德自动化有限公司 CAN bus communication method with sectional self-definition identifier

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102377632A (en) * 2010-08-06 2012-03-14 北京乾唐视联网络科技有限公司 Method and system compatible with Ethernet
CN102427567A (en) * 2011-12-13 2012-04-25 东南大学 Asynchronous multi-wavelength mesh network adaptive node system based on optical packet switching
CN106160800A (en) * 2016-06-22 2016-11-23 邦彦技术股份有限公司 Data transmission method and device
CN110460522A (en) * 2018-05-08 2019-11-15 华为技术有限公司 Multicast data transmission method, relevant apparatus and system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7116640B2 (en) * 2000-12-22 2006-10-03 Mitchell Paul Tasman Architecture and mechanism for forwarding layer interfacing for networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102377632A (en) * 2010-08-06 2012-03-14 北京乾唐视联网络科技有限公司 Method and system compatible with Ethernet
CN102427567A (en) * 2011-12-13 2012-04-25 东南大学 Asynchronous multi-wavelength mesh network adaptive node system based on optical packet switching
CN106160800A (en) * 2016-06-22 2016-11-23 邦彦技术股份有限公司 Data transmission method and device
CN110460522A (en) * 2018-05-08 2019-11-15 华为技术有限公司 Multicast data transmission method, relevant apparatus and system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CAN总线技术应用中的有关问题探讨;王志兵;《工业控制计算机》;20090825(第08期);全文 *

Also Published As

Publication number Publication date
CN112019440A (en) 2020-12-01

Similar Documents

Publication Publication Date Title
CN112019440B (en) CAN bus multicast method based on identifier multiplexing
CN106850466B (en) Method and device for forwarding data packet in time-triggered network
US11146420B2 (en) Method for transmitting data via a serial communication bus, bus interface, and computer program
CN102480462B (en) Universal protocol adapting method and device
EP3384637B1 (en) Systems and methods for implementing a switched controller area network
DE102017121049A1 (en) A communication method based on a vehicle safety integrity level in the vehicle network, and apparatus for the same
WO2020150872A1 (en) Ethernet and controller area network protocol interconversion for in-vehicle networks
CN100553199C (en) Method of realizing group broadcasting, system and equipment based on the PCIE switching network
CN112104538B (en) DDS middleware communication method based on CAN bus data transmission
CN1543149A (en) Flow control in a network environment
US11940943B2 (en) Low complexity ethernet node (LEN) one port
CN110166857B (en) Method for realizing dynamic configuration of fiber channel switch
CN111587560B (en) Master-slave bus system and method for operating a bus system
CN113328870B (en) Multi-node parallel working method of multi-protocol hybrid network
CN109408424A (en) A kind of SpaceFibre bus data acquisition method based on PCIe interface
KR20140021304A (en) Communication system and real time data transmission method
CN115766860A (en) Data transmission method, TSN node and computer readable storage medium
CN114338269B (en) Data transmission method, device, broadband field bus equipment, system and medium
KR20110035247A (en) Method for id transformation in can-based network
KR20070117264A (en) Flexray-can gateway structure and message mapping method
CN106713142B (en) Method for transmitting IP message on CAN bus and IP local area network constructed by CAN bus network
CN113141415B (en) Remote driving system and method for vehicle, electronic device and storage medium
KR101573549B1 (en) Data transmission system and method for transmitting data between different type protocols
US9571355B2 (en) Network
CN114785396B (en) Logic port configuration, lookup mapping and traffic management method, system and terminal

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant