CAN bus and AUTBUS bus conversion method, controller and architecture

Abstract

The embodiments of the present application relate to the field of communication technology, and to a conversion method, controller and architecture for CAN bus and AUTBUS bus. The scheme of the conversion method is as follows: during the initialization of the PHB master station, a descriptor is generated for each conversion module set in the PHB slave station; the PHB master station and the PHB slave station are connected through the AUTBUS bus, and each conversion module is connected to its corresponding CAN bus; the PHB master station receives the uploaded CAN message from the AUTBUS bus based on the descriptor and caches it; wherein, the CAN message comes from the CAN bus and is uploaded to the PHB master station after being processed by the conversion module; the CAN message is read from the cache by calling the read interface through the custom CAN module set in the PHB master station. The embodiment of the present application uses a custom CAN function block and PHB protocol to realize the reception and processing of CAN messages sent by the conversion module on the AUTBUS bus, and can use the advantages of the AUTBUS bus to realize long-distance, high-speed CAN communication, avoid data coverage loss, and ensure data integrity and real-time performance.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a conversion method, a controller and an architecture for a CAN bus and an AUTBUS bus. Background Art

[0002] The controller communicates with devices on the AUTBUS bus using the PHB protocol (Pipe High-speed Bus). This requires importing the slave configuration file and implementing real-time message communication based on the configuration. However, if standard real-time data transmission is used to transmit CAN messages, CAN messages are periodically transmitted to the controller. New data overwrites older data, easily causing data loss. Alternatively, using a custom CAN function block can enable the controller's CAN interface to receive CAN messages, but this cannot receive or process CAN messages sent from other interfaces (such as the AUTBUS bus). Summary of the Invention

[0003] In view of the above problems in the prior art, the embodiments of the present application provide a method, controller and architecture for converting a CAN bus to an AUTBUS bus. A custom CAN function block and the PHB protocol are used to receive and process CAN messages sent by a conversion module on the AUTBUS bus. The advantages of the AUTBUS bus can be used to achieve long-distance, high-speed CAN communication, avoid data coverage loss, and ensure data integrity and real-time performance.

[0004] To achieve the above objectives, the present application provides a first aspect of a method for converting a CAN bus to an AUTBUS bus, comprising:

[0005] During the initialization of the PHB master station, a descriptor is generated for each conversion module provided in the PHB slave station; wherein the PHB master station and the PHB slave station are connected via an AUTBUS bus, and each conversion module is connected to its corresponding CAN bus;

[0006] The PHB master station receives the uploaded CAN message from the AUTBUS bus based on the descriptor and caches it; wherein the CAN message comes from the CAN bus and is uploaded to the PHB master station after being processed by the conversion module;

[0007] The CAN message is read from the cache by calling a read interface through a custom CAN module provided in the PHB master station.

[0008] As a possible implementation of the first aspect, the method further includes:

[0009] The PHB master station sends CAN messages through the CAN function block; wherein, the CAN function block calls the write interface, sends the CAN message to the conversion module through the AUTBUS bus, and the CAN message is sent to the CAN bus after being processed by the conversion module.

[0010] As a possible implementation of the first aspect, generating a descriptor for each conversion module provided in a PHB slave station includes:

[0011] The descriptor is generated when the PHB slave is online.

[0012] As a possible implementation of the first aspect, the processing of the message by the conversion module includes:

[0013] The conversion module encapsulates the CAN message from the CAN bus into a PHB packet, and uploads the PHB packet to the PHB master station.

[0014] As a possible implementation of the first aspect, the processing of the message by the conversion module includes:

[0015] The conversion module decapsulates the CAN message encapsulated into the PHB packet sent by the PHB master station, and sends the decapsulated CAN message to the CAN bus.

[0016] A second aspect of the present application provides a controller, the controller serving as a PHB master station, and a custom CAN module is set in the controller;

[0017] During initialization, the PHB master generates a descriptor for each conversion module provided in the PHB slave; wherein the PHB master is connected to the PHB slave via an AUTBUS bus, and each conversion module is connected to its corresponding CAN bus;

[0018] The PHB master station receives the uploaded CAN message from the AUTBUS bus based on the descriptor and caches it; wherein the CAN message comes from the CAN bus and is uploaded to the PHB master station after being processed by the conversion module;

[0019] The custom CAN module calls a read interface to read the CAN message from the cache.

[0020] As a possible implementation of the second aspect, the following also is included:

[0021] The PHB master station sends CAN messages through the CAN function block; wherein, the CAN function block calls the write interface, sends the CAN message to the conversion module through the AUTBUS bus, and the CAN message is sent to the CAN bus after being processed by the conversion module.

[0022] As a possible implementation of the second aspect, the following also is included:

[0023] When the PHB slave is online, the PHB master generates a descriptor for the conversion module provided in the PHB slave.

[0024] A third aspect of the present application provides a network architecture for converting a CAN bus to an AUTBUS bus, the network architecture comprising the controller as described in the second aspect above and at least one conversion module;

[0025] The conversion modules are arranged at the PHB slave stations and connected to the corresponding CAN buses;

[0026] The conversion module is used to encapsulate the CAN message from the CAN bus into a PHB packet, and upload the PHB packet to the PHB master station through the AUTBUS bus.

[0027] As a possible implementation of the third aspect, the conversion module is further configured to:

[0028] The CAN message encapsulated into the PHB packet sent by the PHB master station is decapsulated, and the decapsulated CAN message is sent to the CAN bus.

[0029] A fourth aspect of the present application provides a computing device, including:

[0030] Communication interface;

[0031] at least one processor connected to the communication interface; and

[0032] At least one memory is connected to the processor and stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor executes any one of the methods described in the first aspect above.

[0033] In a fifth aspect, the present application provides a computer-readable storage medium having program instructions stored thereon. When the program instructions are executed by a computer, the computer is caused to execute any of the methods described in the first aspect.

[0034] These and other aspects of the invention will be apparent from and elucidated with reference to the following description of the embodiment(s). BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The following further illustrates the various features of the present invention and the relationships between the various features with reference to the accompanying drawings. The accompanying drawings are all exemplary, and some features are not shown in actual proportion. In addition, some drawings may omit features that are customary in the field to which this application relates and are not necessary for this application, or additional features that are not necessary for this application may be shown. The combination of the various features shown in the accompanying drawings is not intended to limit this application. In addition, throughout this specification, the same reference numerals refer to the same content. The specific description of the drawings is as follows:

[0036] Figure 1 A schematic diagram of an embodiment of a method for converting a CAN bus to an AUTBUS bus provided in an embodiment of the present application;

[0037] Figure 2 A schematic diagram of a network architecture of an embodiment of a method for converting a CAN bus to an AUTBUS bus provided in an embodiment of the present application;

[0038] Figure 3 A schematic diagram of a network architecture of an embodiment of a method for converting a CAN bus to an AUTBUS bus provided in an embodiment of the present application;

[0039] Figure 4 A flow chart of an embodiment of a method for converting a CAN bus to an AUTBUS bus provided in an embodiment of the present application;

[0040] Figure 5 A schematic diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] The words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0042] In the following description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0043] The term "comprising" as used in the specification and claims should not be construed as limiting to what is listed thereafter; it does not exclude other elements or steps. Thus, it should be interpreted as specifying the presence of the features, integers, steps, or components mentioned, but not excluding the presence or addition of one or more other features, integers, steps, or components, or groups thereof. Thus, the expression "a device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0044] References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, appearances of the phrases "in one embodiment" or "in an embodiment" throughout this specification do not necessarily refer to the same embodiment, but may do so. Furthermore, in one or more embodiments, the particular features, structures, or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0045] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. In the event of any inconsistency, the meanings described in this specification or the meanings derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application. In order to accurately describe the technical content in this application and to accurately understand the present invention, the following explanations or definitions are given for the terms used in this specification before describing the specific embodiments:

[0046] 1) AUTBUS Bus: AUTBUS is an industrial fieldbus that utilizes a two-wire, unbridged medium and features multi-node, high-bandwidth, high-real-time, and long-distance transmission. As a high-speed, time-sensitive network bus, AUTBUS combines the advantages of fieldbus and real-time Ethernet. It can be used for the transmission and application of both real-time and non-real-time data in industrial fields such as process control and discrete control. It can also carry data for ISO / IEC / IEEE 8802-3 Ethernet services and application services such as IPv6. The AUTBUS standard introduces new physical layer technologies, achieving the "last mile" in industrial control, enabling broadband access without changing traditional cabling practices. Compared to the CAN bus, AUTBUS offers higher bandwidth and better real-time performance, in line with the trend of interconnected, integrated development of global industrial communication networks.

[0047] 2) CAN (Controller Area Network) bus: CAN is an ISO internationally standardized serial communication protocol. Developed to facilitate data exchange between numerous control and test instruments in modern automobiles, the CAN bus is a multi-master bus whose communication media can be twisted pair, coaxial cable, or optical fiber. Communication rates can reach up to 1 Mbps. The CAN bus communication interface integrates the physical layer and data link layer functions of the CAN protocol, enabling framing of communication data, including bit stuffing, data block encoding, cyclic redundancy checking, and priority determination. CAN is widely used in industrial automation, shipbuilding, medical equipment, and industrial equipment. Fieldbus is one of the hot topics in today's automation technology development and is known as the computer local area network in the automation field. Its emergence provides strong technical support for distributed control systems to achieve real-time and reliable data communication between nodes.

[0048] The following first introduces the existing methods, and then introduces the technical solution of this application in detail.

[0049] The controller communicates with devices on the AUTBUS bus using the PHB protocol (Pipeline High-Speed ​​Bus). This requires importing the slave configuration file and implementing real-time message communication based on the configuration. However, if standard real-time data transmission using CAN messages is used, CAN messages are periodically transmitted to the controller. New data overwrites older data, potentially causing data loss. Alternatively, using a custom CAN function block allows the controller's CAN interface to receive CAN messages, but this does not allow the reception or processing of CAN messages sent from other interfaces (such as the AUTBUS bus).

[0050] The existing technology has the following defects: using a custom CAN function block cannot receive and process CAN messages sent from the AUTBUS bus; real-time transmission of CAN messages on the AUTBUS bus through the PHB protocol will cause data coverage loss.

[0051] Based on the technical problems existing in the above-mentioned prior art, the present application provides a method for converting a CAN bus to an AUTBUS bus, using a custom CAN function block and a PHB protocol to realize the reception and processing of CAN messages sent by a conversion module on the AUTBUS bus. This solution can take advantage of the advantages of the AUTBUS bus to achieve long-distance, high-speed CAN communication, and can avoid data overwriting and loss, and ensure data integrity and real-time performance. The embodiment of the present application solves the technical problem of the inability to receive and process CAN messages sent from the AUTBUS bus mentioned in the prior art by using the processing of the conversion module. The technical problem of data overwriting and loss mentioned in the prior art is solved by using caching means.

[0052] Figure 1 Schematic diagram of an embodiment of the method for converting the CAN bus to the AUTBUS bus provided in the embodiment of the present application. Figure 1 As shown, the method includes:

[0053] Step S110: during the initialization of the PHB master station, generating a descriptor for each conversion module provided in the PHB slave station; wherein the PHB master station and the PHB slave station are connected via an AUTBUS bus, and each conversion module is connected to its corresponding CAN bus;

[0054] Step S120: The PHB master station receives the CAN message uploaded from the AUTBUS bus based on the descriptor and caches it; wherein the CAN message comes from the CAN bus and is uploaded to the PHB master station after being processed by the conversion module;

[0055] Step S130 : calling a read interface via a custom CAN module provided in the PHB master station to read the CAN message from the cache.

[0056] PHB is a bus used on AUTBUS. In the embodiment of the present application, the conversion between CAN bus and AUTBUS bus is realized based on PHB protocol and custom CAN function block. Figure 1 and Figure 2 , the controller can be used as the PHB master. The controller can be a programmable logic controller (PLC). The conversion function can convert CAN messages to and from AUTBUS messages. A conversion module with this function can be installed in the PHB slave. Figure 2 The "PHB-S" in the figure indicates a PHB slave. The PHB master and PHB slave are connected via the AUTBUS bus. The AUTBUS bus and CAN bus are connected via a conversion module.

[0057] When using a custom CAN function block for communication, you must first open the CAN interface on the device used to send and receive messages. Therefore, to implement the CAN to AUTBUS conversion function, during the PHB configuration and initialization process, the PHB master generates a virtual CAN interface for each CAN to AUTBUS conversion module (PHB slave) for use by other modules in the controller to send and receive CAN messages.

[0058] In step S110, during the initialization of the PHB master, a descriptor is generated for each conversion module set in the PHB slave. The descriptor is used to identify each conversion module. Figure 2 In the network architecture shown, the conversion module is involved in forwarding CAN messages. On the PHB master, the conversion module can be virtualized as a CAN interface on the controller, allowing direct control of the conversion module through custom CAN function blocks. In a network architecture, there can be one or more conversion modules. Conversion modules corresponding to different descriptors connect to different CAN buses. A CAN interface can connect to only one CAN bus. Each conversion module connects to its own corresponding CAN bus.

[0059] Figure 2 At least one CAN device can be connected to the CAN bus in the controller. The process of a CAN device transmitting a CAN message to the controller may include: the CAN device transmitting the CAN message to a conversion module via the CAN bus; the conversion module converting the CAN message so that it can be transmitted on the AUTBUS bus. After processing, the conversion module uploads the message to the PHB master via the AUTBUS bus. In step S120, the PHB master receives the CAN message uploaded by the CAN device from the AUTBUS bus based on the descriptor generated in step S110 and stores the CAN message in a cache.

[0060] In one example, the controller functions as the PHB master. After initialization, the controller receives CAN messages from the AUTBUS and caches them locally, waiting for the custom CAN module to call the read interface. The custom CAN module is also installed in the controller and is a function block within the controller, also known as a custom CAN function block.

[0061] In one example, the custom CAN module may include four parts: opening the CAN interface, receiving messages, sending messages, and closing the CAN interface. In step S130, the custom CAN module set in the PHB master opens the virtual CAN interface and calls the read interface to read the CAN message from the cache.

[0062] See also Figure 3 The controller is equipped with a PHB protocol module and a custom CAN module. The PHB protocol module is used to execute the PHB communication protocol, enabling communication between the PHB master and PHB slaves. The controller serves as the PHB master, and the conversion module is provided in the PHB slave. When the PHB master is initialized, the PHB protocol module generates a descriptor identifying each PHB slave. Each slave refers to a PHB slave serving as the conversion module. The PHB master and the PHB slave are connected via the AUTBUS bus. The AUTBUS bus and the CAN bus are connected via the conversion module.

[0063] See also Figure 3, a cache is set in the PHB protocol module to store the uploaded CAN messages received from the AUTBUS bus. The process of uploading CAN messages is as follows: at least one CAN device can be connected to the CAN bus. The CAN device transmits the CAN message to the conversion module via the CAN bus; the conversion module converts the CAN message so that the converted message can be transmitted on the AUTBUS bus. After processing, the conversion module uploads the message to the PHB protocol module in the PHB master station via the AUTBUS bus. Based on the generated descriptor, the PHB protocol module receives the CAN message uploaded by the CAN device from the AUTBUS bus and stores the CAN message in the cache. See Figure 3 The custom CAN module is provided with a read interface, which is an interface for the custom CAN module to read data from the above buffer. The custom CAN module can call the read interface to read CAN messages from the buffer.

[0064] exist Figure 3 In the CAN bus, the conversion module is a dedicated slave station for AUTBUS to CAN conversion. A descriptor needs to be generated for the conversion module. The descriptor is equivalent to virtualizing the conversion module into a CAN port on the controller. The conversion module involves the forwarding of CAN messages, so from the perspective of the controller, the conversion module can be considered a virtual CAN interface in software terms. Figure 3 , the custom CAN module can open a virtual CAN interface and call the read interface to read CAN messages from the cache. In the prior art, the custom CAN function block is an actual CAN interface of the PHB master station. Real-time messages are transmitted in the AUTBUS bus. After the real-time message is received, if the previous message is not read in time, the previous message may be overwritten by the next message. In contrast, the embodiment of the present application regards the device connected by the PHB protocol as a virtual CAN interface. A cache is set in the CAN interface to cache the received messages and wait for the custom CAN module to read them.

[0065] This embodiment of the present application utilizes a custom CAN function block and the PHB protocol to receive and process CAN messages sent by a conversion module on the AUTBUS bus. In this solution, the PHB master and PHB slave stations are connected via the AUTBUS bus, and the conversion modules within each PHB slave station are connected to their corresponding CAN bus. By utilizing this network architecture, this solution leverages the advantages of the AUTBUS bus to achieve long-distance, high-speed CAN communication. Furthermore, this solution utilizes a caching mechanism to prevent data overwriting and loss, ensuring data integrity and real-time performance.

[0066] In one embodiment, the method further comprises:

[0067] The PHB master station sends CAN messages through the CAN function block; wherein, the CAN function block calls the write interface, sends the CAN message to the conversion module through the AUTBUS bus, and the CAN message is sent to the CAN bus after being processed by the conversion module.

[0068] See also Figure 2 , using the controller as the PHB master. When the controller sends a CAN message to a CAN device on the CAN bus, the controller's CAN function block invokes the write interface and directly sends the message to the conversion module via AUTBUS. The conversion module converts the CAN message so that it can be transmitted on the CAN bus. After processing, the conversion module sends the message to the CAN bus.

[0069] like Figure 4 As shown, in the controller, the process of an exemplary CAN bus and AUTBUS bus conversion method is as follows:

[0070] 1) PHB protocol

[0071] ① The PHB master initializes, generates descriptors to identify each slave, and waits for the slave to come online.

[0072] Among them, the slave station used as the conversion module has the function of connecting to the CAN bus and needs to generate descriptors. Other slave stations do not have the function of connecting to the CAN bus and do not need to generate descriptors.

[0073] ② The slave station used as the conversion module goes online, performs basic configuration related to the PHB protocol, and prepares for communication.

[0074] ③ The PHB receives CAN messages uploaded by the slave. These messages are transmitted via the CAN bus through the conversion module. The PHB receives and buffers the messages, then waits for the custom CAN module to call the read interface to receive them. When the master sends commands to the slave, the custom CAN module acts as the interface for sending CAN messages, transmitting the CAN messages required by the CAN function block via the PHB protocol.

[0075] 2) Custom CAN module

[0076] ① Initialization: You need to wait until the PHB slave station comes online before initialization can be successful.

[0077] ② Start sending and receiving CAN messages.

[0078] In one embodiment, generating a descriptor for each conversion module provided at a PHB slave station includes:

[0079] The descriptor is generated when the PHB slave is online.

[0080] See also Figures 2 to 4 If the descriptor is generated when the PHB slave is not online, the custom CAN module will fail to open the virtual CAN interface of the conversion module. Therefore, it is necessary to generate a descriptor when the slave is online after the PHB protocol initialization is completed. The descriptor is a virtual CAN interface that can be used by the controller to receive and send CAN messages. The custom CAN module needs to use this virtual CAN interface when receiving a message. Whether this CAN interface is available depends on whether the conversion module it represents is online and whether the communication of the PHB protocol is normal. In the embodiment of the present application, the custom CAN module and the PHB can be linked through this descriptor, and the two can work together to achieve the conversion between the CAN bus and the AUTBUS bus.

[0081] In the embodiment of the present application, the conversion module is virtualized into a CAN interface on the controller, which is equivalent to directly connecting the controller to the CAN bus, that is, the controller is used as a device on the CAN bus to execute the communication protocol or directly send messages.

[0082] In one embodiment, the processing of the message by the conversion module includes:

[0083] The conversion module encapsulates the CAN message from the CAN bus into a PHB packet, and uploads the PHB packet to the PHB master station.

[0084] In one embodiment, the processing of the message by the conversion module includes:

[0085] The conversion module decapsulates the CAN message encapsulated into the PHB packet sent by the PHB master station, and sends the decapsulated CAN message to the CAN bus.

[0086] See also Figure 2 The conversion module encapsulates the packets sent from the CAN bus into PHB packets, and then transmits them to the controller. For the packets sent by the controller, the conversion module removes the PHB protocol header and protocol footer, leaving only the CAN message, and then sends it to the CAN bus.

[0087] In one example, data on the CAN bus needs to be sent to a controller. In this application scenario, the controller can be understood as a device on the CAN bus. The CAN device sends data to the controller via a conversion module. The controller collects CAN data from the CAN bus, aggregates the data, and then performs calculations. In another application scenario, the controller needs to send control instructions to the CAN device via a conversion module. In both of these application scenarios, the controller and CAN device interact through the conversion module, virtualizing the controller as a device on the CAN bus during this interaction.

[0088] See also Figure 2 In the network architecture, the controller is connected to the CAN bus, collects some information from the CAN bus devices and then issues instructions. Taking into account the advantages of the AUTBUS bus over the CAN bus, the introduction of the AUTBUS bus in the middle can give full play to the advantages of the AUTBUS bus and realize long-distance, high-speed CAN communication. The conversion module is a device connected to the CAN bus, and its purpose is equivalent to connecting the controller directly to the CAN bus. In actual application scenarios, the distance between the controller and the CAN bus may be very far. The conversion module can be directly set on the CAN bus, or the conversion module can also be directly set very close to the CAN device. In this case, the distance between the conversion module and the controller is very far. If the network transmission over this long distance uses the CAN bus, the communication quality and efficiency will be difficult to guarantee. Therefore, the embodiment of the present application uses the AUTBUS bus to transmit data over this distance, and can use the AUTBUS bus to achieve long-distance, high-speed CAN communication.

[0089] The present application also provides a corresponding controller, which serves as a PHB master station and is provided with a custom CAN module;

[0090] During initialization, the PHB master generates a descriptor for each conversion module provided in the PHB slave; wherein the PHB master is connected to the PHB slave via an AUTBUS bus, and each conversion module is connected to its corresponding CAN bus;

[0091] The PHB master station receives the uploaded CAN message from the AUTBUS bus based on the descriptor and caches it; wherein the CAN message comes from the CAN bus and is uploaded to the PHB master station after being processed by the conversion module;

[0092] The custom CAN module calls a read interface to read the CAN message from the cache.

[0093] In one embodiment, it further includes:

[0094] The PHB master station sends CAN messages through the CAN function block; wherein, the CAN function block calls the write interface, sends the CAN message to the conversion module through the AUTBUS bus, and the CAN message is sent to the CAN bus after being processed by the conversion module.

[0095] In one embodiment, it further includes:

[0096] When the PHB slave is online, the PHB master generates a descriptor for the conversion module provided in the PHB slave.

[0097] In one embodiment, the processing of the message by the conversion module includes:

[0098] The conversion module encapsulates the CAN message from the CAN bus into a PHB packet, and uploads the PHB packet to the PHB master station.

[0099] In one embodiment, the processing of the message by the conversion module includes:

[0100] The conversion module decapsulates the CAN message encapsulated into the PHB packet sent by the PHB master station, and sends the decapsulated CAN message to the CAN bus.

[0101] The controller uses a custom CAN function block and the PHB protocol to receive and process CAN messages sent by the conversion module on the AUTBUS bus, converting the CAN bus to the AUTBUS bus. For the beneficial effects or technical problems solved by this controller, please refer to the description of any of the above-mentioned conversion methods or the description in the Summary of the Invention, and will not be repeated here.

[0102] See also Figure 2 , the present application also provides a corresponding network architecture for realizing conversion between CAN bus and AUTBUS bus, the network architecture comprising the above-mentioned controller and at least one conversion module;

[0103] The conversion modules are arranged at the PHB slave stations and connected to the corresponding CAN buses;

[0104] The conversion module is used to encapsulate the CAN message from the CAN bus into a PHB packet, and upload the PHB packet to the PHB master station through the AUTBUS bus.

[0105] For the beneficial effects or technical problems solved by this network architecture, please refer to the description of the above-mentioned controller and any of the above-mentioned conversion methods, or refer to the description in the content of the invention, which will not be repeated here.

[0106] In one embodiment, the conversion module is further configured to:

[0107] The CAN message encapsulated into the PHB packet sent by the PHB master station is decapsulated, and the decapsulated CAN message is sent to the CAN bus.

[0108] Figure 59 is a schematic structural diagram of a computing device 900 provided in an embodiment of the present application. The computing device 900 includes: a processor 910, a memory 920, and a communication interface 930.

[0109] It should be understood that Figure 5 The communication interface 930 in the computing device 900 shown in FIG. 9 may be used to communicate with other devices.

[0110] The processor 910 may be connected to a memory 920. The memory 920 may be used to store the program code and data. Therefore, the memory 920 may be a storage unit within the processor 910, an external storage unit independent of the processor 910, or a component including both a storage unit within the processor 910 and an external storage unit independent of the processor 910.

[0111] Optionally, the computing device 900 may further include a bus. The memory 920 and the communication interface 930 may be connected to the processor 910 via the bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, and the like.

[0112] It should be understood that in the embodiment of the present application, the processor 910 can adopt a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Alternatively, the processor 910 adopts one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0113] The memory 920 may include a read-only memory and a random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include a non-volatile random access memory. For example, the processor 910 may also store information about the device type.

[0114] When the computing device 900 is running, the processor 910 executes the computer-executable instructions in the memory 920 to perform the operating steps of the above method.

[0115] It should be understood that the computing device 900 according to the embodiment of the present application can correspond to the corresponding subject in executing the method according to each embodiment of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.

[0116] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0117] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0118] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0119] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0120] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0121] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0122] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, it is used to execute a method for generating diversified questions, which includes at least one of the solutions described in the above embodiments.

[0123] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or components, or any combination thereof.More specific examples (non-exhaustive list) of computer-readable storage media include: electrical connection with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination thereof.In this document, computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0124] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0125] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0126] The 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., through the Internet using an Internet service provider).

[0127] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present application has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, all of which fall within the scope of protection of the present invention.

Claims

1. A method for converting a CAN bus to an AUTBUS bus, characterized in that: include: During the initialization of the PHB master station, when the PHB slave station is online, a descriptor is generated for each conversion module provided in the PHB slave station; wherein the PHB master station is connected to the PHB slave station via an AUTBUS bus, and each conversion module is connected to its corresponding CAN bus, wherein the PHB master station is a controller, and each descriptor virtualizes the corresponding conversion module into a CAN interface of the controller, so that the custom CAN module provided in the controller directly controls the corresponding conversion module; The PHB master station receives the uploaded CAN message from the AUTBUS bus based on the descriptor and caches it; wherein the CAN message comes from the CAN bus and is uploaded to the PHB master station after being processed by the conversion module; The virtual CAN interface is opened through the CAN module, a read interface is called, and the CAN message is read from the cache.

2. The method according to claim 1, characterized in that The method further comprises: The PHB master station sends CAN messages through the CAN module; wherein, the CAN module calls the write interface and sends the CAN messages to the conversion module through the AUTBUS bus, and the CAN messages are sent to the CAN bus after being processed by the conversion module.

3. The method according to claim 1, characterized in that The processing of the message by the conversion module includes: The conversion module encapsulates the CAN message from the CAN bus into a PHB packet, and uploads the PHB packet to the PHB master station.

4. The method according to claim 2, characterized in that The processing of the message by the conversion module includes: The conversion module decapsulates the CAN message encapsulated into the PHB packet sent by the PHB master station, and sends the decapsulated CAN message to the CAN bus.

5. A controller, characterized in that: The controller serves as a PHB master station, and a custom CAN module is set in the controller; During the initialization process, the PHB master generates a descriptor for each conversion module provided in the PHB slave station when the PHB slave station is online. The PHB master is connected to the PHB slave station via an AUTBUS bus, and each conversion module is connected to its corresponding CAN bus. Each descriptor virtualizes the corresponding conversion module into a CAN interface of the controller, so that the custom CAN module provided in the controller directly controls the corresponding conversion module. The PHB master station receives the uploaded CAN message from the AUTBUS bus based on the descriptor and caches it; wherein the CAN message comes from the CAN bus and is uploaded to the PHB master station after being processed by the conversion module; The custom CAN module opens a virtual CAN interface, calls a read interface, and reads the CAN message from the cache.

6. The controller according to claim 5, characterized in that Also includes: The PHB master station sends CAN messages through the CAN module; wherein, the CAN module calls the write interface and sends the CAN messages to the conversion module through the AUTBUS bus, and the CAN messages are sent to the CAN bus after being processed by the conversion module.

7. A network architecture for realizing conversion between CAN bus and AUTBUS bus, characterized in that: The network architecture comprises the controller according to claim 5 and at least one conversion module; The conversion modules are arranged at the PHB slave stations and connected to the corresponding CAN buses; The conversion module is used to encapsulate the CAN message from the CAN bus into a PHB packet, and upload the PHB packet to the PHB master station through the AUTBUS bus.

8. The network architecture according to claim 7, characterized in that: The conversion module is further configured to: The CAN message encapsulated into the PHB packet sent by the PHB master station is decapsulated, and the decapsulated CAN message is sent to the CAN bus.

Images