Control method of protocol conversion device, protocol conversion device and storage medium

Abstract

The invention discloses a control method of a protocol conversion device, the protocol conversion device and a storage medium, and relates to the technical field of telecommunication, and the control method of the protocol conversion device comprises the following steps: taking a message sent by first equipment and an equipment address of the first equipment as a first field; the first equipment corresponds to a first protocol; packaging into a message payload based on the first field and a second field, wherein the second field is used for identifying a target device for processing the message payload; and packaging the message payload and the type field into a target message, and sending the target message to a protocol bus corresponding to a second protocol. The technical problems that new and old system protocols are incompatible, a data intercommunication barrier is formed, and industrial data full-process collection is hindered are solved, and the technical effect that a new AutBus protocol conversion device can be smoothly compatible with old Can equipment is achieved.

Description

Technical Field

[0001] The present application relates to the field of electrical communication technology, and in particular to a control method for a protocol conversion device, a protocol conversion device, and a storage medium. Background Art

[0002] In the field of industrial automation, the CAN (Controller Area Network) protocol has long been a core technology for device interconnection, supporting communication between sensors, actuators, and other devices due to its high reliability and low cost. With the advancement of localization of industrial protocols, newer, independent protocols are gradually replacing traditional foreign protocols. However, incompatibility between old and new system protocols creates barriers to data interoperability and hinders the full collection of industrial data. Summary of the Invention

[0003] The main purpose of this application is to provide a control method for a protocol conversion device, a protocol conversion device and a storage medium, aiming to solve the technical problem of incompatibility between new and old system protocols, forming data intercommunication barriers, and hindering the full-process collection of industrial data.

[0004] To achieve the above-mentioned object, the present application provides a control method for a protocol conversion device, the control method for the protocol conversion device comprising:

[0005] According to the message sent by the first device and the device address of the first device as the first field, the first device corresponds to the first protocol;

[0006] encapsulating the first field and the second field into a message payload, wherein the second field is used to identify a target device for processing the message payload;

[0007] The target message is encapsulated according to the message payload and the type field, and the target message is sent to a protocol bus, where the protocol bus corresponds to a second protocol.

[0008] In one embodiment, the step of using the message sent by the first device and the device address of the first device as the first field includes:

[0009] Determine the number of messages corresponding to the message;

[0010] Determine the message length according to the number of messages and the message message;

[0011] The device address, the message length, the number of messages and the message message are used as the first field.

[0012] In one embodiment, the step of encapsulating the first field and the second field into a message payload includes:

[0013] Using the node identifier of the target device as the second field;

[0014] encapsulating the second field and the first field into the message payload;

[0015] The step of encapsulating the target message according to the message payload and type field includes:

[0016] Setting the type field to a first reserved field;

[0017] The target message is encapsulated according to the message payload and the first reserved field.

[0018] In one embodiment, the step of encapsulating the first field and the second field into a message payload includes:

[0019] The first subtype and the multicast identifier of the protocol conversion device are used as the second field;

[0020] The message payload is encapsulated based on the second field and the first field.

[0021] In one embodiment, before the step of using the first subtype and the multicast identifier of the protocol conversion device as the second field, the method includes:

[0022] encapsulate into a request message according to the device address of the first device being connected, the device identifier of the protocol conversion device, and the second subtype;

[0023] Sending the request message to the control node so that the control node returns an allocation message;

[0024] The multicast identifier is determined based on the received allocation message.

[0025] In one embodiment, after the step of determining the multicast identifier based on the received allocation message, the following steps are included:

[0026] assembling a response message according to the third subtype, the multicast identifier, and the device identifier;

[0027] The response message is sent to the control node.

[0028] In one embodiment, the step of encapsulating the target message according to the message payload and type field includes:

[0029] Setting the type field to a second reserved field;

[0030] The target message is encapsulated according to the message payload and the second reserved field.

[0031] In one embodiment, the control method of the protocol conversion device further includes:

[0032] Determining a target multicast identifier of the target message according to the target message received by the protocol conversion device;

[0033] If the target multicast identifier is the same as the multicast identifier of the protocol conversion device, extracting the message in the target message;

[0034] Forward the message to the first device for processing.

[0035] In addition, to achieve the above-mentioned purpose, the present application also provides a protocol conversion device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the control method of the protocol conversion device as described above.

[0036] In addition, to achieve the above-mentioned purpose, the present application also provides a storage medium, which is a computer-readable storage medium, and the computer-readable storage medium stores a program for implementing the control method of the protocol conversion device, and the program for implementing the control method of the protocol conversion device is executed by the processor to implement the steps of the control method of the protocol conversion device as described above.

[0037] The present application provides a control method for a protocol conversion device. The present application uses a message sent by a first device and the device address of the first device as a first field, wherein the first device corresponds to a first protocol; encapsulates the message into a message payload based on the first field and the second field, wherein the second field is used to identify a target device for processing the message payload; encapsulates the message into a target message based on the message payload and the type field, and sends the target message to a protocol bus, wherein the protocol bus corresponds to a second protocol. The present application solves the technical problem that the incompatibility between the old and new system protocols forms a barrier to data intercommunication and hinders the full-process collection of industrial data, and achieves the technical effect that the new AutBus protocol conversion device can smoothly be compatible with the old Can device. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0039] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0040] Figure 1 A flowchart of a control method for a protocol conversion device according to an embodiment of the present invention is provided;

[0041] Figure 2 This is a schematic diagram of a CAN device connected to an AutBus bus through an AutBus protocol conversion device in Example 1 of the control method of the protocol conversion device of the present application;

[0042] Figure 3 This is an example diagram of the target message in the third embodiment of the control method of the protocol conversion device of this application;

[0043] Figure 4 This is a schematic diagram of message changes in the third embodiment of the control method for the protocol conversion device of this application;

[0044] Figure 5 This is a schematic diagram of request interaction involved in the fourth embodiment of the control method of the protocol conversion device of the present application;

[0045] Figure 6 This is an example diagram of a target message in a multicast mode in the sixth embodiment of the control method of the protocol conversion device of the present application;

[0046] Figure 7 This is a schematic diagram of message changes in Example 6 of the control method for the protocol conversion device of the present application;

[0047] Figure 8 This is a schematic diagram of message discard in Example 6 of the control method for the protocol conversion device of this application;

[0048] Figure 9 Schematic diagram of the hardware structure of the protocol conversion device in the embodiment of the present application.

[0049] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0050] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0051] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0052] Currently, in the field of industrial automation, the CAN protocol, due to its high reliability and low cost, has long been a core technology for device interconnection, supporting communication between sensors, actuators, and other devices. With the advancement of localization of industrial protocols, new, independent protocols are gradually replacing traditional foreign protocols. However, incompatibility between old and new system protocols creates barriers to data interoperability and hinders the full collection of industrial data.

[0053] The main solution of this application is: based on the message sent by the first device and the device address of the first device as the first field, the first device corresponds to the first protocol; based on the first field and the second field, it is encapsulated into a message payload, and the second field is used to identify the target device that processes the message payload; based on the message payload and the type field, it is encapsulated into a target message, and the target message is sent to the protocol bus, and the protocol bus corresponds to the second protocol. The new AutBus protocol conversion device achieves the technical effect of smooth compatibility with old Can devices.

[0054] It should be noted that the execution subject of this embodiment may be an AutBus bus network, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or a protocol conversion device capable of implementing the above functions, etc. This embodiment does not specifically limit this. The following uses the protocol conversion device as an example to illustrate this embodiment and the following embodiments.

[0055] Based on this, the present application proposes a control method for a protocol conversion device. Figure 1 , the control method of the protocol conversion device includes steps S10 to S30:

[0056] Step S10: According to the message sent by the first device and the device address of the first device as the first field, the first device corresponds to the first protocol.

[0057] In this embodiment, the first device is a device that complies with the first protocol (i.e., the CAN protocol), such as sensors and actuators in industry. The message is the data generated and intended to be transmitted by the first device, such as temperature, pressure, and other data collected by the sensor. The device address is the unique number of the first device in the first protocol network. Figure 2 , Figure 2 Schematic diagram of a CAN device connected to the autbus bus via an AutBus protocol conversion device. The protocol conversion device in this embodiment is Figure 2 AutBus converter in.

[0058] As an optional embodiment, the protocol conversion device is provided with a dedicated receiving interface connected to the first device. When the first device sends a message, the receiving interface receives the message. Simultaneously, the protocol conversion device obtains the device address of the first device from its stored device information or through a specific configuration operation, and combines the message and the device address to form the first field.

[0059] Step S20: Encapsulate into a message payload based on the first field and the second field, where the second field is used to identify a target device for processing the message payload.

[0060] In this embodiment, the second field is identification information used to clarify which device will process the message payload. The message payload is the part containing the actual data to be transmitted.

[0061] As an optional implementation, the protocol conversion device arranges the first field and the pre-configured (by system preset, user input, etc.) second field in sequence and encapsulates them into a message payload according to a pre-set data structure in its internal storage area.

[0062] Step S30: encapsulate the target message into a target message according to the message payload and type field, and send the target message to a protocol bus corresponding to a second protocol.

[0063] In this embodiment, the type field is the TYPE field of the AutBus bus protocol, which is used to distinguish message types, such as normal data messages and control messages. The target message is a complete message encapsulated according to the second protocol format and can be accurately transmitted on the protocol bus. The protocol bus is a communication line that complies with the second protocol and is used to connect devices that support the second protocol.

[0064] As an optional embodiment, the protocol conversion device combines the message payload and the type field determined based on the actual situation of the message according to the message encapsulation rules specified by the second protocol to generate a target message. The target message is then transmitted to the protocol bus via a transmission interface connected to the protocol bus by the protocol conversion device.

[0065] For example, on an automated production line, there are multiple CAN sensors acting as the first device. These sensors collect dimensional data of products on the line in real time and transmit messages. A protocol converter receives these messages and the corresponding sensor device addresses through a receiving interface, forming the first field. A control room computer on the production line serves as the target device, with its unique identifier serving as the second field. The protocol converter encapsulates the first and second fields into a message payload, determines the value of the type field, encapsulates the message payload and type field into a target message, and transmits the message via the protocol bus to the autbus bus.

[0066] This embodiment effectively resolves the incompatibility issue between the first and second protocols by establishing a complete process from data collection and format conversion on the first device to transmission on the protocol bus corresponding to the second protocol. This breaks down the data interoperability barriers between the old and new protocols, enabling the smooth flow of industrial production data between devices with different protocols. This effectively promotes the full-process collection of industrial data and provides support for the adoption of domestically produced, independent protocols and the intelligent development of industrial automation systems.

[0067] Based on any of the above embodiments, in the second embodiment of the present application, step S10 includes:

[0068] Step S11, determining the number of messages corresponding to the message.

[0069] In this embodiment, the number of messages refers to the number of independent messages contained in the message sent by the first device. For example, if the message sent by the first device is a collection of data collected by multiple different sensors, the data from each sensor can be considered an independent message, and the number of messages is the number of sensors. As an optional embodiment, the protocol conversion device determines the number of messages by parsing the specific format of the message. For example, if the message is divided into different messages according to fixed delimiters, the protocol conversion device counts the number of delimiters plus one to obtain the number of messages.

[0070] Step S12: determining the message length according to the number of messages and the message content.

[0071] In this embodiment, the message length refers to the number of bytes occupied by the message during storage or transmission, which is related to the number of messages and the specific content of each message.

[0072] As an optional implementation, the protocol conversion device estimates the message length based on the average byte length of each message and the number of messages, or accurately calculates the byte length of each message and accumulates the byte length to obtain the message length.

[0073] As an optional implementation, the protocol conversion device first determines the byte length of each message, accumulates the byte lengths of all messages, and adds the number of bytes occupied by the messages themselves to obtain the message length.

[0074] Step S13: Use the device address, the message length, the number of messages, and the message message as the first field.

[0075] In this embodiment, the device address is used to uniquely identify the first device, the message length can help the receiver accurately receive and parse the message, and the number of messages can assist in understanding the composition of the message.

[0076] As an optional implementation, the protocol conversion device combines this information into the first field in a specific order (eg, device address first, message length, number of messages, and finally message information).

[0077] For example, in an automated logistics workshop, the first device is a plurality of CAN sensors distributed on different transport tracks, which are used to monitor the transport speed of goods. Each sensor periodically sends a CAN message containing the cargo transport speed data. After receiving these CAN message messages, the protocol conversion device first counts the number of CAN messages (ENTRY_NUM). Assuming that a total of 8 sensors have sent messages, ENTRY_NUM is 8. The message length (LENGTH) is then determined based on the byte length of each transport speed data and ENTRY_NUM. Next, the device address of the sensor (SRC_CANID), the calculated message length (LENGTH), the number of CAN messages (ENTRY_NUM) and the complete CAN message message (CAN_ENTRY) are combined into the first field.

[0078] This embodiment provides more accurate and detailed data for subsequent message encapsulation and transmission by clarifying the relevant information of the CAN message and combining it into the first field, which helps to improve the accuracy and reliability of the protocol conversion process and ensure that the CAN message of the first device can be correctly transmitted and processed on the second protocol bus.

[0079] Based on any of the above embodiments, in the third embodiment of the present application, step S20 includes:

[0080] Step S21: Use the node identifier of the target device as the second field.

[0081] In this embodiment, the target device can be either a standard AutBus-compliant device or a CAN device connected to the AutBus bus via a protocol converter. The node identifier uniquely identifies the target device within the AutBus network, enabling precise delivery of the message payload to the target device. Alternatively, the protocol converter can obtain the target device's node identifier from a preconfigured device information database or by initiating a query request to a device management server on the network.

[0082] Step S22: encapsulate the second field and the first field into the message payload.

[0083] In this embodiment, the first field contains information about the first device (which complies with the CAN protocol), such as SRC_CANID, LENGTH, ENTRY_NUM, and CAN_ENTRY. The second field, Dst_NodeID, specifies the identity of the target device. These fields are encapsulated together to form a message payload, facilitating transmission across the AutBus network. As an optional implementation, the protocol conversion device places the second field in a specific location according to a specific data structure and format, and then combines it with the first field to form a complete message payload.

[0084] Furthermore, the step of encapsulating the target message according to the message payload and type field includes:

[0085] Step S31: Set the type field to the first reserved field.

[0086] In this embodiment, the type field is the TYPE field of the AutBus bus protocol, which is used to indicate the type of the message. The first reserved field is a specific value pre-reserved in the protocol and is used to identify this special message after protocol conversion. For example, in one example, the first reserved field can be 0x00 or 0. As an optional embodiment, the protocol conversion device sets the value of the type field to the first reserved field according to a preset rule.

[0087] Step S32: encapsulate the target message according to the message payload and the first reserved field.

[0088] In this embodiment, the target message is a complete message that complies with the AutBus protocol format and can be transmitted on the AutBus bus. The message payload and the set first reserved field are encapsulated according to the requirements of the AutBus protocol to form the target message.

[0089] As an optional implementation, the protocol conversion device adds the first reserved field to a specific position of the message payload, such as the message header, and then fills and verifies it according to the format specified by the protocol to generate the final target message.

[0090] Reference Figure 3 , Figure 3The following diagram shows an example of a target message. The target message includes a TYPE field, a Fragment no field, a LENGTH field, a PAYLOAD field, and a CRC field. The TYPE field is used to identify the message type. In protocol conversion scenarios, it can distinguish between different types of messages, such as normal data messages and control messages, or mark specific multicast message types in multicast communications. As mentioned earlier, specific values such as the first reserved field and the second reserved field may be used to represent different types of messages. The Fragment no field is also known as the "fragment number" field. When a message is large in size, it may need to be split into multiple fragments for transmission. This field is used to identify the number of each fragment, allowing the receiver to reassemble the fragments into a complete message based on these numbers. The LENGTH field is also known as the "length" field. It indicates the length of the message, typically including the total number of bytes in the message payload and other necessary fields. This field allows the receiver to determine how much data to receive, ensuring complete and accurate message reception. PAYLOAD (Payload) field: also known as the "Payload" field. It is the part of the message that carries the actual data. During the protocol conversion process, it includes relevant information obtained from the first device (such as the first field) and information used to identify the target device (such as the second field). CRC field: is the "Cyclic Redundancy Check" field. It is used to detect whether there are any errors in the message during transmission. The sender will calculate a CRC value based on the content of the message and add it to the message. After receiving the message, the receiver will recalculate the CRC value and compare it with the CRC field in the message. If the two are inconsistent, it means that there may be an error in the message during transmission.

[0091] Reference Figure 4 , Figure 4 An example of message changes is shown. The AutBus protocol converter is powered on and started; when a Can device is connected to the AutBus protocol converter, the AutBus protocol converter is marked as a converter bound to the Can device; when the Can device sends a Can message, the AutBus protocol converter receives the Can message with TYPE set to 0x00 and the CAN source ID set to the node ID sending the Can message. The Can message is then encapsulated into the payload and sent to the AutBus bus. When the AutBus protocol converter receives the AutBus message encapsulating the Can message, if the AutBus protocol converter is marked as a Can device, indicating that the AutBus protocol converter is connected to the Can device and is operating normally, the Can message in the AutBus message is extracted and forwarded to the Can device for processing; otherwise, the message is discarded.

[0092] For example, in an automated workshop for automobile manufacturing, the first device is a plurality of CAN protocol torque sensors, which are responsible for collecting torque data during the assembly process of automobile parts and sending CAN messages. After receiving these data, the protocol conversion device generates the first field according to the previous steps. The target device is another group of CAN protocol display devices connected to the AutBus bus through the protocol conversion device, which are used to display torque data in real time. The protocol conversion device obtains the node identifiers of these display devices as the second field, and encapsulates the second field and the first field into a message payload. Then, the type field is set to the first reserved field 0x00, and the message payload and the first reserved field are encapsulated into a target message, which is sent to these display devices via the AutBus bus so that the operator can see the torque data in real time.

[0093] Furthermore, when the AutBus protocol conversion device receives the AutBus target message encapsulating the Can message, if the protocol conversion device is marked as a Can device, indicating that the protocol conversion device is connected to the Can device and is operating normally, the Can message in the AutBus target message is extracted and forwarded to the Can device for processing; otherwise, the message is discarded. The response message process of the Can device is similar to that in the above embodiment and will not be repeated here.

[0094] This embodiment achieves message conversion from the CAN protocol to the AutBus protocol by accurately setting the second field and the type field and performing corresponding encapsulation operations, allowing device data that complies with the CAN protocol to be smoothly transmitted on the AutBus bus. Even if the target device is also a CAN device, accurate data interaction can be achieved, breaking the data interoperability barriers between different protocols and improving the compatibility and efficiency of data transmission in industrial automation systems.

[0095] Based on any of the above embodiments, in the fourth embodiment of the present application, step S20 includes:

[0096] Step S23: The first subtype and the multicast identifier of the protocol conversion device are used as the second field.

[0097] In this embodiment, the first subtype is a field used to mark the message type in the target message sent by the protocol conversion device to the AutBus bus. This is achieved by extending the SUB_TYPE field of the PAYLOAD (message payload) field. It is used to identify the type of message exchange between the control node (CN) and the AutBus protocol conversion device. The multicast identifier of the protocol conversion device is a unique identifier of the device in AutBus multicast communications. When the first subtype is 4, it indicates that this is a multicast message transmission message.

[0098] As an optional implementation, when a multicast message needs to be sent, the protocol conversion device sets the value of the first subtype to 4 according to a preset rule, obtains the multicast identifier from the information stored in itself, and combines the two pieces of information to form a second field.

[0099] For example, the first subtype is 4: a multicast message sending message, the second subtype is 1: a multicast identifier request message, the third subtype is 3: a multicast identifier response message, and the fourth subtype is 2: a multicast identifier allocation message.

[0100] Furthermore, the values of the first subtype, the second subtype, the third subtype, and the fourth subtype are not specifically limited.

[0101] Step S24: encapsulate the second field and the first field into the message payload.

[0102] In this embodiment, the first field contains information about the first device (compliant with the CAN protocol), such as SRC_CANID, LENGTH, ENTRY_NUM, and CAN_ENTRY. The second field is combined with the first field according to a specific data structure and format to form a complete message payload for transmission on the AutBus bus. As an optional embodiment, the protocol conversion device places the first field first according to a predefined encapsulation order, and then adds the second field to a specific position to complete the encapsulation of the message payload.

[0103] The following example illustrates the multicast identifier interaction process: Multiple CAN-based sensors and actuators serve as first devices, connected to the AutBus via multiple protocol conversion devices. The control node (CN) manages and schedules the entire bus system. When a protocol conversion device needs to send a multicast message to a group of target devices, multicast identifier interaction occurs.

[0104] Reference Figure 5, the protocol conversion device is powered on and enabled, and the CAN device is connected to the AutBus protocol conversion device to perform CAN registration. The protocol conversion device sends a request message MC_NodeID_REQ (the second subtype is 1) for the multicast identifier to the control node (CN) to request the allocation of the multicast identifier. After receiving the request, the control node (CN) will send an allocation message MC_NodeID_ASSIGN (the fourth subtype is 2) for the multicast identifier to the protocol conversion device to allocate a unique multicast identifier for it. After receiving the allocated multicast identifier, the protocol conversion device sends a response message MC_NodeID_ACK (the third subtype is 3) for the multicast identifier to inform the control node. When sending a multicast message, the first subtype is set to 4 (multicast message sending message), and the second field is formed in combination with the allocated multicast identifier. Then, the protocol conversion device encapsulates the first field and the second field containing the CAN device information into a message payload, and then encapsulates them into a target message according to the steps described above, and sends the multicast message through the AutBus bus.

[0105] This embodiment performs protocol conversion via multicast, utilizing different subtypes to distinguish message interaction types. This enables efficient allocation and management of multicast identifiers between the control node (CN) and the protocol conversion device, as well as multicast transmission of CAN device data on the AutBus bus. This approach improves the efficiency and flexibility of data transmission, enabling multiple target devices to receive relevant data simultaneously, meeting the needs of large-scale device communication and collaborative work in industrial automation scenarios. It further breaks down the data transmission barriers between the CAN protocol and the AutBus protocol, and enhances the communication compatibility and collaboration of the entire industrial system.

[0106] Based on any of the above embodiments, in the fifth embodiment of the present application, before step S23, the following steps are included:

[0107] Step A10: encapsulate into a request message according to the device address of the connected first device, the device identifier of the protocol conversion device, and the second subtype.

[0108] In this embodiment, the first device is a CAN-compliant device whose device address uniquely identifies it. The device identifier of the protocol converter is the unique identifier of the device in the AutBus system. The second subtype is 1, representing a request message with a multicast identifier. As an optional embodiment, the protocol converter combines the first device's device address, its own device identifier, and the second subtype (value 1) in a specific data structure and format to form a request message.

[0109] Exemplarily, the request message includes: SUB_TYPE, data type BYTE is the second subtype: the value is 1, indicating a multicast identification request message, sent by the AutBus protocol conversion device to the control node; SRC_NodeID, data type WORD, is the device identifier of the AutBus protocol conversion device; SRC_CANID, data type BYTE, is the device address of the first device, used to identify the address of the device sending the frame.

[0110] Step A20: Send the request message to the control node, so that the control node returns an allocation message.

[0111] In this embodiment, the control node (CN) is responsible for the management and scheduling of the entire AutBus system and can assign a multicast identifier to the protocol converter based on the request message. The protocol converter sends the request message via a communication link established with the control node. As an alternative embodiment, the protocol converter utilizes the AutBus communication interface to encapsulate the request message into a suitable frame format according to the bus protocol requirements and sends it to the control node.

[0112] Furthermore, after receiving the request message, the control node will allocate a unique multicast identifier to the protocol conversion device according to the system resource situation and allocation rules, and return the unique multicast identifier to the protocol conversion device via an allocation message.

[0113] An allocation message is generated according to the fourth subtype, the multicast identifier, and the device identifier of the protocol conversion device.

[0114] Exemplarily, the allocation message includes: SUB_TYPE, a BYTE data type, which is the fourth subtype and has a value of 2, indicating a multicast ID allocation message sent by the control node to the AutBus protocol converter; MC_NodeID, a WORD data type, which is the multicast ID value assigned to the AutBus protocol converter SRC_NodeID; and SRC_NodeID, a WORD data type, which is the device ID of the AutBus protocol converter.

[0115] Step A30: Determine the multicast identifier based on the received allocation message.

[0116] In this embodiment, after receiving the allocation message, the protocol conversion device extracts the allocated multicast identifier from the allocation message. As an optional implementation, the protocol conversion device parses a specific field of the allocation message to obtain the multicast identifier information contained therein.

[0117] Further, after the step of determining the multicast identifier based on the received allocation message, the method further includes:

[0118] A40: Assemble a response message according to the third subtype, the multicast identifier, and the device identifier.

[0119] In this embodiment, the third subtype is 3, representing a response message for a multicast identifier. The multicast identifier is a unique identifier assigned by the control node to the protocol converter for multicast communication. The device identifier is the identifier of the protocol converter itself in the AutBus system. As an optional embodiment, the protocol converter combines the third subtype value of 3, the obtained multicast identifier, and its own device identifier according to a predefined message format to form a response message.

[0120] Exemplarily, the response message includes: SUB_TYPE, a BYTE data type, a third subtype value of 3, indicating a multicast identification response message sent by the AutBus protocol converter to the control node; MC_NodeID, a WORD data type, which is the multicast identification value assigned to the AutBus protocol converter SRC_NodeID; and SRC_NodeID, a WORD data type, which is the device identifier of the AutBus protocol converter.

[0121] A50: Send the response message to the control node.

[0122] In this embodiment, the protocol conversion device notifies the control node that the multicast identifier has been successfully received by sending a response message. As an optional implementation, the protocol conversion device encapsulates the response message according to the requirements of the AutBus bus protocol and sends it to the control node through the bus communication interface.

[0123] Furthermore, after the AutBus protocol converter is started, a multicast identifier for the CAN protocol is reserved. When a CAN device is connected to the AutBus protocol converter, the multicast identifier reception mode is activated and takes effect. When all CAN devices are connected to the AutBus protocol converter, they will have the same multicast identifier, and the control node CN will allocate a bandwidth time slot for the multicast identifier. That is, within the bandwidth time slot, the protocol converter executes the step of sending the target message.

[0124] This embodiment achieves efficient multicast protocol conversion between CAN protocol devices and the AutBus bus through a complete multicast identifier request, allocation, confirmation, and message encapsulation and transmission process. During this process, clear and accurate information exchange is carried out between the protocol conversion device and the control node, ensuring the correct allocation and use of multicast identifiers, improving the reliability and efficiency of data transmission, meeting the needs of large-scale device communication and collaborative work in intelligent transportation systems, and further promoting the integration and application of different protocol devices in complex systems.

[0125] Based on the above embodiment, in the sixth embodiment of the present application, the step of encapsulating the target message according to the message payload and type field includes:

[0126] Step S33: Set the type field to the second reserved field.

[0127] In this embodiment, the type field is the TYPE field of the AutBus bus protocol, which is used to indicate the type of message. The second reserved field is a specific value reserved specifically for target messages in multicast mode, which is used to identify this special type of message. As an example, the second reserved field can be 0x01 or 1. As an optional embodiment, the protocol conversion device sets the value of the type field to the pre-defined second reserved field based on the current multicast communication requirements.

[0128] Step S34: encapsulate the target message according to the message payload and the second reserved field.

[0129] In this embodiment, the target message is a complete message that complies with the AutBus protocol format and can be accurately transmitted on the AutBus bus. The protocol conversion device combines the message payload and the set second reserved field according to the encapsulation rules of the AutBus protocol to form the final target message. As an optional embodiment, the protocol conversion device adds the second reserved field to a specific location in the message payload (such as the message header) and performs necessary padding and verification to ensure that the target message complies with the requirements of the AutBus bus protocol.

[0130] Reference Figure 6 , Figure 6 An example of a target message in a multicast mode is shown, wherein the target message includes a TYPE (type) field, a Fragment no field, a LENGTH field, a PAYLOAD (payload) field, and a CRC field. The value of the type field is 1.

[0131] For example, on an automated production line in a large factory, there are multiple CAN-based production equipment sensors (such as temperature sensors and pressure sensors) as the first device, which are connected to the AutBus bus through a protocol conversion device. The control node is responsible for the management and scheduling of the entire system. When the protocol conversion device needs to send a multicast message of these sensor data to a group of monitoring devices:

[0132] The protocol conversion device collects the device addresses of the connected production equipment sensors, combines them with its own device identification, sets the second subtype to 1, encapsulates them into a request message and sends it to the control node.

[0133] After receiving the request message, the control node allocates a unique multicast identifier to the protocol conversion device and returns it through an allocation message.

[0134] After receiving the allocation message, the protocol conversion device determines the multicast identifier from the message.

[0135] The protocol conversion device sets the third subtype to 3, combines the multicast identifier and its own device identifier to assemble a response message, and sends it to the control node.

[0136] The protocol conversion device sets the first subtype to 4 and uses it together with the multicast identifier as the second field.

[0137] The protocol conversion device encapsulates the first field and the second field containing the production equipment sensor information into a message payload.

[0138] The protocol conversion device sets the type field to the second reserved field (such as 0x01).

[0139] Finally, the protocol conversion device encapsulates the message payload and the second reserved field into a target message, and sends the multicast message through the AutBus bus.

[0140] Exemplarily, the AutBus protocol conversion device is powered on and started; 2) the Can device is connected to the AutBus protocol conversion device, the AutBus protocol conversion device notifies the control node CN that a Can device has been connected, and the control node CN sends a multicast identifier to the AutBus protocol conversion device. The AutBus protocol conversion device starts the multicast receiving mode after receiving the multicast identifier sent by the control node; in this way, the control node CN can assign different multicast identifiers to different Can users. When the multicast identifiers are the same, the Can users can interact with each other through messages. Otherwise, the AutBus protocol conversion device does not process data that does not belong to its own multicast identifier. When all Can devices are connected to the AutBus protocol conversion device, they will have the same multicast identifier, and the control node CN will allocate a bandwidth time slot for the multicast identifier; when the Can device sends a Can message, the AutBus protocol conversion device receives the Can message, and the AutBus protocol conversion device encapsulates the Can message into the AutBus target message. The content of the target message includes:

[0141] SUB_TYPE fourth subtype: the value is 4, indicating that a multicast message with a Can message is sent by the AutBus protocol conversion device to other AutBus nodes (including control nodes, AutBus protocol conversion device nodes, etc.); MC_NodeID is a multicast identifier with a value range of 1 to 253, 0 is reserved, and 254 to 255 are reserved; this identifier is assigned by the control node CN to the AutBus protocol conversion device or reserved by the AutBus protocol conversion device; when this identifier is the same, the carried Can protocols can communicate with each other. SRC_CANID is the device address of the first device: used to identify the address of the device sending the frame; LENGTH is the message length, this value includes the total length of ENTRY_NUM and CAN_ENTRY. ENTRY_NUM is the number of CAN messages; CAN_ENTRY is a complete CAN message message.

[0142] Among them, reference Figure 7 , SUB_TYPE is set to 0x04, MC_NodeID is the value assigned by the controller CN to the AutBus protocol converter, or the multicast ID reserved by AutBus for the Can protocol. The CAN source ID is set to the node identifier of the node sending the Can message. The Can message is then encapsulated into the payload and sent to the AutBus bus. When the AutBus protocol converter receives the AutBus message encapsulating the Can message, it first determines whether the MC_NodeID assigned by the controlled node CN is the same as the MC_NodeID in the message. If they are the same, the Can message is extracted from the AutBus message and forwarded to the Can device for processing. The response message flow of the Can device is similar to the above embodiment and will not be repeated here.

[0143] Reference Figure 8 If the device identification of the AutBus protocol converter 4 is different from the target device identification, the message will be discarded.

[0144] This embodiment implements efficient multicast protocol conversion between CAN protocol devices and the AutBus bus through a complete multicast identifier request, allocation, confirmation, message encapsulation, and transmission process. In particular, by setting a dedicated second reserved field to identify the target message in multicast mode, control nodes and receiving devices can accurately identify and process these multicast messages, improving the reliability and efficiency of data transmission, meeting the needs of large-scale equipment communication and collaborative operation in large-scale factory automation production lines, and further promoting the integration and application of different protocol devices in complex industrial systems.

[0145] Based on any of the above embodiments, in Embodiment 7 of the present application, the control method of the protocol conversion device further includes:

[0146] Step C10: Determine the target multicast identifier of the target message according to the target message received by the protocol conversion device.

[0147] In this embodiment, the target message is a message transmitted on the AutBus bus and conforming to the AutBus protocol format. The target multicast identifier is unique identification information in the message used to identify multicast communication. As an optional embodiment, the protocol conversion device extracts a specific field representing the target multicast identifier from the received target message according to the message parsing rules specified by the AutBus protocol.

[0148] Step C20: If the target multicast identifier is the same as the multicast identifier of the protocol conversion device, extract the message in the target message.

[0149] In this embodiment, the multicast identifier of the protocol converter is a unique identifier assigned by the control node for multicast communication. When the target multicast identifier matches the multicast identifier of the protocol converter, it indicates that the target message is destined for that protocol converter. The message portion is the actual data content carried in the target message, such as data sent by a CAN device. As an optional embodiment, after confirming that the multicast identifiers match, the protocol converter extracts the message portion from the target message based on the format of the target message.

[0150] Step C30: forward the message to the first device for processing.

[0151] In this embodiment, the first device is a device that complies with the CAN protocol, such as a sensor or actuator. The protocol conversion device forwards the extracted message to the corresponding first device, allowing the first device to process the message. For example, a sensor may adjust its acquisition frequency based on the received message, or an actuator may perform an action based on the message. As an optional embodiment, the protocol conversion device encapsulates the message in the CAN protocol format and sends it to the first device via the CAN communication interface established with the first device.

[0152] Furthermore, when the AutBus converter receives the AutBus message encapsulating the Can message, it first determines whether the MC_NodeID assigned by the controlled node CN is the same as the MC_NodeID in the message. If they are the same, it extracts the Can message in the AutBus message and forwards it to the Can device for processing; otherwise, the message is discarded.

[0153] Through the above steps, this embodiment implements the function of receiving target messages from the AutBus bus, filtering out messages belonging to itself based on the multicast identifier, and forwarding the messages to the first CAN protocol device for processing. This further improves the bidirectional communication mechanism between CAN protocol devices and the AutBus bus, enabling devices based on different protocols to work together in the same system, improving the intelligence level of the smart home system and the interactivity between devices, and meeting users' needs for centralized control and management of smart home devices.

[0154] The present application provides a protocol conversion device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the control method of the protocol conversion device in the above-mentioned embodiment 1.

[0155] Reference below Figure 9 , which shows a schematic structural diagram of a protocol conversion device suitable for implementing an embodiment of the present application. The protocol conversion device in the embodiment of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, personal digital assistants (PDAs), tablet computers, and vehicle-mounted terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The protocol conversion device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0156] like Figure 9As shown, the protocol conversion device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. In the random access memory 1004, various programs and data required for the operation of the protocol conversion device are also stored. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the protocol conversion device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a protocol conversion device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0157] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0158] The protocol conversion device provided in this application, using the control method for the protocol conversion device in the above-mentioned embodiment, can resolve the technical problem of incompatibility between old and new system protocols, which creates barriers to data interoperability and hinders the full-process collection of industrial data. Compared with the prior art, the beneficial effects of the protocol conversion device provided in this application are the same as those of the protocol conversion device provided in the above-mentioned embodiment, and the other technical features of the protocol conversion device are the same as those disclosed in the method of the above-mentioned embodiment, and are not further described here.

[0159] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0160] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0161] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, and the computer-readable program instructions are used to execute the control method of the protocol conversion device in the above embodiment.

[0162] The computer-readable storage medium provided in this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in combination with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium can be transmitted using any appropriate medium, including but not limited to: an electric wire, an optical cable, a radio frequency (RF), etc., or any suitable combination thereof.

[0163] The computer-readable storage medium may be included in the protocol conversion device; or may exist independently without being assembled into the protocol conversion device.

[0164] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the protocol conversion device, the protocol conversion device: based on the message message sent by the first device and the device address of the first device as the first field, the first device corresponds to the first protocol; based on the first field and the second field, it is encapsulated into a message payload, and the second field is used to identify the target device for processing the message payload; based on the message payload and the type field, it is encapsulated into a target message, and the target message is sent to the protocol bus, and the protocol bus corresponds to the second protocol.

[0165] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0166] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0167] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0168] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the control method of the protocol conversion device described above. This computer-readable storage medium can address the technical issues of incompatibility between old and new system protocols, which creates barriers to data interoperability and hinders the full-process collection of industrial data. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the control method of the protocol conversion device provided in the above-mentioned embodiments, and are not further elaborated here.

[0169] An embodiment of the present application provides a computer program product, including a computer program, which implements the steps of the control method of the protocol conversion device as described above when the computer program is executed by a processor.

[0170] The computer program product provided in this application can resolve the technical issues of incompatibility between old and new system protocols, which creates barriers to data interoperability and hinders the full-process collection of industrial data. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this application are the same as those of the control method for the protocol conversion device provided in the above-mentioned embodiments, and are not further elaborated here.

[0171] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. A control method for a protocol conversion device, characterized in that: The control method of the protocol conversion device includes: According to the message sent by the first device and the device address of the first device as the first field, the first device corresponds to the first protocol; encapsulating the first field and the second field into a message payload, wherein the second field is used to identify a target device for processing the message payload; The target message is encapsulated according to the message payload and the type field, and the target message is sent to a protocol bus, where the protocol bus corresponds to a second protocol.

2. The control method of the protocol conversion device according to claim 1, characterized in that: The step of using the message sent by the first device and the device address of the first device as the first field includes: Determine the number of messages corresponding to the message; Determine the message length according to the number of messages and the message message; The device address, the message length, the number of messages and the message message are used as the first field.

3. The control method of the protocol conversion device according to claim 1, wherein: The step of encapsulating the first field and the second field into a message payload includes: Using the node identifier of the target device as the second field; encapsulating the second field and the first field into the message payload; The step of encapsulating the target message according to the message payload and type field includes: Setting the type field to a first reserved field; The target message is encapsulated according to the message payload and the first reserved field.

4. The control method of the protocol conversion device according to claim 1, wherein: The step of encapsulating the first field and the second field into a message payload includes: The first subtype and the multicast identifier of the protocol conversion device are used as the second field; The message payload is encapsulated based on the second field and the first field.

5. The control method of the protocol conversion device according to claim 4, wherein: Before the step of using the first subtype and the multicast identifier of the protocol conversion device as the second field, the method includes: encapsulate into a request message according to the device address of the first device being connected, the device identifier of the protocol conversion device, and the second subtype; Sending the request message to the control node so that the control node returns an allocation message; The multicast identifier is determined based on the received allocation message.

6. The control method of the protocol conversion device according to claim 5, wherein: After the step of determining the multicast identifier based on the received allocation message, the method further includes: assembling a response message according to the third subtype, the multicast identifier, and the device identifier; The response message is sent to the control node.

7. The control method of the protocol conversion device according to claim 1, wherein: The step of encapsulating the target message according to the message payload and type field includes: Setting the type field to a second reserved field; The target message is encapsulated according to the message payload and the second reserved field.

8. The control method of the protocol conversion device according to claim 1, wherein: The control method of the protocol conversion device further includes: Determining a target multicast identifier of the target message according to the target message received by the protocol conversion device; If the target multicast identifier is the same as the multicast identifier of the protocol conversion device, extracting the message in the target message; Forward the message to the first device for processing.

9. A protocol conversion device, characterized in that: The protocol conversion device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the control method for the protocol conversion device according to any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the control method of the protocol conversion device according to any one of claims 1 to 8 are implemented.

Images