WO2023070238A1 - 访问车辆资源的方法、装置和车辆控制器 - Google Patents

访问车辆资源的方法、装置和车辆控制器 Download PDF

Info

Publication number
WO2023070238A1
WO2023070238A1 PCT/CN2021/125965 CN2021125965W WO2023070238A1 WO 2023070238 A1 WO2023070238 A1 WO 2023070238A1 CN 2021125965 W CN2021125965 W CN 2021125965W WO 2023070238 A1 WO2023070238 A1 WO 2023070238A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
vehicle
format
gateway module
vehicle controller
Prior art date
Application number
PCT/CN2021/125965
Other languages
English (en)
French (fr)
Inventor
丁喆
李双成
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2021/125965 priority Critical patent/WO2023070238A1/zh
Priority to CN202180097384.1A priority patent/CN117203637A/zh
Publication of WO2023070238A1 publication Critical patent/WO2023070238A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/151—Transformation

Definitions

  • the present application relates to the technical field of vehicle controllers, in particular to a method and device for accessing vehicle resources and a vehicle controller.
  • L2 level automatic driving refers to the partial automation of vehicle driving
  • IT Internet Technology
  • the electronic and electrical architecture of the vehicle shown in Figure 1A is transformed from a distributed electronic control unit (Electronic Control Unit, ECU) to a centralized centralized processing (for example, by high performance computing (High Performance Computing, HPC)); the communication backbone
  • ECU Electronic Control Unit
  • HPC High Performance Computing
  • the network has developed from traditional low-speed networks such as Controller Area Network (CAN) to high-speed networks such as automotive Ethernet (1000BASE-T1).
  • CAN Controller Area Network
  • automotive Ethernet 1000BASE-T1
  • the solid line represents the vehicle Ethernet connection
  • the dashed line represents the bus connection.
  • the topological link of the vehicle Ethernet is point-to-point communication, which is different from the traditional bus method, and the cross-node data transmission needs to add switching chips. If you want to access the Ethernet data between ECU1 and HPC, you need to disconnect the original direct connection between ECU1 and HPC, install the plug-in connector required by the professional equipment shown in Figure 1B, and then connect to the equipment. The introduction of professional testing equipment and the transformation of lines will bring high hardware costs.
  • the deserialization and serialization of the on-board Ethernet protocol data provided by the device requires the use of supporting software for professional test equipment.
  • the installation platform of supporting software is relatively single (such as a certain operating system).
  • the supporting software of professional test equipment and the closed environment created by a single installation platform bring additional software costs.
  • the embodiments of the present application provide a method, device and vehicle controller for accessing vehicle resources.
  • the first aspect of the present application provides a method for accessing vehicle resources, including: the vehicle controller receives first data from the vehicle sensor, the first data is data in a physical format of the vehicle sensor; The first data is converted into second data, and the second data is data in an external message format; the vehicle controller sends the second data to the outside.
  • the process of converting the first data into the second data by the vehicle controller includes: converting the first data into fifth data, where the fifth data is data in an internal message format; The fifth data is converted into the second data.
  • the physical format includes a binary sequence format.
  • the vehicle controller can obtain the capability of the vehicle sensor interface.
  • the external message format includes HTTP format.
  • the external can use the open IT ecological technology to access the internal data of the vehicle controller.
  • the second aspect of the present application provides a method for accessing vehicle resources, including: the vehicle controller receives third data from outside the vehicle; the third data is data in an external message format; the vehicle controller sends the third The data is converted into fourth data; the fourth data is data in a physical format of the vehicle actuator; the vehicle controller sends the fourth data to the vehicle actuator.
  • the third data based on the open external message format is obtained from the outside, and converted into the fourth data based on the physical format of the vehicle actuator to control the vehicle actuator, so as to control the vehicle or perform calibration through external debugging
  • the third data based on the open external message format is obtained from the outside, and converted into the fourth data based on the physical format of the vehicle actuator to control the vehicle actuator, so as to control the vehicle or perform calibration through external debugging
  • the process of the vehicle controller converting the third data into the fourth data includes: converting the third data into sixth data, where the sixth data is data in an internal message format; The fifth data is converted into the fourth data.
  • the physical format includes a binary sequence format.
  • the vehicle controller can obtain the capability of the vehicle actuator interface.
  • the external message format includes HTTP format.
  • the vehicle controller can receive external control using the open IT ecological technology.
  • the third aspect of the present application provides a device for accessing vehicle resources, including: an interface module and a gateway module; the interface module is used for receiving the first data of the vehicle sensor by the vehicle controller, and the first data is the vehicle sensor The data in the physical format; the gateway module is used for converting the first data into the second data by the vehicle controller; the second data is data in an external message format; the gateway module is also used for sending the second data to the outside by the vehicle controller.
  • the gateway module includes a southbound gateway module and a northbound gateway module; the southbound gateway module is used to convert the first data into fifth data; the fifth data is data in an internal message format; The northbound gateway module is used for converting the fifth data into the second data.
  • the physical format includes a binary sequence format.
  • the vehicle controller can obtain the capability of the vehicle sensor interface.
  • the external message format includes HTTP format.
  • the external can use the open IT ecological technology to access the internal data of the vehicle controller.
  • the fourth aspect of the present application provides a device for accessing vehicle resources, including: an interface module and a gateway module; the gateway module is used for the vehicle controller to receive third data from outside the vehicle; the third data is external Data in message format; the gateway module is also used to convert the third data into fourth data by the vehicle controller; the fourth data is data in the physical format of the vehicle actuator; the interface module is used to send the vehicle controller to the vehicle actuator Fourth data.
  • the third data based on the open external message format is obtained from the outside, and converted into the fourth data based on the physical format of the vehicle actuator to control the vehicle actuator, so as to control the vehicle or perform calibration through external debugging
  • the third data based on the open external message format is obtained from the outside, and converted into the fourth data based on the physical format of the vehicle actuator to control the vehicle actuator, so as to control the vehicle or perform calibration through external debugging
  • the gateway module includes a southbound gateway module and a northbound gateway module; the northbound gateway module is used to convert the third data into sixth data, and the sixth data is data in an internal message format; The gateway module is used to convert the sixth data into the fourth data.
  • the physical format includes a binary sequence format.
  • the vehicle controller can obtain the capability of the vehicle actuator interface.
  • the external message format includes HTTP format.
  • the vehicle controller can receive external control using the open IT ecological technology.
  • the fifth aspect of the present application provides a vehicle controller, including: the device according to any one of the third aspect; the device according to any one of the fourth aspect; a general interface unit; a centralized controller; wherein, the The interface module is deployed on the general interface unit, and the gateway module is deployed on the centralized controller.
  • the sixth aspect of the present application provides a computing device, including at least one processor and at least one memory, the memory stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor implements the first The method of any one of the first aspects or the method of any one of the second aspects.
  • the seventh aspect of the present application provides a computer-readable storage medium, on which program instructions are stored, and when the program instructions are executed by a computer, the computer implements the method of any one of the first aspect or any one of the second aspect. one method.
  • the eighth aspect of the present application provides a computer program product, which includes program instructions. When executed by a computer, the program instructions cause the computer to implement the method of any one of the first aspect or any one of the second aspect. method.
  • the embodiment of the present application achieves access to vehicle resources without introducing expensive professional testing equipment, and without modifying the original wiring harness, and using existing public IT technologies to access vehicle resources ecologically and conveniently.
  • FIG. 1A is a schematic diagram of the electrical and electronic architecture of a vehicle
  • FIG. 1B is a schematic structural diagram of accessing vehicle resources using professional equipment
  • Fig. 1C is a structural schematic diagram of using professional equipment to access vehicle resources through Ethernet;
  • FIG. 2A is a schematic structural diagram of an application scenario of an embodiment of the present application.
  • FIG. 2B is a schematic diagram of an application scenario of an embodiment of the present application.
  • FIG. 3A is a schematic flowchart of Embodiment 1 of a method for accessing vehicle resources of the present application
  • FIG. 3B is a schematic flowchart of Embodiment 2 of a method for accessing vehicle resources of the present application
  • FIG. 4A is a schematic flowchart of Embodiment 3 of a method for accessing vehicle resources of the present application
  • FIG. 4B is a schematic flowchart of Embodiment 4 of a method for accessing vehicle resources of the present application
  • Fig. 4C is a schematic diagram of the data of the method embodiment 3 and embodiment 4 of the present application.
  • Fig. 4D is a schematic diagram of the data conversion process of the method embodiment 3 and embodiment 4 of the present application.
  • FIG. 5 is a schematic structural diagram of Embodiment 1 of a device for accessing vehicle resources of the present application
  • FIG. 6A is a schematic structural diagram of an embodiment of the vehicle controller of the present application.
  • Fig. 6B is a schematic diagram of data conversion between the interface module and the southbound gateway module of the vehicle controller embodiment of the present application;
  • Fig. 6C is a schematic diagram of data conversion among the interface module, the southbound gateway module, and the northbound gateway module of the vehicle controller embodiment of the present application;
  • FIG. 7 is a schematic structural diagram of a computing device provided by an embodiment of the present application.
  • the solution for exchanging data between the vehicle controller and the outside includes an apparatus and method for exchanging data between the vehicle controller and the outside, a computing device, a computer-readable storage medium, and a computer program product. Since the principles of these technical solutions to solve problems are the same or similar, in the introduction of the following specific embodiments, some repetitions may not be repeated, but it should be considered that these specific embodiments have been referred to each other and can be combined with each other.
  • the vehicle controller is used to complete the control function of the whole vehicle or several functional domains.
  • the functional domains may include the fields of intelligent cockpit, body, and automatic driving, and may also include the sub-functional domains of the above functional domains.
  • the Versatile Interface Unit (VIU) is used to complete the connection of vehicle sensors and vehicle actuators in one functional domain of the vehicle.
  • the centralized controller (X domain Controller, XDC) is used to complete the control functions in one or more functional domains of the vehicle.
  • Hypertext Transfer Protocol (Hyper Text Transfer Protocol, HTTP), a network transfer protocol widely used on the Internet, is used to transfer hypertext from the World Wide Web (World Wide Web, WWW) server to the local browser transfer protocol, based on TCP/ IP communication protocol to transfer data.
  • HTTP Hyper Text Transfer Protocol
  • JS Object Notation (JSon), a lightweight data exchange format.
  • the data is stored and represented in a text format completely independent of the programming language.
  • the concise and clear hierarchical structure makes it an ideal data exchange language, which is easy to read and write for humans, and easy for machines to parse and generate, and effectively improves network transmission. efficiency.
  • Objectification which encapsulates the state of the target and the operations performed on the target state.
  • the vehicle sensor and vehicle execution are objectified in a service-oriented manner.
  • Fig. 1C shows a calibration measurement solution based on the Ethernet backbone network.
  • This solution includes a general interface unit 101 and a general interface unit 102, the general interface units 101 and 102 are responsible for the access of vehicle sensors and vehicle actuators in this functional domain; a centralized controller 104 is also shown, as well as professional test equipment 103 and its Corresponding supporting software 105 .
  • the original topology is that the general interface units 101 and 102 are directly connected to the centralized controller 104 to provide vehicle Ethernet protocol data services.
  • the engineer needs to configure the physical link to the professional test equipment 103 through the professional supporting software 105, and the physical link connection is successfully performed for data calibration measurement.
  • serialization and deserialization of vehicle Ethernet protocol data also require professional testing equipment to complete.
  • the hardware equipment cost of this calibration measurement scheme is high, and expensive professional testing equipment needs to be introduced, and the original wiring harness needs to be modified.
  • the software interface is not open, and the calibration status data requires professional supporting software for serialization and deserialization, and the existing IT technology cannot be used to access vehicle resources easily and ecologically.
  • the vehicle includes a vehicle controller 100 , sensors 130 and 132 , and an actuator 140 .
  • the vehicle controller 100 may be a whole vehicle controller, or a controller of a functional domain, such as a smart cockpit controller.
  • the vehicle controller 100 includes common interface units 110 and 112 , and a centralized controller 120 .
  • General interface units 110 and 112 are responsible for the access of vehicle sensors 130 and 132 and vehicle actuators 140 in this functional domain.
  • two general interface units are shown in FIG. 2A , and may actually contain multiple general interface units , each common interface unit can be an ECU.
  • the centralized controller 120 completes the control function of the entire vehicle, and can also complete the control function in one or more fields or the control function of a specific functional domain.
  • the centralized controller 120 can be an HPC or a multi-domain controller (Multi Domain Controller , MDC) or ECU.
  • the vehicle sensors 130 and 132 are used to collect data. As an example, two vehicle sensors are shown in FIG. 2A , which may actually include multiple vehicle sensors, which are respectively connected to the common interface units. Wherein, the vehicle sensor may include a vehicle speed sensor, a roll angle sensor, a distance sensor, a temperature sensor, a brightness sensor, a humidity sensor, a power sensor, and the like.
  • the vehicle actuator 140 is used to execute the control commands of the centralized controller 120.
  • Vehicle actuator As an example, one vehicle actuator is shown in FIG. 2A , but it may actually include multiple vehicle actuators, which are respectively connected to the common interface units. Vehicle actuators include electric motors, clutches, solenoid valves, switches, brake calipers for ABS, and more.
  • the external computer 150 communicates with the vehicle controller 100 to obtain the data collected by the vehicle sensors through the centralized controller 120 of the vehicle controller 100, and execute the The controller issues control commands.
  • the external computer can communicate with the vehicle controller 100 by wire or wirelessly.
  • the external computer can also be replaced by a device such as a tablet computer (PAD), a smart phone, or the like.
  • PAD tablet computer
  • Embodiment 1 and Embodiment 2 of a method for accessing vehicle resources provided by this application are introduced.
  • the methods in Embodiment 1 and Embodiment 2 can be run in the vehicle controller 100 shown in FIG. 2A .
  • the vehicle controller accesses the vehicle sensor or controls the vehicle actuator based on the data in the physical format, and interacts with the off-vehicle device based on the data in the open external message format, so that the off-vehicle device can access the vehicle resource , it is not necessary to add new equipment or modify the existing vehicle controller.
  • Fig. 3A shows the process of Embodiment 1 of the method for accessing vehicle resources.
  • the vehicle controller 100 obtains the first data based on the physical format of the vehicle sensor from the vehicle sensor, and converts the first data based on the open external message format. The data is sent to the outside.
  • This embodiment includes steps S310A to S330A.
  • the vehicle controller 100 receives first data from the vehicle sensor.
  • the first data is data in a physical format of the vehicle sensor.
  • the data in the physical format includes binary sequence data. In other embodiments, the data in physical format includes hexadecimal or octal sequence data.
  • the vehicle controller 100 receives the first data of the vehicle sensor through the universal interface unit.
  • the general interface unit may be implemented by an ECU included in the vehicle controller 100 .
  • the interface unit of the vehicle controller 100 communicates with the vehicle sensor through a universal bus protocol to acquire the first data of the vehicle sensor.
  • the general bus protocol may include CAN bus protocol, high-speed CAN bus protocol, FlexRay protocol, Time Triggered Protocol (Time Triggered Protocol, TTP), Vehicle Area Network (Vehicle Area network, VAN) protocol, or local Internet (Local Interconnect Network, LIN) bus protocol, etc.
  • the vehicle controller 100 transmits the first data from the common interface unit to the centralized controller 120 using an internal communication protocol.
  • the internal communication protocol may be a vehicle Ethernet protocol (Ethernet), and may also be a vehicle area network (Vehicle Area network, VAN) protocol, a local interconnect network (Local Interconnect Network, LIN) protocol, and the like.
  • VAN Vehicle Area network
  • LIN Local Interconnect Network
  • S320A The vehicle controller 100 converts the first data into the second data.
  • the second data is data in an external message format.
  • the data in the external message format includes data in the HTTP format. Since HTTP is a network transmission protocol widely used on the Internet, the data based on the HTTP format is more versatile, and it is convenient for various external devices to receive and process the data based on the HTTP format. In some other embodiments, the format of the external message may also be data in FTP protocol format, etc.
  • the second data is structured data based on JSon.
  • JSON-based structured data is easy to read and write for humans, and easy for machines to parse and generate, and can effectively improve network transmission efficiency.
  • the structured data may also be based on XML (XML is an Extensible Markup Language), Protobuf (Protobuf is a data exchange format), Flatbuffer (Flatbuffer is a data exchange format) and so on.
  • the first data and the second data use the same service-oriented template structure.
  • the vehicle controller 100 converts the first data into the second data through the centralized controller 120 . In some embodiments, the vehicle controller 100 may also convert the data through other controllers, such as any ECU on the vehicle.
  • the data based on the open external message format is sent out through the vehicle controller, without special third-party test equipment, and without modifying the internal circuit of the vehicle controller, and the data of the vehicle sensor can be transmitted to the external device.
  • this step specifically includes: converting the first data into fifth data, where the fifth data is data in an internal message format. And, converting the fifth data into the second data.
  • the first data and the fifth data use the same service-oriented template structure.
  • S330A The vehicle controller 100 sends the second data to the outside.
  • the vehicle controller 100 sends out the second data through the centralized controller 120 .
  • the vehicle controller 100 can send the second data to the external device through the centralized controller 120 through wired transmission or wireless transmission.
  • the external device may be a general computer system, a tablet computer (PAD), a smart phone, and the like.
  • the second data adopts Chunked Transfer Encoding (Chunked), which is convenient for multiplexing the link of the second data.
  • Fig. 3B shows the flow of the second embodiment of the method for accessing vehicle resources.
  • the vehicle controller obtains the third data based on the open external message format from the outside, and converts it into the fourth data based on the physical format of the vehicle actuator. data to control vehicle actuators.
  • the embodiment will be described in detail below with reference to FIG. 3B , and the embodiment includes steps S310B to S330B.
  • S310B The vehicle controller 100 receives third data from outside the vehicle.
  • the third data is data in an open external message format.
  • the data in the external message format includes data in the HTTP format, or data in the FTP protocol format.
  • data in the HTTP format or data in the FTP protocol format.
  • the relevant description of the external message format in step S320A refer to the relevant description of the external message format in step S320A.
  • the third data is structured data based on JSon, and may also be based on XML, Protobuf, Flatbuffer, etc.
  • JSon structured data based on JSon
  • XML XML
  • Protobuf Protobuf
  • Flatbuffer Flatbuffer
  • the vehicle controller 100 receives the third data from an external device outside the vehicle through the centralized controller 120 . Wherein, it may be received through wired transmission or wireless transmission.
  • the vehicle controller 100 converts the third data into fourth data.
  • the fourth data is data in a physical format of the vehicle actuator.
  • the data in the physical format includes binary sequence data, and may also be hexadecimal or octal sequence data, etc., and the format of the fourth data may be based on the physical format supported by the actuator.
  • the third data and the fourth data use the same service-oriented template structure.
  • the vehicle controller 100 converts the third data into fourth data through the centralized controller 120 . In some embodiments, the vehicle controller 100 may also convert the data through other controllers, such as any ECU on the vehicle.
  • the vehicle controller receives external data based on the open external message format and converts it into data in the physical format of the vehicle actuator. There is no need for special third-party test equipment, and there is no need to modify the internal circuit of the vehicle controller. It can receive external general data. data sent by the computer system.
  • this step specifically includes: converting the third data into sixth data, where the sixth data is data in an internal message format. And, convert the sixth data into the fourth data.
  • the sixth data and the fourth data use the same service-oriented template structure.
  • S330B The vehicle controller sends fourth data to the vehicle actuator 140 .
  • the vehicle controller 100 sends the fourth data from the centralized controller 120 to the universal interface unit using an internal communication protocol.
  • the internal communication protocol may be a vehicle Ethernet protocol (Ethernet), and may also be a vehicle area network (Vehicle Area network, VAN) protocol, a local interconnect network (Local Interconnect Network, LIN) protocol, and the like.
  • the vehicle controller 100 sends the fourth data to the actuator 140 through the universal interface unit.
  • the general interface unit may be implemented by an ECU included in the vehicle controller 100 .
  • the interface unit of the vehicle controller 100 communicates with the actuator through a universal bus protocol, and sends the fourth data to the actuator.
  • the general bus protocol may include CAN bus protocol, high-speed CAN bus protocol, FlexRay protocol, Time Triggered Protocol (Time Triggered Protocol, TTP), vehicle area network (Vehicle Area network, VAN) protocol, or local Internet (Local Interconnect Network, LIN) bus protocol, etc.
  • the procedure of the first embodiment of the above-mentioned method for accessing vehicle resources and the procedure of the second embodiment of the method are separately executed to collect data from vehicle sensors or control vehicle actuators.
  • the process of the first embodiment of the method for accessing vehicle resources is performed first, and then the process of the second embodiment of the method for accessing vehicle resources is performed, such as being applied to the data calibration process.
  • the process of the first embodiment of the above method for accessing vehicle resources and the process of the second embodiment of the above method for accessing vehicle resources are repeatedly and alternately run, such as being applied to a troubleshooting process or a debugging process.
  • the above-mentioned embodiment of the method for accessing vehicle resources collects the first data based on the physical format of the vehicle sensor from the vehicle sensor, and converts it into data based on an open external message format and sends it to the outside;
  • the third data is transformed into fourth data based on the physical format of the vehicle actuators to control the vehicle actuators.
  • the above embodiments of the method for accessing vehicle resources do not require the introduction of expensive professional testing equipment, nor the need to modify the original wiring harness, and use the existing public IT technology to access vehicle resources ecologically and conveniently.
  • the embodiment of the present application also provides the third and fourth embodiments of a method for accessing vehicle resources, and the third and fourth embodiments of the method will be described below with reference to the accompanying drawings.
  • Embodiment 3 and Embodiment 4 of this method are executed by the vehicle controller 100 shown in FIG. 2A , based on the physical format data of the binary sequence to access the vehicle sensor or control the vehicle actuator through the vehicle controller 100, and externally based on the data in the open HTTP format Interact with the outside to achieve access to vehicle resources without adding new equipment and without modifying the wiring harness of the existing vehicle controller. At the same time, it is interconnected with the system outside the vehicle through the existing IT ecological technology.
  • Figure 4A shows the process of the third embodiment of the method.
  • the general interface unit collects the first data in the physical format of the vehicle sensor from the vehicle sensor (for the convenience of description, it is subsequently referred to as state data in this example)
  • Send to centralized controller 120 and centralized controller 120 generates the 5th data of internal message format (for convenience of description, follow-up is referred to as the second status message in this example) according to state data first, then generates open HTTP according to the second status message
  • the second data in the format (for convenience of description, subsequently referred to as the first status message in this example) to be sent to the external computer 150, including steps S410A to S440A;
  • Fig. 4B shows the process of the fourth embodiment of the method.
  • the centralized controller 120 receives the third data in the open HTTP format from the external computer (for the convenience of description, it is subsequently referred to as the first data in this example). command message), the centralized controller 120 generates the sixth data according to the first command message (for the convenience of description, it is subsequently called the second command message in this example), and then generates the fourth data based on the physical format of the actuator according to the second command message (For the convenience of description, it will be referred to as a control command later in this example), and send it to the general interface unit, and the general interface unit sends the received control command to the vehicle actuator to control the vehicle, including steps S410B to S440B.
  • S410A The general interface unit of the vehicle controller 100 obtains the status data and sends it to the centralized controller 120 thereof.
  • the state data is the binary sequence data in the physical format of the relevant state collected by the vehicle sensor.
  • the vehicle controller 100 collects data from vehicle sensors through a service-oriented architecture application programming interface (Service-Oriented Architecture Application Programming Interface, SOA API), generates state data content based on a service-oriented template, and adds relevant service type identification and the data type identification to generate state data, wherein the data type identification of the state data is a data identification.
  • SOA API Service-Oriented Architecture Application Programming Interface
  • the state data is transmitted through the internal communication protocol between the general interface unit and the centralized controller 120 .
  • S420A The centralized controller 120 of the vehicle controller 100 receives the status data, and generates an objectified second status message accordingly.
  • the second status message is data in an object-oriented internal message format, which is convenient for subscription application programs (Application, APP) inside the centralized controller 120 to use.
  • Application Application, APP
  • the template structure of the content of the second status message is the same as that of the status data, which is a service-oriented template structure.
  • S430A The centralized controller 120 of the vehicle controller 100 converts the second status message into the first status message.
  • the first state message is JSon structured data based on HTTP format, which is in the Representational State Transfer (REST) style, and is convenient for the external computer 150 to use through the open IT technology ecology.
  • REST Representational State Transfer
  • the template structure of the content of the first status message is the same as the template structure of the content of the status data.
  • S440A The centralized controller 120 of the vehicle controller 100 converts and sends the second status message to the outside.
  • the first status message when the first status message is periodic data, the first status message adopts block transfer coding, which is convenient for multiplexing the link of the first status message.
  • S410B The centralized controller 120 of the vehicle controller 100 receives a first command message from outside the vehicle.
  • the first command message is JSon structured data based on HTTP format, which is convenient for receiving commands from the external computer 150 through an open IT ecological technology.
  • S420B The centralized controller 120 of the vehicle controller 100 converts the first command message into a second command message.
  • the second command message is data in the internal message format of the object structure, which is convenient for use inside the centralized controller 120 .
  • the template structure of the content of the second command message is the same as the template structure of the content of the first command message, which is a service-oriented template structure.
  • S430B The centralized controller 120 of the vehicle controller 100 serializes the second command message to generate a binary sequence of control commands.
  • the format of the control command is the physical format of the vehicle actuator.
  • the template structure of the content of the second command message is the same as the template structure of the content of the control command.
  • S440B The general interface unit of the vehicle controller 100 obtains the control command, and sends the command to generate the vehicle actuator to the vehicle actuator.
  • the state data is transmitted through the internal communication protocol between the general interface unit and the centralized controller 120 .
  • the general interface unit sends commands to the vehicle actuators through SOA API.
  • Fig. 4C shows the data of three types of services, from bottom to top, they are status data and control data in physical format, second status message and second command message in internal message format, first status in HTTP format message and first command message.
  • the service type is Service DoorLock.
  • the data in the lower box in the figure is data in physical format, and the service type is identified as SID 0x1001, including the status data of the car door status and the control commands of the car door.
  • the data type of the state data is identified as Event 0x0001, and Event represents the state data, and the content of the state data includes the left door state (flClockStatus) and the right door state (frClockStatus);
  • the data type of the control command is identified as Method 0x0002, and Method represents the control command , the content of the control command includes the left door control command (clockMotorCmd_L) and the right door control command (clockMotorCmd_R).
  • the data in the middle box in the figure is the data in the internal message format.
  • Topic DoorLock is the second status message, and its content is consistent with the Event content of Service DoorLock, including the status of the left door (flClockStatus) and the status of the right door (frClockStatus);
  • DoorLock is the second command message, and its content is consistent with the method content of the control command Service DoorLock, including the left door control command (clockMotorCmd_L) and the right door control command (clockMotorCmd_R).
  • the data in the upper box of the figure is JSon structured data in HTTP format.
  • RI:GET DoorLock is the first status message to obtain the door status
  • GET means to obtain and the obtained DoorLock content includes the left door status in Topic DoorLock (flClockStatus ) and the right door status (frClockStatus)
  • URI: PUT DoorLock is the first command message for sending the door control, PUT means sending, and the content of the sent DoorLock includes the left door control command (clockMotorCmd_L) and the right door control command ( clockMotorCmd_R).
  • the middle text in Figure 4C is Lighting Service (Service ExteriorLinght), and its service type is identified as SID0x1002. It includes the lighting control command, the second command message and the first command message from bottom to top. The contents of the three are consistent and will not be described in detail.
  • the text on the right side in Figure 4C is Ultrasound Radar Service (Service Ultrasound), and its service type is identified as SID 0x1003, which includes status data, second status message and first status message of ultrasonic radar from bottom to top, and the contents of the three are consistent. No more detailed description.
  • Fig. 4D shows the data conversion relationship of the method embodiment 3 and embodiment 4, including: the status data of the binary sequence in the physical format of the sensor is deserialized, and converted into the objectified first in the internal message format of the vehicle controller. Two status messages, and then converted to the first status message in the JSon structured HTTP format; and the JSon structured HTTP format data is converted into an object-oriented second command message in the internal message format, and then serialized into a physical format Binary sequence of control commands.
  • method embodiment 3 and embodiment 4 collect the status data of the vehicle sensor in physical format from the vehicle sensor, convert it into the second status message in the internal message format, and then convert the second status message into the first status in the open HTTP format Message, to send to external computer 150; Receive the first command message of open HTTP format from external computer), centralized controller 120 is converted into the second command message of internal message format according to the first command message, and then according to the second command The messages generate control commands in the physical format of the actuators and send them to the common interface unit to control the vehicle.
  • Method Embodiment 3 and Embodiment 4 do not need to introduce expensive professional testing equipment, and do not need to modify the original wiring harness, and use the existing public IT technology to access vehicle resources easily and conveniently.
  • the internal message format generated in the middle The second status message or/and the second command message are convenient for internal use by the vehicle controller.
  • Embodiment 1 of an apparatus for accessing vehicle resources provides Embodiment 1 of an apparatus for accessing vehicle resources, and the apparatus can be used to implement the solutions of the various embodiments of the above-mentioned method for accessing vehicle resources.
  • FIG. 5 shows the structure of Embodiment 1 of the device, which includes an interface module 510 and a gateway module 520 .
  • the interface module 510 executes the above step S310A and the optional embodiments of the step, for receiving the first data of the vehicle sensor by the vehicle controller 100; and also executes the above step S330B and the optional embodiments of the step, for the vehicle controller 100 to receive the first data of the vehicle sensor; The vehicle controller 100 transmits fourth data.
  • the first data is the data of the physical format of the vehicle sensor
  • the fourth data is the data of the physical format of the vehicle actuator
  • the data in physical format includes binary sequence data.
  • the interface module 510 is deployed on the general interface unit of the vehicle controller 100 shown in FIG. 2A .
  • the gateway module 520 executes the above steps S320A and S330A and the optional embodiments of these two steps, for the vehicle controller 100 to convert the first data into the second data and send the second data to the outside; also execute the above steps S310B and S320B and the optional embodiments of the two steps are used for the vehicle controller 100 to receive the third data from outside the vehicle and convert the third data into fourth data.
  • the second data and the third data are data in an external message format.
  • the external message-formatted data includes HTTP-based formatted data.
  • the second data and the third data are JSon-based structured data.
  • the first data and the second data use the same service-oriented template.
  • the third data and the fourth data use the same service-oriented template.
  • the gateway module 520 communicates with the interface module 510 using an existing internal protocol of the vehicle controller 100 .
  • the gateway module 520 is deployed on the centralized controller 120 of the vehicle controller 100 shown in FIG. 2A ,
  • the gateway module 520 includes a southbound gateway module 521 and a northbound gateway module 522 .
  • the southbound gateway module 521 is used for converting the first data into fifth data by the vehicle controller 100
  • the northbound gateway module 522 is also used for converting the fifth data into second data by the vehicle controller 100
  • the fifth data is data in an internal message format.
  • the northbound gateway module 522 is also used for converting the third data into sixth data by the vehicle controller 100, and the southbound gateway module 521 is also used for converting the sixth data into fourth data by the vehicle controller 100, wherein the sixth data Data in internal message format.
  • the embodiment of the present application also provides a vehicle controller, which can be used to implement the solutions of the various embodiments of the above method for accessing vehicle resources.
  • Fig. 6A shows the structure of the vehicle controller embodiment, and this vehicle controller embodiment comprises each common interface unit (for example, comprises common interface unit 110 and 112) and a centralized controller 120, and each common interface unit also comprises interface Module 510, the centralized controller 120 includes a southbound gateway (South Gateway) module 521 and a northbound gateway (North Gateway) module 522.
  • each common interface unit for example, comprises common interface unit 110 and 112
  • each common interface unit also comprises interface Module 510
  • the centralized controller 120 includes a southbound gateway (South Gateway) module 521 and a northbound gateway (North Gateway) module 522.
  • the interface module 510 is used to provide the SOA API to the vehicle controller 100, and open the capabilities of the vehicle sensors (including the vehicle sensors 130 and 132) and the vehicle actuators (including the vehicle actuator 140).
  • the interface module 510 executes the above step S410A and the optional embodiments of this step to obtain state data from the vehicle sensor, and also executes the above step S440B and the optional embodiments of this step to send control commands to the vehicle actuators.
  • the interface provided by the interface module 510 is SOMEIP middleware.
  • the interface provided by the interface module 510 is a service-oriented middleware of other communication methods.
  • the state data is the binary sequence data in the physical format of the vehicle sensor
  • the control command is the binary sequence data in the physical format of the vehicle actuator
  • the status data and control commands are based on a service-oriented template structure, and the template includes service type identification, data type identification and content, wherein the data type identification of the status data is a data identification, and the data type identification of a control command is a command identification.
  • the southbound gateway module 521 executes the above step S420A and the optional embodiments of this step, and is used to deserialize the status data received from the interface module 510 and convert it into an objectified second status message for the centralized controller
  • the internal APP of 120 uses or sends through the northbound gateway module 522.
  • the southbound gateway module 521 also executes the above step S430B and the optional embodiments of this step, for serializing the objectified second command message received from the northbound gateway module 522 or the APP inside the centralized controller 120, and converting It is a binary control command to be sent to the interface module 510 .
  • the communication between the southbound gateway module 521 and the interface module 510 is performed through an internal protocol of the vehicle controller, for example, based on IP.
  • the second status message and the second command message are in the internal message format of the vehicle controller, which is convenient for the APP subscribed inside the centralized controller to use.
  • the template structure of the content of the second status message is the same as that of the status data; the template structure of the content of the second command message is the same as that of the control command.
  • FIG. 6B shows the data conversion between the southbound gateway module 521 and the interface module 510 by taking the door lock service as an example.
  • the second status message of the centralized controller 120 internal message format defined by the southbound gateway module 521 in Fig. 6B is Topic DoorLock, and its content is consistent with the status data of the interface module 510, that is, the content of the Event of Service DoorLock, including the left door status (flClockStatus) and the right door status (frClockStatus), so that the southbound gateway module 521 deserializes the Event data of the corresponding Service DoorLock received from the interface module 510 according to the same template structure, and converts it into a Topic DoorLock in an object-oriented internal message format, It is convenient for the internal APP of the centralized controller 120 to subscribe or send to the northbound gateway module 522 .
  • the second command message of the centralized controller 120 defined by the southbound gateway module 521 is Service DoorLock, and its content is consistent with the control command of the interface module 510, that is, the content of the Method of Service DoorLock, including the left door control command (clockMotorCmd_L) and the right door control command (clockMotorCmd_R), so that the southbound gateway module 521 serializes the Service DoorLock received from the internal APP or the northbound gateway module 522 according to the same template structure, and generates the control command in the physical format of the vehicle actuator to The vehicle is controlled through the interface module 510 .
  • the southbound gateway module 521 serializes the Service DoorLock received from the internal APP or the northbound gateway module 522 according to the same template structure, and generates the control command in the physical format of the vehicle actuator to The vehicle is controlled through the interface module 510 .
  • the northbound gateway module 522 executes the above-mentioned steps S430A and S440A and the optional embodiments of the two steps, for converting the second status message received from the southbound gateway module 521 into a first status message in HTTP format, and sending the status message to the external computer 150 sent.
  • the northbound gateway module 522 also executes the above steps S410B and S420B and the optional embodiments of the two steps, for converting the first command message in HTTP format received from the external computer 150 into a second command message.
  • the first status message and the first command message are in the HTTP format widely used in the IT industry, and are in the REST style, so that the external computer 150 can be used by the open IT ecological technology.
  • the first status message and the first command message are structured data represented by JS objects, so as to further facilitate the use of the external computer 150 .
  • the template structure of the content of the first status message is the same as the template structure of the content of the status data.
  • the first status message when the first status message is periodic data, the first status message adopts block transfer coding, which is convenient for multiplexing the link of the first status message.
  • Fig. 6C shows the data conversion relationship between the northbound gateway module 522, the southbound gateway module 521 and the interface module 510 by taking the door lock service as an example, and the data conversion relationship between the southbound gateway module 521 and the interface module 510 The relationship has been introduced in FIG. 6B , and the data conversion between the northbound gateway module 522 and the southbound gateway module 521 will be described below.
  • Fig. 6C shows the data conversion relationship between the northbound gateway module 522, the southbound gateway module 521 and the interface module 510 by taking the door lock service as an example, and the data conversion relationship between the southbound gateway module 521 and the interface module 510 The relationship has been introduced in FIG. 6B , and the data conversion between the northbound gateway module 522 and the southbound gateway module 521 will be described below.
  • the first status message defined by the northward gateway module 522 is URI:GET DoorLock, and its content is JSon structured data based on the HTTP format, wherein GET means acquisition, and the acquired DoorLock content includes the topic defined by the southbound gateway module 521
  • GET means acquisition
  • the acquired DoorLock content includes the topic defined by the southbound gateway module 521
  • the left door status (flClockStatus) and the right door status (frClockStatus) in the DoorLock have thus just completed the data from the vehicle sensor, to the interface module 510, to the southbound gateway module 521, to the northbound gateway module 522, and finally to the external computer 150 A logical chain of mappings. Simultaneously in Fig.
  • the first command message received by the northward gateway module 522 is URI:PUT DoorLock, and its content is JSon structured data based on the HTTP format, wherein, PUT means sending, and the content of the DoorLock sent includes the southward gateway module 521
  • the left door control command (clockMotorCmd_L) and the right door control command (clockMotorCmd_R) in the defined Service DoorLock have like this completed from external computer 150, to northbound gateway module 522, to southbound gateway module 521, to interface module 510, finally A logical chain of data mappings to vehicle actuators.
  • FIG. 7 is a schematic structural diagram of a computing device 700 provided by an embodiment of the present application.
  • the computing device 700 includes: a processor 710 , a memory 720 , and a communication interface 730 .
  • the communication interface 730 in the computing device 700 shown in FIG. 7 can be used to communicate with other devices.
  • the processor 710 may be connected to the memory 720 .
  • the memory 720 can be used to store the program codes and data. Therefore, the memory 720 may be a storage module inside the processor 710, or an external storage module independent of the processor 710, or may include a storage module inside the processor 710 and an external storage module independent of the processor 710. part.
  • the processor 710 may use a central processing unit (central processing unit, CPU).
  • the processor can also be other general-purpose processors, digital signal processors (digital signal processors, DSPs), application specific integrated circuits (application specific integrated circuits, ASICs), field programmable gate arrays (field programmable gate arrays, FPGAs) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • a general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.
  • the processor 710 adopts one or more integrated circuits for executing related programs, so as to realize the technical solutions provided by various embodiments of the present application.
  • the memory 720 may include read-only memory and random-access memory, and provides instructions and data to the processor 710 .
  • a portion of processor 710 may also include non-volatile random access memory.
  • processor 710 may also store device type information.
  • the processor 710 executes computer-implemented instructions in the memory 720 to perform the operation steps of the above method.
  • the computing device 700 may correspond to a corresponding body executing the methods according to the various embodiments of the present application, and the above-mentioned and other operations and/or functions of the modules in the computing device 700 are for realizing the present invention
  • the corresponding processes of the methods in the application embodiments are not repeated here.
  • the disclosed systems, devices and methods may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.
  • the functions described above are realized in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of the present application is essentially 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, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disc and other media that can store program codes. .
  • the embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and the program is used to execute at least one of the solutions described in the various embodiments of the present application when executed by a processor.
  • the computer storage medium in the embodiments of the present application may use any combination of one or more computer-readable media.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination thereof. More specific examples (non-exhaustive list) of computer readable storage media include: electrical connections with one or more leads, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), Erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above.
  • a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
  • a computer readable signal medium may include a data signal in baseband or propagated as part of a carrier wave with computer readable program code embodied therein. Such propagated data signals may take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • a computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. .
  • 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.
  • Computer program code for performing the operations of the present application may be written in one or more programming languages or combinations thereof, including object-oriented programming languages—such as Java, Smalltalk, C++, and conventional Procedural Programming Language - such as "C" or a similar programming language.
  • the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
  • the remote computer can be connected to the user computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (such as through the Internet using an Internet service provider). connect).
  • LAN local area network
  • WAN wide area network
  • connect such as AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.

Abstract

本申请涉及车辆控制器技术领域，本申请实施例提供了一种访问车辆资源的方法和装置以及车辆控制器，包括：车辆控制器接收车辆传感器的第一数据，所述第一数据为所述车辆传感器的物理格式的数据；所述车辆控制器将所述第一数据转换为第二数据；所述第二数据为外部消息格式的数据；所述车辆控制器向外发送所述第二数据。本申请的方案无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地访问车载资源。

Description

访问车辆资源的方法、装置和车辆控制器 技术领域
本申请涉及车辆控制器技术领域，尤其涉及访问车辆资源的方法、装置和车辆控制器。
背景技术
如今的车辆都配备了多项高级自动驾驶辅助功能，自动驾驶水平达到了L2级(L2级的自动驾驶指车辆驾驶实现部分的自动化)或者更高的水平，车辆技术的进化和变革浪潮从未停止。在智能互联、自动驾驶、共享出行、电力驱动的变革中，车辆行业与其他行业(例如互联网技术(Internet Technology，IT)行业等)不断融合，其核心技术将发生较大改变。
为了应对这些变化，如图1A示出的车辆电子电气架构由分布式电子控制单元(Electronic Control Unit，ECU)向中央集中处理(例如由高性能计算(High Performance Computing，HPC))转变；通信骨干网由传统的控制器局域网络(Controller Area Network,CAN)等低速网络发展为车载以太网(1000BASE-T1)等高速网络。图1A中实线表示车载以太网连接，虚线表示总线连接。
整车设备装备完毕后，工程师如要在系统外部访问车辆设备提供的数据资源进行测试(如标定测量)会变得困难。例如，车载以太网的拓扑链接是点对点通信，和传统总线方式不同，跨节点数据传输需要加入交换芯片。如要访问ECU1和HPC之间的以太网数据，需要断开原有的ECU1和HPC之间的直连方式，安装图1B示出的专业设备要求的接插件连接器后再接入设备。专业测试设备的引入以及改造线路会带来高昂的硬件成本。
另一方面，对设备提供的车载以太协议数据进行反序列化以及序列化需要使用专业测试设备的配套软件。且配套软件的安装平台比较单一(如某操作系统)。专业测试设备的配套软件以及单一的安装平台所制造的封闭的环境带来了额外的软件成本。
发明内容
有鉴于此，本申请实施例提供了一种访问车辆资源的方法、装置和车辆控制器。
为达到上述目的，本申请的第一方面提供一种访问车辆资源的方法，包括：车辆控制器接收车辆传感器的第一数据，第一数据为车辆传感器的物理格式的数据；车辆控制器将第一数据转换为第二数据，第二数据为外部消息格式的数据；车辆控制器向外发送第二数据。
由上，通过把车辆传感器的物理格式的第一数据转化为基于开放的外部消息格式的第二数据而向外部发送，从而在外部访问车辆资源时无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地访问车载资源。
作为第一方面的一种可能的实施方式，车辆控制器将第一数据转换为第二数据的流程包括：将第一数据转换为第五数据，第五数据为内部消息格式的数据；将第五数据转换为第二数据。
由上，通过把车辆传感器的物理格式的第一数据转化为基于内部消息格式的第五数据，从而便于车辆传感器内部使用。
作为第一方面的一种可能的实施方式，物理格式包括二进制序列的格式。
由上，通过使用与车辆传感器物理层匹配的二进制序列格式采集第一数据，使车辆控制器获得车辆传感器接口的能力。
作为第一方面的一种可能的实施方式，外部消息格式包括HTTP格式。
由上，通过使用HTTP格式作为外部消息格式，使外部可以使用开放IT生态技术访问车辆控制器的内部数据。
为达到上述目的，本申请的第二方面提供一种访问车辆资源的方法，包括：车辆控制器接收来自车外的第三数据；第三数据为外部消息格式的数据；车辆控制器将第三数据转换为第四数据；第四数据为车辆执行器的物理格式的数据；车辆控制器向车辆执行器发送第四数据。
由上，通过从外部获取基于开放的外部消息格式的第三数据，并转化为基于车辆执行器的物理格式的第四数据以对车辆执行器进行控制，从而通过外部调试控制车辆或进行标定时无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地进行调试或标定。
作为第二方面的一种可能的实施方式，车辆控制器将第三数据转换为第四数据的过程包括：将第三数据转换为第六数据，第六数据为内部消息格式的数据；将第五数据转换为第四数据。
由上，通过把外部消息格式的第三数据转化为基于内部消息格式的第六数据，从而便于车辆传感器内部使用。
作为第二方面的一种可能的实施方式，物理格式包括二进制序列的格式。
由上，通过使用与车辆传执行器物理层匹配的二进制序列格式发送第四数据，使车辆控制器获得车辆执行器接口的能力。
作为第二方面的一种可能的实施方式，外部消息格式包括HTTP格式。
由上，通过使用HTTP格式作为外部消息格式，使车辆控制器可以使用开放IT生态技术接收外部的控制。
为达到上述目的，本申请的第三方面提供一种访问车辆资源的装置，包括：接口模块和网关模块；接口模块用于由车辆控制器接收车辆传感器的第一数据，第一数据为车辆传感器的物理格式的数据；网关模块用于由车辆控制器将第一数据转换为第二数据；第二数据为外部消息格式的数据；网关模块还用于由车辆控制器向外发送第二数据。
由上，通过把车辆传感器的物理格式的第一数据转化为基于开放的外部消息格式的第二数据而向外部发送，从而在外部访问车辆资源时无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地访问车载资源。
作为第三方面的一种可能的实施方式，网关模块包括南向网关模块和北向网关模块；南向网关模块用于将第一数据转换为第五数据；第五数据为内部消息格式的数据；北向网关模块用于将第五数据转换为第二数据。
由上，通过把车辆传感器的物理格式的第一数据转化为基于内部消息格式的第五数据，从而便于车辆传感器内部使用。
作为第三方面的一种可能的实施方式，物理格式包括二进制序列的格式。
由上，通过使用与车辆传感器物理层匹配的二进制序列格式采集第一数据，使车辆控制器获得车辆传感器接口的能力。
作为第三方面的一种可能的实施方式，外部消息格式包括HTTP格式。
由上，通过使用HTTP格式作为外部消息格式，使外部可以使用开放IT生态技术访问车辆控制器的内部数据。
为达到上述目的，本申请的第四方面提供一种访问车辆资源的装置，包括：接口模块和网关模块；网关模块用于由车辆控制器接收来自车外的第三数据；第三数据为外部消息格式的数据；网关模块还用于由车辆控制器将第三数据转换为第四数据；第四数据为车辆执行器的物理格式的数据；接口模块用于由车辆控制器向车辆执行器发送第四数据。
由上，通过从外部获取基于开放的外部消息格式的第三数据，并转化为基于车辆执行器的物理格式的第四数据以对车辆执行器进行控制，从而通过外部调试控制车辆或进行标定时无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地进行调试或标定。
作为第四方面的一种可能的实施方式，网关模块包括南向网关模块和北向网关模块；北向网关模块用于将第三数据转换为第六数据，第六数据为内部消息格式的数据；南向网关模块用于将第六数据转换为第四数据。
由上，通过把外部消息格式的第三数据转化为基于内部消息格式的第六数据，从而便于车辆传感器内部使用。
作为第四方面的一种可能的实施方式，物理格式包括二进制序列的格式。
由上，通过使用与车辆传执行器物理层匹配的二进制序列格式发送第四数据，使车辆控制器获得车辆执行器接口的能力。
作为第四方面的一种可能的实施方式，外部消息格式包括HTTP格式。
由上，通过使用HTTP格式作为外部消息格式，使车辆控制器可以使用开放IT生态技术接收外部的控制。
为达到上述目的，本申请的第五方面提供一种车辆控制器，包括：第三方面任一项的装置；第四方面任一项的装置；通用接口单元；集中控制器；其中，所述接口模块部署在通用接口单元上，所述网关模块部署于集中控制器上。
为达到上述目的，本申请的第六方面提供一种计算设备，包括至少一个处理器和至少一个存储器，存储器存储有程序指令，程序指令当被至少一个处理器执行时使得至少一个处理器实现第一方面任一项的方法或第二方面任一项的方法。
为达到上述目的，本申请的第七方面提供一种计算机可读存储介质，其上存储有程序指令，程序指令当被计算机执行时使得计算机实现第一方面任一项的方法或第二 方面任一项的方法。
为达到上述目的，本申请的第八方面提供一种计算机程序产品，其包括有程序指令，程序指令当被计算机执行时使得计算机实现第一方面任一项的方法或第二方面任一项的方法。
综上，本申请实施例实现了访问车辆资源是无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地访问车载资源。
本申请的这些和其它方面在以下(多个)实施例的描述中会更加简明易懂。
附图说明
以下参照附图来进一步说明本申请的各个特征和各个特征之间的联系。附图均为示例性的，一些特征并不以实际比例示出，并且一些附图中可能省略了本申请所涉及领域的惯常的且对于本申请非必要的特征，或是额外示出了对于本申请非必要的特征，附图所示的各个特征的组合并不用以限制本申请。另外，在本说明书全文中，相同的附图标记所指代的内容也是相同的。具体的附图说明如下：
图1A为车辆电子电气架构示意图；
图1B为使用专业设备的访问车辆资源的结构示意图；
图1C为使用专业设备通过以太网访问车辆资源的结构示意图；
图2A为本申请实施例应用场景的结构示意图；
图2B为本申请实施例应用场景的示意图；
图3A为本申请的一种访问车辆资源的方法实施例一的流程示意图；
图3B为本申请的一种访问车辆资源的方法实施例二的流程示意图；
图4A为本申请的一种访问车辆资源的方法实施例三的流程示意图；
图4B为本申请的一种访问车辆资源的方法实施例四的流程示意图；
图4C为本申请的方法实施例三、实施例四的数据示意图；
图4D为本申请的方法实施例三、实施例四的数据转化过程示意图；
图5为本申请的一种访问车辆资源的装置实施例一的结构示意图；
图6A为本申请的车辆控制器实施例的结构示意图；
图6B为本申请的车辆控制器实施例的接口模块与南向网关模块数据转化示意图；
图6C为本申请的车辆控制器实施例的接口模块、南向网关模块、北向网关模块三者之间数据转化示意图；
图7为本申请实施例提供的计算设备的结构示意图。
具体实施方式
下面结合附图并举实施例，对本申请提供的技术方案作进一步说明。应理解，本申请实施例中提供的系统结构和业务场景主要是为了说明本申请的技术方案的可能的实施方式，不应被解读为对本申请的技术方案的唯一限定。本领域普通技术人员可知，随着系统结构的演进和新业务场景的出现，本申请提供的技术方案对类似技术问题同样适用。
应理解，本申请实施例提供的车辆控制器与外部交互数据的方案，包括车辆控制 器与外部交互数据的装置与方法、计算设备、计算机可读存储介质及计算机程序产品。由于这些技术方案解决问题的原理相同或相似，在如下具体实施例的介绍中，某些重复之处可能不再赘述，但应视为这些具体实施例之间已有相互引用，可以相互结合。
对本申请具体实施方式进行进一步详细说明之前，对本申请实施例中涉及的技术用语进行说明。除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。如有不一致，以本说明书中所说明的含义或者根据本说明书中记载的内容得出的含义为准。另外，本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
为了准确地对本申请中的技术内容进行叙述，以及为了准确地理解本申请，在对具体实施方式进行说明之前先对本说明书中所使用的术语给出如下的解释说明或定义。
车辆控制器，用于完成整车或若干个功能域的控制功能的控制器，示例地，功能域可以包括智能座舱、车身和自动驾驶等领域，也可以包括上述功能域的子功能域。
通用接口单元(Versatile Interface Unit，VIU)，用于完成车辆一个功能域内的车辆传感器和车辆执行器设备接入。
集中控制器(X domain Controller，XDC)，用于完成车辆一个或多个功能域内的控制功能。
超文本传输协议(Hyper Text Transfer Protocol，HTTP)，因特网上应用广泛的一种网络传输协议，用于从万维网(World Wide Web，WWW)服务器传输超文本到本地浏览器的传送协议，基于TCP/IP通信协议来传递数据。
JS对象简谱(JavaScript Object Notation,JSon)，一种轻量级的数据交换格式。采用完全独立于编程语言的文本格式来存储和表示数据，简洁和清晰的层次结构使得其成为理想的数据交换语言，易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。
对象化，将目标的状态与对目标状态进行的操作封装在一起。在本申请实施例中是将车辆传感器和车辆执行按照面向服务的方式进行对象化。
图1C示出了一种基于以太骨干网的标定测量方案。该方案包括通用接口单元101和通用接口单元102，通用接口单元101和102负责本功能域内的车辆传感器和车辆执行器设备接入；还示出了集中控制器104，以及专业测试设备103以及其对应的配套软件105。
原始拓扑为通用接口单元101和102直接接入集中控制器104，以提供车载以太协议数据服务。当需要对通用接口单元数据进行标定测量时，首先需要引入专业测试设备103以及其对应的配套软件105；其次对原有的通用接口单元101和102直接接入集中控制器104的线束需要进行改造，须断开原线束，在线束上安装专业测试设备要求的接插件连接器后再接入设备，再由专业测试设备103进行数据的旁路测量或者标定。
在整个过程中，工程师需要通过专业的配套软件105对专业测试设备103配置物理链路，物理链路连接成功进行数据标定测量。其中对车载以太协议数据进行序列化 以及反序列化也需要专业测试设备完成。
该标定测量方案硬件设备成本高，需要引入昂贵的专业测试设备，且需要对原有线束进行改造。另一方面，软件接口不开放，标定状态数据需要专业的配套软件进行序列化以及反序列化，不能使用已有IT技术生态简便地访问车载资源。
下面，结合图2A和图2B，对本申请实施例提供的访问车辆资源的方案应用于车辆的一种场景进行概要性的说明。
该应用场景中，如图2A所示，车辆包括车辆控制器100、传感器130和132、执行器140。其中，车辆控制器100可以是整车控制器，也可以是一个功能域的控制器，如智能座舱控制器。车辆控制器100包括通用接口单元110和112、集中控制器120。通用接口单元110和112负责本功能域内的车辆传感器130和132、车辆执行器140设备的接入，示例地，图2A中示出了2个通用接口单元，实际上可以包含多个通用接口单元，每个通用接口单元可以是一个ECU。集中控制器120完成车辆整车的控制功能，也可以完成一个或多个领域内的控制功能或者某一个具体功能域的控制功能，集中控制器120可以为HPC或多域控制器(Multi Domain Controller，MDC)或ECU。车辆传感器130和132用于采集数据，示例地，图2A中示出了2个车辆传感器，实际可以包含多个车辆传感器，分别连接在各通用接口单元。其中，车辆传感器可以包括车速传感器、侧倾角传感器、距离传感器、温度传感器、亮度传感器、湿度传感器、电量传感器等。车辆执行器140用于执行集中控制器120的控制命令，示例地，图2A中示出了1个车辆执行器，实际可以包含多个车辆执行器，分别连接在各通用接口单元。车辆执行器包括电动机、离合器、电磁阀、开关、ABS的刹车钳等等。
该应用场景中，如图2B所示，外部计算机150与车辆控制器100通信，用于通过车辆控制器100的集中控制器120获取车辆传感器所采集的数据，和通过集中控制器120向车辆执行器发布控制命令。在一些实施例中，外部计算机可以通过有线或无线方式与车辆控制器100进行通信。外部计算机也可以替换为平板电脑(PAD)、智能手机等设备。
下面基于各个附图，介绍本申请的各实施例。
首先，对本申请提供的一种访问车辆资源的方法实施例一、实施例二进行介绍，该实施例一、实施例二的方法可在图2A示出的车辆控制器100中运行。本方法实施例一、实施例二中，车辆控制器基于物理格式的数据访问车辆传感器或控制车辆执行器，基于开放的外部消息格式的数据与车外设备进行交互，实现车外设备访问车辆资源时，可不增加新的设备、可不改造现有车辆控制器。
图3A示出了访问车辆资源的方法实施例一的流程，该实施例中，车辆控制器100从车辆传感器获取基于车辆传感器的物理格式的第一数据，并转化为基于开放的外部消息格式的数据向外部发送，下面参照图3A对该实施例进行详细介绍，该实施例包括步骤S310A至S330A。
S310A：车辆控制器100接收车辆传感器的第一数据。其中，第一数据为车辆传感器的物理格式的数据。
在本实施例中，该物理格式的数据包括二进制序列数据。在其他一些实施例中，物理格式的数据包括十六进制或八进制序列数据。
在一些实施例中，车辆控制器100通过通用接口单元接收车辆传感器的第一数据。在本实施例中，通用接口单元可以由车辆控制器100包含的ECU实现。
在一些实施例中，车辆控制器100的接口单元通过通用总线协议与车辆传感器通信，来获取车辆传感器的所述第一数据。在一些实施例中，通用总线协议可以包括CAN总线协议、高速CAN总线协议、FlexRay协议、时间触发协议(Time Triggered Protocol，TTP)、车域网(Vehicle Area network，VAN)协议、或本地互联网络(Local Interconnect Network，LIN)总线协议等。
在一些实施例中，车辆控制器100利用内部通信协议把第一数据从通用接口单元传输到集中控制器120。
在一些实施例中，该内部通信协议可以为车载以太网协议(Ethernet)，还可以为车域网(Vehicle Area network，VAN)协议、本地互联网络(Local Interconnect Network，LIN)协议等。
S320A：车辆控制器100将第一数据转换为第二数据。其中，第二数据为外部消息格式的数据。
在本实施例中，外部消息格式的数据包括基于HTTP格式的数据。由于HTTP为因特网上应用广泛的一种网络传输协议，因此基于HTTP格式的数据更具有通用性，便于各类外部设备对该基于HTTP格式的数据的接收和处理。在其他一些实施例中，外部消息格式也可以是FTP协议格式的数据等。
在本实施例中，第二数据为基于JSon的结构化数据。基于JSon的结构化数据易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。在其他一些实施例中，结构化数据也可以是基于XML(XML是一种可扩展标记语言)、Protobuf(Protobuf是一种数据交换格式)、Flatbuffer(Flatbuffer是一种数据交换格式)等等。
在一些实施例中，第一数据和第二数据采用相同的面向服务的模板结构。
在一些实施例中，车辆控制器100通过集中控制器120将第一数据转换为第二数据。在一些实施例中，车辆控制器100也可以通过其他控制器，如车辆上的任一ECU进行所述数据的转换。
由上，通过车辆控制器向外发送基于开放的外部消息格式的数据，无需专门的三方测试设备，也无需改造车辆控制器的内部线路，可以向外部装置传送车辆传感器的数据。
在一些实施例中，本步骤具体包括：将第一数据转换为第五数据，其中，第五数据为内部消息格式的数据。以及，将第五数据转换为第二数据。
在一些实施例中，第一数据和第五数据采用相同的面向服务的模板结构。
由上，通过把第一数据转换为内部消息格式的第五数据，便于车辆控制器100的内部使用。
S330A：车辆控制器100向外发送第二数据。
在一些实施例中，车辆控制器100通过集中控制器120向外发送第二数据。在一 些实施例中，可以通过有线传输、或者无线传输方式，由车辆控制器100通过集中控制器120，将所述第二数据发送至外部装置。其中，外部装置可以是通用的计算机系统、平板电脑(PAD)、智能手机等等。
在一些实施例中，第二数据采用分块传输编码(Chunked Transfer Encoding，Chunked)，便于复用第二数据的链接。
图3B示出了访问车辆资源的方法实施例二的流程，该实施例中，车辆控制器从外部获取基于开放的外部消息格式的第三数据，转化为基于车辆执行器的物理格式的第四数据以对车辆执行器进行控制。下面参照图3B对该实施例进行详细介绍，该实施例包括步骤S310B至S330B。
S310B：车辆控制器100接收来自车外的第三数据。其中，第三数据为开放的外部消息格式的数据。
在一些实施例中，外部消息格式的数据包括基于HTTP格式的数据，也可以是基于FTP协议格式的数据等，具体可参见步骤S320A中的对外部消息格式的相关描述。
在一些实施例中，第三数据为基于JSon的结构化数据，也可以是基于XML、Protobuf、Flatbuffer等，具体可参见步骤S320A中的对结构化数据的相关描述。
在一些实施例中，车辆控制器100通过集中控制器120接收来自车外的外部装置的第三数据。其中，可以通过有线传输、或者无线传输方式接收。
S320B：车辆控制器100将第三数据转换为第四数据。其中，第四数据为车辆执行器的物理格式的数据。
在一些实施例中，该物理格式的数据包括二进制序列数据，也可以是十六进制或八进制序列数据等，第四数据的格式可以以执行器支持的物理格式为准。
在一些实施例中，第三数据和第四数据采用相同的面向服务的模板结构。
在一些实施例中，车辆控制器100通过集中控制器120将第三数据转换为第四数据。在一些实施例中，车辆控制器100也可以通过其他控制器，如车辆上的任一ECU进行所述数据的转换。
由上，通过车辆控制器接收外部基于开放的外部消息格式的数据，转化为车辆执行器的物理格式的数据，无需专门的三方测试设备，也无需改造车辆控制器的内部线路，可以接收外部通用的计算机系统发送的数据。
在一些实施例中，本步骤具体包括：将第三数据转换为第六数据，其中，第六数据为内部消息格式的数据。以及，将第六数据转换为第四数据。
在一些实施例中，第六数据和第四数据采用相同的面向服务的模板结构。
由上，通过把第三数据转换为内部消息格式的第六数据，便于车辆控制器100内部的内部使用。
S330B：车辆控制器向车辆执行器140发送第四数据。
在一些实施例中，车辆控制器100利用内部通信协议把第四数据从集中控制器120发送到通用接口单元。在一些实施例中，该内部通信协议可以为车载以太网协议(Ethernet)，还可以为车域网(Vehicle Area network,VAN)协议、本地互联网络(Local Interconnect Network，LIN)协议等。
在一些实施例中，车辆控制器100通过通用接口单元发送第四数据到执行器140。在本实施例中，通用接口单元可以由车辆控制器100包含的ECU实现。
在一些实施例中，车辆控制器100的接口单元通过通用总线协议与执行器通信，将第四数据发送到执行器。在一些实施例中，通用总线协议可以包括CAN总线协议、高速CAN总线协议、FlexRay协议、时间触发协议(Time Triggered Protocol，TTP)、车域网(Vehicle Area network,VAN)协议、或本地互联网络(Local Interconnect Network，LIN)总线协议等。
在一些实施例中，上述访问车辆资源的方法实施例一的流程和方法实施例二的流程分别单独执行，进行车辆传感器的数据采集或对车辆执行器进行控制。
在一些实施例中，先执行上述访问车辆资源的方法实施例一的流程，再执行上述访问车辆资源的方法实施例二的流程，如应用于数据标定过程。
在一些实施例中，上述访问车辆资源的方法实施例一的流程与上述访问车辆资源的方法实施例二的流程反复交替运行，如应用于排障过程或调试过程。
综上，上述访问车辆资源的方法实施例从车辆传感器采集基于车辆传感器的物理格式的第一数据，并转化为基于开放的外部消息格式的数据向外部发送；从外部获取基于开放的外部消息格式的第三数据，转化为基于车辆执行器的物理格式的第四数据以对车辆执行器进行控制。上述访问车辆资源的方法实施例无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地访问车载资源。
本申请实施例还提供了一种访问车辆资源的方法实施例三和实施例四，下面结合附图介绍该方法实施例三和实施例四。
本方法实施例三、实施例四由图2A示出的车辆控制器100执行，基于二进制序列的物理格式数据通过车辆控制器100访问车辆传感器或控制车辆执行器，对外基于开放的HTTP格式的数据与外部交互，实现在访问车辆资源时不增加新的设备和不改造现有车辆控制器的线束，同时通过已有的IT生态技术与车外的系统互联。
图4A示出了该方法实施例三的流程，在实施例三的流程中，通用接口单元从车辆传感器采集车辆传感器物理格式的第一数据(为了描述方便，本例中后续称为状态数据)向集中控制器120发送，集中控制器120先根据状态数据生成内部消息格式的第五数据(为了描述方便，本例中后续称为第二状态消息)，再根据第二状态消息生成开放的HTTP格式的第二数据(为了描述方便，本例中后续称为第一状态消息)，以向外部计算机150发送，包括步骤S410A至S440A；
图4B示出了该方法实施例四的流程，在实施例四的流程中，集中控制器120从外部计算机接收开放的HTTP格式的第三数据(为了描述方便，本例中后续称为第一命令消息)，集中控制器120根据第一命令消息生成第六数据(为了描述方便，本例中后续称为第二命令消息)，再根据第二命令消息生成基于执行器物理格式的第四数据(为了描述方便，本例中后续称为控制命令)，并向通用接口单元发送，通用接口单元把接收的控制命令向车辆执行器发送，对车辆进行控制，包括步骤S410B至S440B。
下面参见图4A，详细介绍该方法实施例三包含的具体步骤。
S410A：车辆控制器100的通用接口单元获得状态数据，并向其集中控制器120发送。
其中，状态数据为车辆传感器所采集的相关状态的物理格式的二进制序列的数据。
其中，车辆控制器100通过面向服务架构的应用程序接口(Service-Oriented Architecture Application Programming Interface，SOA API)从车辆传感器采集数据，基于面向服务的模板生成状态数据的内容，并添加相关的服务类型标识和数据类型标识生成状态数据，其中，状态数据的数据类型标识为数据标识。
其中，状态数据通过通用接口单元与集中控制器120之间内部通信协议传送。
S420A：车辆控制器100的集中控制器120接收状态数据，并据此生成对象化的第二状态消息。
其中，第二状态消息为对象化的内部消息格式的数据，便于集中控制器120内部的订阅的应用程序(Application，APP)使用。
其中，第二状态消息的内容的模板结构与状态数据的内容的模板结构相同，为面向服务的模板结构。
S430A：车辆控制器100的集中控制器120把第二状态消息转换为第一状态消息。
其中，第一状态消息为基于HTTP格式的JSon结构化的数据，为表述性状态转化(Representational State Transfer，REST)风格，便于外部计算机150通过公开的IT技术生态使用。
其中，第一状态消息的内容的模板结构与状态数据的内容的模板结构相同。
S440A：车辆控制器100的集中控制器120把第二状态消息转换向外部发送。
其中，当第一状态消息为周期性数据时，第一状态消息采用分块传输编码，便于复用第一状态消息的链接。
下面参见图4B，详细介绍该方法实施例四包含的具体步骤。
S410B：车辆控制器100的集中控制器120从车外接收第一命令消息。
其中，第一命令消息为基于HTTP格式的JSon结构化的数据，便于通过开放的IT生态技术接收通过外部计算机150的命令。
S420B：车辆控制器100的集中控制器120把第一命令消息转换为第二命令消息。
其中，第二命令消息为对象化结构内部消息格式的数据，便于集中控制器120内部的使用。
其中，第二命令消息的内容的模板结构与第一命令消息的内容的模板结构相同，为面向服务的模板结构。
S430B：车辆控制器100的集中控制器120对第二命令消息进行序列化，生成二进制序列的控制命令。
其中，控制命令的格式为车辆执行器的物理格式。
其中，第二命令消息的内容的模结构板与控制命令的内容的模板结构相同。
S440B：车辆控制器100的通用接口单元获得控制命令，并向生成车辆执行器的命令向车辆执行器发送。
其中，状态数据通过通用接口单元与集中控制器120之间内部通信协议传送。
其中，通用接口单元通过SOA API向车辆执行器发送命令。
下面再结合附图对方法实施例三、实施例四中的数据进行示例地描述。
示例地，图4C示出了3种服务类型的数据，从下至上，分别为物理格式的状态数据和控制数据、内部消息格式的第二状态消息和第二命令消息、HTTP格式的第一状态消息和第一命令消息。
先介绍图4C左侧的数据，其服务类型为门锁服务(Service DoorLock)。图下部方框中数据为物理格式的数据，服务类型标识为SID 0x1001，包括车门状态的状态数据和车门的控制命令。其中，状态数据的数据类型标识为Event 0x0001，Event表示状态数据，状态数据的内容包括左门状态(flClockStatus)和右门状态(frClockStatus)；控制命令的数据类型标识为Method 0x0002，Method表示控制命令，控制命令的内容包括左门控制命令(clockMotorCmd_L)和右门控制命令(clockMotorCmd_R)。图中部方框中数据为内部消息格式的数据，其中，Topic DoorLock为第二状态消息，其内容的与Service DoorLock的Event内容一致，包括左门状态(flClockStatus)和右门状态(frClockStatus)；Service DoorLock为第二命令消息，其内容与控制命令即Service DoorLock的Method内容一致，包括左门控制命令(clockMotorCmd_L)和右门控制命令(clockMotorCmd_R)。图上部方框中数据为HTTP格式的JSon结构化的数据，其中，RI:GET DoorLock为获取车门状态的第一状态消息，GET表示获取，获取的DoorLock内容包括Topic DoorLock中的左门状态(flClockStatus)和右门状态(frClockStatus)；URI:PUT DoorLock为发送车门控制的第一命令消息，PUT表示发送，发送的DoorLock的内容包括Service DoorLock中的左门控制命令(clockMotorCmd_L)和右门控制命令(clockMotorCmd_R)。
图4C的中间文本为灯光服务(Service ExteriorLinght)，其服务类型标识为SID0x1002，自下至上包括灯光的控制命令、第二命令消息和第一命令消息，三者内容一致，具体不再详述。图4C中的右侧文本为超声波雷达服务(Service Ultrasound)，其服务类型标识为SID 0x1003，自下至上包括超声波雷达的状态数据、第二状态消息和第一状态消息，三者内容一致，，具体不再详述。
需要指出的，在图4C中显示的文本形式是为了描述方便，其实际形式可以是二进制序列数据。
示例地，图4D示出了方法实施例三、实施例四的数据转化关系，包括：传感器物理格式的二进制序列的状态数据经过反序列化，转化为车辆控制器内部消息格式的对象化的第二状态消息，再转化为到JSon结构化的HTTP格式的第一状态消息；以及JSon结构化的HTTP格式的数据转化为内部消息格式的对象化的第二命令消息、再序列化为物理格式的二进制序列的控制命令。
综上，方法实施例三、实施例四从车辆传感器采集车辆传感器物理格式的状态数据，转化为内部消息格式的第二状态消息，再把第二状态消息转化为开放的HTTP格式的第一状态消息，以向外部计算机150发送；从外部计算机接收开放的HTTP格式的第一命令消息)，集中控制器120根据第一命令消息，转化为内部消息格式的第二命令消息，再根据第二命令消息生成执行器物理格式的控制命令，并向通用接口单元 发送，对车辆进行控制。方法实施例三、实施例四无需要引入昂贵的专业测试设备，也无需对原有线束进行改造，而且使用已有公开的IT技术生态简便地访问车载资源，同时，中间生成的内部消息格式的第二状态消息或/和第二命令消息便于车辆控制器内部使用。
本申请实施例提供了一种访问车辆资源的装置实施例一，该装置可用于执行上述访问车辆资源的方法的各个实施例的方案。
图5示出了该装置实施例一的结构，其包括接口模块510、网关模块520。
接口模块510执行上述步骤S310A及该步骤可选的各实施例，用于由车辆控制器100接收车辆传感器的第一数据；还执行上述步骤S330B及该步骤可选的各实施例，用于由车辆控制器100发送第四数据。
其中，第一数据为辆传感器的物理格式的数据，第四数据为车辆执行器的物理格式的数据。
在一些实施例中，物理格式的数据包括的二进制序列数据。
在一些实施例中，接口模块510部署在图2A示出的车辆控制器在车辆控制器100的通用接口单元上。
网关模块520执行上述步骤S320A和S330A及该两步骤可选的各实施例，用于由车辆控制器100将第一数据转换为第二数据和向外发送第二数据；还执行上述步骤S310B和S320B及该两步骤可选的各实施例，用于由车辆控制器100接收来自车外的第三数据和将第三数据转换为第四数据。
其中，第二数据和第三数据为外部消息格式的数据。
在一些实施例中，外部消息格式的数据包括基于HTTP格式的数据。
在一些实施例中，第二数据和第三数据为基于JSon的结构化数据。
在一些实施例中，第一数据与第二数据采用相同的面向服务的模板。
在一些实施例中，第三数据与第四数据采用相同的面向服务的模板。
在一些实施例中，网关模块520与接口模块510利用车辆控制器100已有的内部协议进行通信。
在一些实施例中，网关模块520部署在图2A示出的车辆控制器100的集中控制器120上，
在一些实施例中，网关模块520包括南向网关模块521和北向网关模块522。
南向网关模块521用于由车辆控制器100将第一数据转换为第五数据，北向网关模块522还用于由车辆控制器100将第五数据转换为第二数据。其中，第五数据为内部消息格式的数据。
北向网关模块522还用于由车辆控制器100将第三数据转换为第六数据，南向网关模块521还用于由车辆控制器100将第六数据转换为第四数据，其中，第六数据为内部消息格式的数据。
本申请实施例还提供了一种车辆控制器，可用于执行上述访问车辆资源的方法的各个实施例的方案。
图6A示出了车辆控制器实施例的结构，该车辆控制器实施例包括各通用接口单元(示例地，包括通用接口单元110和112)和一个集中控制器120，各通用接口单元还包括接口模块510，集中控制器120包括南向网关(South Gateway)模块521和北向网关(North Gateway)模块522。
接口模块510用于向车辆控制器100提供SOA API，开放车辆传感器(包括车辆传感器130和132)和车辆执行器(包括车辆执行器140)的能力。接口模块510执行上述步骤S410A及该步骤可选的各实施例，从车辆传感器获得状态数据，还执行上述步骤S440B及该步骤可选的各实施例，向车辆执行器发送控制命令。
其中，因为各通用接口单元与集中控制器120基于IP进行通信，所以接口模块510所提供的接口为SOMEIP的中间件。当各通用接口单元与集中控制器120基于其他通信方式进行通信时，接口模块510所提供的接口为其他通信方式的面向服务的中间件。
其中，状态数据为车辆传感器物理格式的二进制序列数据，控制命令为车辆执行器物理格式的二进制序列数据。
其中，状态数据和控制命令基于面向服务的模板结构，该模板包括服务类型标识、数据类型标识和内容，其中，状态数据的数据类型标识为数据标识，控制命令的数据类型标识为命令标识。
南向网关模块521执行上述步骤S420A及该步骤可选的各实施例，用于把从接口模块510接收的状态数据进行反序列化，转化为对象化的第二状态消息，以供集中控制器120内部的APP使用或者通过北向网关模块522发送。南向网关模块521还执行上述步骤S430B及该步骤可选的各实施例，用于把从北向网关模块522或集中控制器120内部的APP接收的对象化的第二命令消息进行序列化，转换为二进制的控制命令，以向接口模块510发送。
其中，南向网关模块521与接口模块510之间通过车辆控制器内部协议进行通信，示例地，基于IP进行通信。
其中，第二状态消息和第二命令消息为车辆控制器的内部消息格式，便于集中控制器内部订阅的APP使用。
其中，第二状态消息的内容的模板结构与状态数据的内容的模板结构相同；第二命令消息的内容的模板结构与控制命令的内容的模板结构相同。
示例地，图6B以门锁服务为例，示出了南向网关模块521与接口模块510之间的数据转换。图6B中南向网关模块521定义的集中控制器120内部消息格式的第二状态消息为Topic DoorLock，其内容与接口模块510的状态数据即Service DoorLock的Event的内容一致，包括左门状态(flClockStatus)和右门状态(frClockStatus)，这样南向网关模块521把从接口模块510接收到对应的Service DoorLock的Event数据根据相同的模板结构进行反序列化，转化为对象化的内部消息格式的Topic DoorLock，便于集中控制器120的内部APP进行订阅或向北向网关模块522发送。又如，图6B中，南向网关模块521定义的集中控制器120的第二命令消息为Service DoorLock，其内容与接口模块510的控制命令即Service DoorLock的Method的内容一致，包括左门控制命令(clockMotorCmd_L)和右门控制命令(clockMotorCmd_R)， 这样南向网关模块521把从内部APP或北向网关模块522接收的Service DoorLock根据相同的模板结构进行序列化，生成车辆执行器物理格式的控制命令以通过接口模块510控制车辆。
北向网关模块522执行上述步骤S430A和S440A及该两步骤可选的各实施例，用于把从南向网关模块521接收的第二状态消息转化为HTTP格式的第一状态消息，并向外部计算机150发送。北向网关模块522还执行上述步骤S410B和S420B及该两步骤可选的各实施例，用于从外部计算机150接收的HTTP格式的第一命令消息，并转换为第二命令消息。
其中，第一状态消息和第一命令消息为在IT业界广泛使用的HTTP格式，为REST风格，以便于外部计算机150通过开放的IT生态技术使用。
其中，第一状态消息和第一命令消息为JS对象表示的结构化的数据，以进一步便于外部计算机150使用。
其中，第一状态消息的内容的模板结构与状态数据的内容的模板结构相同。
其中，当第一状态消息为周期性数据时，第一状态消息采用分块传输编码，便于复用第一状态消息的链接。
示例地，图6C以门锁服务为例示出了北向网关模块522、南向网关模块521和接口模块510三者之间的数据转化关系，南向网关模块521和接口模块510之间的数据转换关系已在图6B中介绍过，下面介绍北向网关模块522与南向网关模块521之间的数据转化。图6C中北向网关模块522定义的第一状态消息为URI:GET DoorLock，其内容为基于HTTP格式的JSon结构化数据，其中，GET表示获取，获取的DoorLock内容包括南向网关模块521定义的Topic DoorLock中的左门状态(flClockStatus)和右门状态(frClockStatus)，这样就完成了从车辆传感器、到接口模块510、到南向网关模块521、到北向网关模块522、最后到外部计算机150的数据映射的逻辑链条。同时图6C中通过北向网关模块522接收的第一命令消息为URI:PUT DoorLock，其内容为基于HTTP格式的JSon结构化数据，其中，PUT表示发送，发送的DoorLock的内容包括南向网关模块521定义的Service DoorLock中的左门控制命令(clockMotorCmd_L)和右门控制命令(clockMotorCmd_R)，这样就完成了从外部计算机150、到北向网关模块522、到南向网关模块521、到接口模块510、最后到车辆执行器的数据映射的逻辑链条。
图7是本申请实施例提供的一种计算设备700的结构性示意性图。该计算设备700包括：处理器710、存储器720、通信接口730。
应理解，图7所示的计算设备700中的通信接口730可以用于与其他设备之间进行通信。
其中，该处理器710可以与存储器720连接。该存储器720可以用于存储该程序代码和数据。因此，该存储器720可以是处理器710内部的存储模块，也可以是与处理器710独立的外部存储模块，还可以是包括处理器710内部的存储模块和与处理器710独立的外部存储模块的部件。
应理解，在本申请实施例中，该处理器710可以采用中央处理模块(central  processing unit，CPU)。该处理器还可以是其它通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。或者该处理器710采用一个或多个集成电路，用于执行相关程序，以实现本申请各实施例所提供的技术方案。
该存储器720可以包括只读存储器和随机存取存储器，并向处理器710提供指令和数据。处理器710的一部分还可以包括非易失性随机存取存储器。例如，处理器710还可以存储设备类型的信息。
在计算设备700运行时，所述处理器710执行所述存储器720中的计算机执行指令执行上述方法的操作步骤。
应理解，根据本申请实施例的计算设备700可以对应于执行根据本申请各实施例的方法中的相应主体，并且计算设备700中的各个模块的上述和其它操作和/或功能分别为了实现本申请实施例各方法的相应流程，为了简洁，在此不再赘述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only  Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时用于执行本申请各个实施例所描述的方案中的至少之一。
本申请实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是，但不限于，电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中连接了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括、但不限于无线、电线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本申请操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
其中，说明书和权利要求书中的词语“第一、第二、第三等”或模块A、模块B、模块C等类似用语，仅用于区别类似的对象，不代表针对对象的特定排序，可以理解地，在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
在以上的描述中，所涉及的表示步骤的标号，如S110、S120……等，并不表示一定会按此步骤执行，在允许的情况下可以互换前后步骤的顺序，或同时执行。
说明书和权利要求书中使用的术语“包括”不应解释为限制于其后列出的内容；它不排除其它的元件或步骤。因此，其应当诠释为指定所提到的所述特征、整体、步骤或部件的存在，但并不排除存在或添加一个或更多其它特征、整体、步骤或部件及其组群。因此，表述“包括装置A和B的设备”不应局限为仅由部件A和B组成的设备。
本说明书中提到的“一个实施例”或“实施例”意味着与该实施例结合描述的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在本说明书各处出现的用语“在一个实施例中”或“在实施例中”并不一定都指同一实施例，但可以指同一实施例。此外，在一个或多个实施例中，能够以任何适当的方式组合各特定特征、结构或特性，如从本公开对本领域的普通技术人员显而易见的那样。
注意，上述仅为本申请的较佳实施例及所运用的技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请的构思的情况下，还可以包括更多其他等效实施例，均属于本申请的保护范畴。

Claims (16)

  1. 一种访问车辆资源的方法，其特征在于，包括：
    车辆控制器接收车辆传感器的第一数据，所述第一数据为所述车辆传感器的物理格式的数据；
    所述车辆控制器将所述第一数据转换为第二数据；所述第二数据为外部消息格式的数据；
    所述车辆控制器输出所述第二数据。
  2. 根据权利要求1所述方法，其特征在于，所述车辆控制器将所述第一数据转换为第二数据包括：
    将所述第一数据转换为第五数据；所述第五数据为内部消息格式的数据；
    将所述第五数据转换为所述第二数据。
  3. 一种访问车辆资源的方法，其特征在于，包括：
    车辆控制器接收来自车外的第三数据，所述第三数据为外部消息格式的数据；
    所述车辆控制器将所述第三数据转换为第四数据；所述第四数据为车辆执行器的物理格式的数据；
    所述车辆控制器向所述车辆执行器发送第四数据。
  4. 根据权利要求3所述方法，其特征在于，所述车辆控制器将所述第三数据转换为第四数据包括：
    将所述第三数据转换为第六数据，所述第六数据为内部消息格式的数据；
    将所述第六数据转换为第四数据。
  5. 根据权利要求1或3所述方法，其特征在于，所述物理格式包括二进制序列格式。
  6. 根据权利要求1或3所述方法，其特征在于，所述外部消息格式包括HTTP格式。
  7. 一种访问车辆资源的装置，其特征在于，包括：接口模块和网关模块；
    所述接口模块用于由车辆控制器接收车辆传感器的第一数据，所述第一数据为所述车辆传感器的物理格式的数据；
    所述网关模块用于由所述车辆控制器将所述第一数据转换为第二数据，所述第二数据为外部消息格式的数据；
    所述网关模块还用于由所述车辆控制器输出所述第二数据。
  8. 根据权利要求7所述装置，其特征在于，所述网关模块包括南向网关模块和北向网关模块；
    所述南向网关模块用于将所述第一数据转换为第五数据，所述第五数据为内部消息格式的数据；
    所述北向网关模块用于将所述第五数据转换为所述第二数据。
  9. 一种访问车辆资源的装置，其特征在于，包括：接口模块和网关模块；
    所述网关模块用于由车辆控制器接收来自车外的第三数据，所述第三数据为外部消息格式的数据；
    所述网关模块还用于由所述车辆控制器将所述第三数据转换为第四数据，所述第 四数据为车辆执行器的物理格式的数据；
    所述接口模块用于由所述车辆控制器向所述车辆执行器发送第四数据。
  10. 根据权利要求9所述装置，其特征在于，所述网关模块包括南向网关模块和北向网关模块；
    所述北向网关模块用于将所述第三数据转换为第六数据，所述第六数据为内部消息格式的数据；
    所述南向网关模块用于将所述第六数据转换为第四数据。
  11. 根据权利要求7或9所述装置，其特征在于，所述物理格式包括二进制序列格式。
  12. 根据权利要求7或9所述装置，其特征在于，所述外部消息格式包括HTTP格式。
  13. 一种车辆控制器，其特征在于，包括：
    权利要求7至12任一项所述的装置；
    通用接口单元；
    集中控制器；
    其中，所述接口模块部署在通用接口单元上，所述网关模块部署于集中控制器上。
  14. 一种计算设备，其特征在于，包括至少一个处理器和至少一个存储器，所述存储器存储有程序指令，所述程序指令当被所述至少一个处理器执行时使得所述至少一个处理器实现权利要求1至6任一项所述的方法。
  15. 一种计算机可读存储介质，其上存储有程序指令，其特征在于，所述程序指令当被计算机执行时使得所述计算机实现权利要求1至6任一项所述的方法。
  16. 一种计算机程序产品，其特征在于，其包括有程序指令，所述程序指令当被计算机执行时使得所述计算机实现权利要求1至6任一项所述的方法。
PCT/CN2021/125965 2021-10-25 2021-10-25 访问车辆资源的方法、装置和车辆控制器 WO2023070238A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2021/125965 WO2023070238A1 (zh) 2021-10-25 2021-10-25 访问车辆资源的方法、装置和车辆控制器
CN202180097384.1A CN117203637A (zh) 2021-10-25 2021-10-25 访问车辆资源的方法、装置和车辆控制器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/125965 WO2023070238A1 (zh) 2021-10-25 2021-10-25 访问车辆资源的方法、装置和车辆控制器

Publications (1)

Publication Number Publication Date
WO2023070238A1 true WO2023070238A1 (zh) 2023-05-04

Family

ID=86159859

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/125965 WO2023070238A1 (zh) 2021-10-25 2021-10-25 访问车辆资源的方法、装置和车辆控制器

Country Status (2)

Country Link
CN (1) CN117203637A (zh)
WO (1) WO2023070238A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013178140A1 (zh) * 2012-09-06 2013-12-05 中兴通讯股份有限公司 行车记录处理方法、装置及设备
CN104412223A (zh) * 2012-05-09 2015-03-11 博世汽车服务解决方案有限责任公司 自动诊断服务器
CN109544964A (zh) * 2018-12-29 2019-03-29 同济大学 一种无人驾驶车的航线传输系统
CN110321392A (zh) * 2019-06-25 2019-10-11 北京海量数据技术股份有限公司 基于传感器监测数据文件的数据库管理系统
CN111009054A (zh) * 2019-11-25 2020-04-14 腾讯科技（深圳）有限公司 一种上车辆控制装置、数据处理方法及存储介质
CN111191422A (zh) * 2019-12-31 2020-05-22 湖南中联重科智能技术有限公司 一种文件格式转换方法、装置和计算机可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104412223A (zh) * 2012-05-09 2015-03-11 博世汽车服务解决方案有限责任公司 自动诊断服务器
WO2013178140A1 (zh) * 2012-09-06 2013-12-05 中兴通讯股份有限公司 行车记录处理方法、装置及设备
CN109544964A (zh) * 2018-12-29 2019-03-29 同济大学 一种无人驾驶车的航线传输系统
CN110321392A (zh) * 2019-06-25 2019-10-11 北京海量数据技术股份有限公司 基于传感器监测数据文件的数据库管理系统
CN111009054A (zh) * 2019-11-25 2020-04-14 腾讯科技（深圳）有限公司 一种上车辆控制装置、数据处理方法及存储介质
CN111191422A (zh) * 2019-12-31 2020-05-22 湖南中联重科智能技术有限公司 一种文件格式转换方法、装置和计算机可读存储介质

Also Published As

Publication number Publication date
CN117203637A (zh) 2023-12-08

Similar Documents

Publication Publication Date Title
CN114553873A (zh) 基于soa的车云协同控制系统、方法及可读存储介质
Gopu et al. Service Oriented Architecture based connectivity of automotive ECUs
US20170048359A1 (en) Method and device for transmitting a message in a vehicle
WO2021052442A1 (zh) 获取方法、配置方法、边缘计算集群及装置
CN103699074A (zh) 一种变流器中的can通信控制装置及通信方法
Oksanen et al. Remote access of ISO 11783 process data by using OPC Unified Architecture technology
CN108563501B (zh) 动态可重构高速串行总线的中断请求方法及装置
CN115871691A (zh) 车辆行驶控制方法、装置、电子设备和计算机可读介质
JP2023516417A (ja) ログ取得方法、端末及びサーバ
WO2023070238A1 (zh) 访问车辆资源的方法、装置和车辆控制器
Ioana et al. VSOMEIP-OPC UA gateway solution for the automotive industry
Kenjić et al. Connectivity challenges in automotive solutions
Găitan et al. Modbus protocol performance analysis in a variable configuration of the physical Fieldbus architecture
Weckemann et al. Lessons from a Minimal Middleware for IP-based In-car Communication
da Silva Sa et al. Monitoring of temperature using smart sensors based on CAN architecture
TWI496706B (zh) 車載網路通訊系統及其模組化分析裝置
Yordanova et al. Comparative Evaluation of Communication Protocols in the Automotive Industry
Guijarro Cameros et al. How DDS and TSN are driving interoperability and performance in automotive systems
Zi-Wei et al. Remote ATS simulation system based on webSocket communication protocol
Yuan et al. Overview of OPC UA TSN
CN114363423B (zh) 支持B-SA的嵌入式BACnet装置、执行器及楼宇自控系统
Jacquin et al. Design of a Gateway Module for Multi-protocol Industrial Connected Objects and Cloud Services
Lee et al. General middleware bridge to support device interoperability on different middlewares
Oleghe Controller-based IIoT infrastructure and enabling technologies: An overview for design configuration
WO2022104747A1 (zh) 一种访问io设备的方法及装置

Legal Events

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

Ref document number: 21961630

Country of ref document: EP

Kind code of ref document: A1