Vehicle-machine cloud cooperation system, method, device and storage medium

Abstract

The application discloses a vehicle-machine cloud cooperation system, method, equipment and storage medium, relates to the technical field of vehicles, and can realize that vehicle state information acquired through a vehicle terminal triggers a physical action of a body intelligent terminal, and provides services for the vehicle. The system comprises the following: a vehicle terminal, which is used for acquiring vehicle state information and uploading the vehicle state information to a cloud server; the cloud server, which is used for generating a service task based on the vehicle state information and sending the service task to an edge gateway; the edge gateway, which is used for converting the service task into an action instruction and sending the action instruction to the body intelligent terminal; and the body intelligent terminal, which is used for executing a physical action in response to the action instruction.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle-machine cloud collaborative system, method, device and storage medium. Background Technology

[0002] Current mainstream vehicle-to-everything (V2X) systems adopt a traditional cloud-vehicle one-way control architecture. This means that the onboard terminal collects raw data such as vehicle driving, vehicle status, and location, and uploads it to a cloud server via a 4G / 5G network. The cloud server is then used for data storage and remote command issuance.

[0003] However, the traditional cloud-vehicle one-way control architecture lacks an external intelligent terminal access channel. Summary of the Invention

[0004] The purpose of this application is to provide a vehicle-machine cloud collaboration system, method, device and storage medium that can trigger a physical action by an embodied intelligent terminal to provide services to the vehicle based on vehicle status information obtained through the vehicle terminal.

[0005] To achieve the above objectives, this application adopts the following technical solution: Firstly, a vehicle-machine cloud collaboration system is provided, the system comprising: The vehicle-mounted terminal is used to acquire vehicle status information and upload it to the cloud server.

[0006] The cloud server is used to generate service tasks based on vehicle status information and send the service tasks to the edge gateway.

[0007] Edge gateways are used to convert service tasks into action commands and send the action commands to the embodied smart terminal.

[0008] An embodied intelligent terminal is used to respond to action commands and perform physical actions.

[0009] The technical solution provided in this application embodiment includes a vehicle-machine cloud collaborative system comprising an in-vehicle terminal, a cloud server, an edge gateway, and a embodied intelligent terminal. The in-vehicle terminal acquires vehicle status information and uploads it to the cloud server. Based on the vehicle status information, the cloud server generates service tasks and sends them to the edge gateway. The edge gateway converts the service tasks into action instructions and sends them to the embodied intelligent terminal. The embodied intelligent terminal responds to the action instructions and executes physical actions, thereby enabling the vehicle status information acquired through the vehicle terminal to trigger the embodied intelligent terminal to execute physical actions and provide services to the vehicle.

[0010] In one possible implementation, the edge gateway is also used to: after determining that the network connection between the edge gateway and the cloud server is interrupted, convert service tasks into disaster recovery control commands based on local vehicle status information. These disaster recovery control commands are used to control the embodied intelligent terminal to perform basic service actions in an offline state. The disaster recovery control commands are then sent to the embodied intelligent terminal.

[0011] Another possible implementation is to determine if the network connection between the edge gateway and the cloud server is interrupted. This can be achieved by: acquiring heartbeat packets sent by the cloud server. When the number of consecutive heartbeat packet losses exceeds a threshold, the network connection between the edge gateway and the cloud server is determined to be interrupted.

[0012] Another possible implementation is to generate service tasks based on vehicle status information. Specifically, this can be achieved by matching the vehicle status information with preset business rules to obtain service tasks. The preset business rules refer to the correspondence between vehicle status information and service tasks built into the cloud server.

[0013] Another possible implementation involves the in-vehicle terminal, which is also used to: acquire the raw signals from the vehicle's CAN bus; and perform standardized semantic conversion on the raw CAN bus signals to obtain vehicle status information.

[0014] Another possible implementation, integrated into the smart terminal, is also used to: acquire environmental perception data and send it to an edge gateway. The edge gateway is further used to: upload the environmental perception data to a cloud server. The cloud server is further used to: send the environmental perception data to the vehicle owner's application for the owner to make vehicle control decisions.

[0015] Secondly, a vehicle-to-the-cloud (V2X) collaboration method is provided, applied to a V2X cloud collaboration system. This method includes: an in-vehicle terminal acquiring vehicle status information and uploading it to a cloud server; the cloud server generating a service task based on the vehicle status information and sending the service task to an edge gateway; the edge gateway converting the service task into action commands and sending the action commands to a smart terminal; and the smart terminal responding to the action commands by performing a physical action.

[0016] Thirdly, a computer device is provided, comprising: a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the vehicle-machine-cloud collaborative method described above.

[0017] Fourthly, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the above-mentioned vehicle-machine-cloud collaborative method.

[0018] The solutions provided in the second to fourth aspects above are used to implement the method provided in the first aspect above, and their specific implementations will not be described in detail here. The technical effects corresponding to any implementation method of the solutions provided in the second to fourth aspects above can be found in the technical effects corresponding to any implementation method in the first aspect above, and will not be described in detail here.

[0019] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This application provides a schematic diagram of the structure of a vehicle-machine-cloud collaborative system. Figure 2 A flowchart illustrating an edge offline disaster recovery mechanism provided in this application embodiment; Figure 3 This application provides a schematic diagram of the architecture of a vehicle-machine cloud collaborative system. Figure 4 This is a schematic diagram of the structure of a vehicle-to-everything (V2X) intelligent collaborative protocol provided in an embodiment of this application. Figure 5 This is a schematic diagram of a security mechanism provided in an embodiment of this application; Figure 6 A flowchart illustrating an application scenario example of a vehicle-machine cloud collaborative system provided in this application embodiment; Figure 7 A flowchart illustrating a vehicle-machine-cloud collaboration method provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In the description of this application, it should be understood that the terms "upper," "lower," "left," "right," "front," "rear," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or relative positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and for simplification, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Unless otherwise specified, the above-mentioned orientational descriptions can be flexibly set in practical applications, provided that the relative positional relationships shown in the accompanying drawings are satisfied.

[0024] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0025] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "communication" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection. They can refer to a direct connection or an indirect connection through an intermediate medium, or a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0026] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, article, or apparatus that includes that element.

[0027] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0028] In the embodiments of this application, at least one can also be described as one or more, and multiple can be two, three, four or more, and this application does not impose any restrictions.

[0029] In the description of this specification, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0030] To facilitate understanding, the terms used in the embodiments of this application will be explained first.

[0031] Embodied intelligent terminals: Intelligent devices with physical execution capabilities, specifically referring to hardware such as service robots, intelligent maintenance equipment, and welcoming terminals adapted to in-vehicle scenarios.

[0032] Embodied AI-IoV Collaborative Protocol (EACP): This application presents a proprietary communication protocol developed in-house, consisting of three sub-protocols, designed to address communication compatibility issues between in-vehicle terminals and smart terminals.

[0033] Offline disaster recovery at the edge: Core data and control logic are cached locally at the edge nodes, so that basic collaborative functions can still be maintained when the vehicle network is interrupted, and data is automatically synchronized after the network is restored.

[0034] It should be noted that the information (including but not limited to device information, personal information of the subject, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the subject or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0035] Current mainstream vehicle networking systems adopt the traditional cloud-vehicle one-way control architecture (i.e., the cloud controls the vehicle in one direction only). The following is a brief explanation of the cloud-vehicle one-way control architecture.

[0036] The vehicle terminal collects raw data such as vehicle driving, vehicle condition, and location, and uploads it to the cloud server via 4G / 5G network. The cloud server is used for data storage and remote command issuance (such as remote unlocking and air conditioning control).

[0037] Traditional cloud-vehicle one-way control architecture only supports one-way command transmission from the cloud to the vehicle, without an external intelligent terminal access channel.

[0038] Based on this, this application provides a vehicle-machine cloud collaborative system, which includes an in-vehicle terminal, a cloud server, an edge gateway, and an embodied intelligent terminal. The in-vehicle terminal acquires vehicle status information and uploads it to the cloud server. The cloud server generates service tasks based on the vehicle status information and sends the service tasks to the edge gateway. The edge gateway converts the service tasks into action instructions and sends the action instructions to the embodied intelligent terminal. The embodied intelligent terminal responds to the action instructions and executes physical actions, thereby enabling the vehicle status information acquired through the vehicle terminal to trigger the embodied intelligent terminal to execute physical actions and provide services to the vehicle.

[0039] like Figure 1 As shown in the figure, this application provides a vehicle-machine cloud collaborative system, which includes an in-vehicle terminal 101, a cloud server 102, an edge gateway 103, and a smart terminal 104.

[0040] The vehicle terminal 101 is used to obtain vehicle status information and upload the vehicle status information to the cloud server 102.

[0041] For example, vehicle status information may include the target vehicle's location, speed, vehicle identification number (VIN), license plate number, door lock status, window status, and headlight status.

[0042] In one possible implementation, the vehicle terminal 101 is used to acquire the original signals of the vehicle CAN bus, perform standardized semantic conversion on the original signals of the vehicle CAN bus, and obtain vehicle status information.

[0043] The vehicle terminal 101 may include a vehicle communication module, which is used to upload vehicle status information to the cloud server 102 via 4G / 5G.

[0044] The cloud server 102 is used to generate service tasks based on vehicle status information and send the service tasks to the edge gateway 103.

[0045] Optionally, the cloud server 102 can be a cloud platform for a Telematics Service Provider (TSP).

[0046] In one possible implementation, the cloud server 102 matches the vehicle status information with preset business rules to obtain service tasks.

[0047] Among them, the preset business rules refer to the correspondence between vehicle status information and service tasks built into the cloud server.

[0048] For example, after receiving the vehicle status information (such as vehicle location information) of the target vehicle, if the cloud server 102 identifies that the target vehicle's location is within the geofence of the 4S store, it will match the vehicle status information in the preset business rules to obtain a service task with the target vehicle as "VIN: ABC123" and the service parameter as "Welcome location: 4S store entrance".

[0049] Edge gateway 103 is used to convert service tasks into action commands and send the action commands to the embodied smart terminal 104.

[0050] Edge gateway 103 is also used to cache vehicle status information. For example, edge gateway 103 can store vehicle status information for the past 7 days locally. The estimated storage capacity of edge gateway 103 is less than or equal to 10GB, that is, the estimated storage space required for caching vehicle status information for the past 7 days on the local storage device of edge gateway 103 is less than or equal to 10GB.

[0051] In one possible implementation, the edge gateway 103 is also used to convert service tasks into disaster recovery control instructions based on local vehicle status information after determining that the network connection between the edge gateway 103 and the cloud server 102 is interrupted, and then send the disaster recovery control instructions to the embodied smart terminal.

[0052] Among them, the disaster recovery control command is used to control the embodied smart terminal to perform basic service actions in the offline state.

[0053] The edge gateway 103 and the cloud server 102 send a heartbeat packet at fixed time intervals to determine the network connection status between them. For example, the cloud server 102 sends a heartbeat packet to the edge gateway 103 every 3 seconds.

[0054] In some embodiments, the edge gateway 103 receives heartbeat packets sent by the cloud server 102. When the number of consecutive heartbeat packet losses exceeds a loss threshold, it is determined that the network connection between the edge gateway 103 and the cloud server 102 is interrupted.

[0055] The number of lost packets threshold can be set according to actual needs. For example, the number of lost packets threshold can be 3. When the heartbeat packet is lost 3 times in a row, it is determined that the network connection between the edge gateway 103 and the cloud server 102 is interrupted (i.e., the edge gateway 103 is offline), and the edge offline disaster recovery mechanism is triggered.

[0056] In the event of a network connection interruption between the edge gateway 103 and the cloud server 102, the edge gateway 103 can drive the embodied smart terminal 104 to perform basic services based on locally cached vehicle status information, received service tasks, and control logic.

[0057] The control logic can be understood as a series of automated rules, judgment conditions and instruction sequences that are pre-designed and stored locally on the edge gateway 103 to drive the embodied smart terminal 104 to perform basic services when the network is interrupted.

[0058] After the network connection between edge gateway 103 and cloud server 102 is restored, edge gateway 103 can incrementally synchronize the execution records accumulated during its offline period to cloud server 102 according to timestamps. This function is automatically triggered and requires no manual intervention. During the execution record synchronization process, uploading the execution records in the order of timestamps ensures that the order of logs received by cloud server 102 is completely consistent with the actual order in which the events occurred.

[0059] The aforementioned edge offline disaster recovery mechanism can solve network fluctuation problems, improving functional continuity by more than 90%.

[0060] The embodied smart terminal 104 is used to respond to action commands and perform physical actions.

[0061] Physical actions can include movement, voice broadcasting, and image acquisition, thereby enabling services such as welcoming, guiding, and detection.

[0062] In some embodiments, the smart terminal 104 is further configured to acquire environmental perception data and send the environmental perception data to the edge gateway 103. The edge gateway 103 is further configured to upload the environmental perception data to the cloud server 102. The cloud server 102 is further configured to send the environmental perception data to the vehicle owner's application for the vehicle owner to make vehicle control decisions.

[0063] Among them, environmental perception data can be image data such as license plate recognition and appearance detection obtained by the smart terminal 104.

[0064] For example, car owners can use a mobile application (APP) to view reports, schedule services, and remotely control their vehicles. After the TSP platform performs security verification on the above user operations, it issues vehicle control commands, such as remotely unlocking the doors, remotely starting the air conditioning, or remotely opening the trunk.

[0065] Optionally, in addition to sending the environmental perception data to the car owner's application (APP), the cloud server 102 can also send the environmental perception data to the 4S store's document management system (DMS). After receiving the environmental perception data, the staff in the 4S store can provide appropriate services to the car owner based on the aforementioned environmental perception data.

[0066] It should be noted that the embodied smart terminal 104 does not directly control any vehicle functions (it does not unlock the doors or start the air conditioning). All vehicle control operations are initiated by the owner through the APP and executed after security verification by the TSP platform. The embodied smart terminal 104 only performs physical world actions (such as movement, voice broadcasting, and image acquisition).

[0067] Furthermore, the vehicle-machine cloud collaborative system provided in this application embodiment can also merge the cloud server 102 and the edge gateway 103, integrate the functions of the edge gateway 103 into the vehicle system of the vehicle terminal 101, cancel the setting of the independent edge gateway 103, and retain the core bidirectional collaboration and protocol conversion functions, thus making it suitable for low-end models and low-cost scenarios.

[0068] In summary, this application provides a vehicle-machine cloud collaborative system, which includes an in-vehicle terminal, a cloud server, an edge gateway, and a embodied intelligent terminal. The in-vehicle terminal acquires vehicle status information and uploads it to the cloud server. Based on the vehicle status information, the cloud server generates service tasks and sends them to the edge gateway. The edge gateway converts the service tasks into action commands and sends them to the embodied intelligent terminal. The embodied intelligent terminal responds to the action commands and executes physical actions, thereby enabling the vehicle status information acquired through the vehicle terminal to trigger the embodied intelligent terminal to execute physical actions and provide services to the vehicle.

[0069] In addition, the vehicle-machine cloud collaborative system provided in this application can realize two-way interaction between the vehicle terminal and the embodied intelligent terminal. That is, the vehicle status information obtained by the vehicle terminal triggers the embodied intelligent terminal to perform physical actions, and the embodied intelligent terminal feeds back environmental perception data to the vehicle terminal. This can solve the problem that the traditional cloud-vehicle one-way control architecture only supports one-way command transmission from the cloud to the vehicle, thereby improving the added value of the vehicle and the user experience.

[0070] like Figure 2 As shown, the implementation of an edge offline disaster recovery mechanism may include the following steps: Step S201: The edge gateway performs network heartbeat detection.

[0071] Among them, network heartbeat detection refers to the detection of heartbeat packets that can reflect the network connection status.

[0072] The edge gateway and the cloud server send heartbeat packets at fixed time intervals to determine the network connectivity between them. For example, the cloud server sends a heartbeat packet to the edge gateway every 3 seconds.

[0073] Step S202: The edge gateway determines whether the number of consecutive heartbeat packet losses exceeds the loss count threshold.

[0074] The threshold for the number of lost records can be set according to actual needs; for example, the threshold for the number of lost records can be 3. This application does not limit the value of the threshold for the number of lost records.

[0075] Specifically, if the number of consecutive heartbeat packet losses exceeds the loss threshold, it indicates that the network connection between the edge gateway and the cloud server is interrupted, and step S203 is executed; if the number of consecutive heartbeat packet losses is less than the loss threshold, it indicates that the network connection between the edge gateway and the cloud server is normal, and step S204 is executed.

[0076] Step S203: The edge gateway enters offline disaster recovery mode.

[0077] Specifically, when the network connection between the edge gateway and the cloud server is interrupted, the edge gateway enters offline disaster recovery mode, that is, the edge gateway drives the embedded intelligent terminal to perform basic services based on locally cached vehicle status information, received service tasks and control logic.

[0078] Step S204: The edge gateway will synchronize the execution records to the cloud server in real time.

[0079] The execution log can be understood as the log of the edge gateway driving the embodied smart terminal to perform various services.

[0080] Step S205: The edge gateway incrementally synchronizes the execution records during the offline period to the cloud server.

[0081] Specifically, after the network connection between the edge gateway and the cloud server is restored, the edge gateway can incrementally synchronize the execution records during the offline period to the cloud server according to the timestamp. This function is automatically triggered and requires no manual intervention.

[0082] like Figure 3 As shown, the vehicle-machine cloud collaborative system provided in this application adopts a four-layer distributed architecture of cloud-edge-vehicle-machine: cloud intelligent scheduling layer 301, edge protocol gateway layer 302, vehicle terminal interaction layer 303, and embodied intelligent terminal layer 304.

[0083] Among them, the cloud-based intelligent scheduling layer 301 can be deployed on the TSP cloud platform to receive vehicle status information, generate service tasks, and issue scheduling instructions.

[0084] The cloud-based intelligent scheduling layer 301 provided in this application embodiment can be implemented by reusing the existing TSP platform and adding an embodied intelligent service scheduling module.

[0085] The Edge Protocol Gateway Layer 302 can be deployed on the local server of a 4S store or the local server of a parking lot for protocol conversion, data caching, offline disaster recovery, and command issuance.

[0086] The edge protocol gateway layer 302 provided in this application embodiment can be implemented by adding a software module to the existing 4S store's DMS system without modifying the network infrastructure.

[0087] The vehicle terminal interaction layer 303 can be deployed in the vehicle online diagnostic system (OBD) module or the vehicle system to collect vehicle controller area network (CAN) bus data, perform format conversion, and upload data.

[0088] The embodied intelligent terminal layer 304 can be deployed in 4S store service robots to receive task instructions from the edge gateway, perform physical actions, and transmit environmental perception data.

[0089] In some embodiments, the embodied smart terminal layer 304 may also be referred to as the robot layer. The name of the embodied smart terminal layer 304 is not limited in this application embodiment.

[0090] The embodied smart terminal layer 304 provided in this application embodiment can be implemented by purchasing third-party commercial equipment and connecting through software adaptation.

[0091] Based on the aforementioned four-layer collaborative architecture of cloud-edge-vehicle-machine, this application provides an Embodied AI-IoV Collaborative Protocol (EACP).

[0092] Figure 4 This is a schematic diagram illustrating the structure of a vehicle-to-everything (V2X) intelligent collaborative protocol provided in an embodiment of this application. Figure 4 As shown, the EACP protocol is divided into three sub-protocols: Vehicle State Semantic Layer (VSS), Intent Service Description Layer (ISD), and Robot Action Atomic Layer (RAA).

[0093] The VSS layer is deployed at the vehicle terminal interaction layer. The VSS layer is used to convert the acquired raw signals from the vehicle CAN bus into standardized semantic data in JSON-LD format.

[0094] Specifically, the VSS layer can be configured to receive the raw binary signals from the CAN bus of different vehicle models and map them into unified JSON-LD format semantic data to mask vehicle model differences and provide a unified data format.

[0095] For example, the VSS layer can map the 3rd and 4th bytes of the CAN ID 0x123 of vehicle model A to the VSS field "vehicleSpeed"; the VSS layer can also map the 1st and 2nd bytes of the CAN ID 0x456 of vehicle model B to "vehicleSpeed".

[0096] The VSS semantic protocol can unify the in-vehicle data format of different car models, eliminating the need for customized modifications for individual car models, greatly reducing adaptation costs, adapting to different car models, breaking down data barriers, and achieving full vehicle compatibility.

[0097] The ISD layer is deployed at the edge protocol gateway layer. The ISD layer is used to convert service tasks issued by the cloud server into task instructions in Protobuf binary format.

[0098] The service tasks issued by the cloud server are in JSON format. JSON format is a human-friendly text format, while Protobuf binary format is a machine-friendly format, such as machine code and instructions that are directly executed by a smart terminal.

[0099] The data output from the ISD layer may include the target vehicle's identity number (ID), service type code, and service parameters.

[0100] The target vehicle ID can be the license plate of the target vehicle.

[0101] Service type codes are used to describe the type of service tasks that the embodied smart terminal needs to perform, such as greeting services, appearance inspection services, parking guidance services, etc.

[0102] Service parameters can be understood as the specific configurations or data required for the intelligent terminal to perform the service task. For example, for a welcome service, service parameters might include the way to address the car owner; for an exterior inspection service, service parameters might specify which angles of photos need to be taken.

[0103] By converting service tasks issued by the cloud server into task instructions in Protobuf binary format, the amount of data transmitted can be compressed and the service intent can be standardized.

[0104] The RAA layer is deployed at the embodied smart terminal layer. The RAA layer is used to convert the service tasks (i.e., task instructions) parsed by the ISD layer into action instructions in JSON-RPC 2.0 format.

[0105] Among them, JSON-RPC 2.0 format action instructions are atomic action instructions that can be executed by a smart terminal (such as a robot).

[0106] For example, a JSON-RPC 2.0 format action instruction can be {"method": "moveTo", "params":{"x": 10, "y": 20}}; {"method": "speak", "params": {"text": "Welcome to the store"}}.

[0107] Furthermore, an adapter can be configured on the embodied smart terminal side to convert the action commands output by the RAA layer into proprietary control commands for each brand of embodied smart terminal. By combining the EACP protocol with the adapter, embodied smart terminals from different brands can access the vehicle-to-cloud collaborative system provided in this application embodiment without hardware modification, thereby improving compatibility and reducing mass production costs.

[0108] Optionally, the vehicle-machine cloud collaborative system provided in this application embodiment can also integrate the smart terminal adapter into the vehicle OBD interface module, eliminating the need for a separate adapter on the smart terminal side, achieving one-stop adaptation on the vehicle side, and is suitable for exclusive scenarios of fixed brand robots.

[0109] Optionally, the Protobuf binary format of the ISD layer can also be JSON. The VSS layer can also choose to use XML format to encapsulate and express standardized semantic data, as an alternative to the JSON-LD format. The core four-layer architecture and bidirectional collaborative logic remain unchanged, achieving the same functionality as the EACP protocol, with only a slight decrease in transmission efficiency.

[0110] By using the EACP protocol described above, data transmission volume can be compressed, response latency reduced, and system stability improved. Edge gateways handle data locally, and collaborative response latency is controlled to within 3 seconds, far superior to the latency of over 5 seconds in existing technologies.

[0111] Based on the vehicle-machine cloud collaborative system provided in the embodiments of this application, this application also designs the following security mechanism.

[0112] The security mechanism for the communication layer between the vehicle terminal and the cloud server is as follows: When establishing a network communication connection between the vehicle terminal and the cloud server, standard transport layer encryption can be implemented using TLS 1.3 + AES-256-GCM encryption.

[0113] The security mechanism for the communication layer between the edge gateway and the embodied smart terminal is as follows: When establishing a communication connection between the edge gateway and the embodied smart terminal, WPA3-Enterprise or physical isolation can be used to achieve local network security.

[0114] A local network refers to the same local area network where the edge gateway and the embodied smart terminal reside. For example, the edge gateway and embodied smart terminal deployed in a 4S store or parking lot are usually connected through the store's Wi-Fi or wired network, forming an internal network that is isolated from or controllable from the external public network.

[0115] WPA3-Enterprise is currently the newest and most secure commercial Wi-Fi security protocol. It requires smart terminals and other devices to perform enhanced authentication (usually using username / password or digital certificate) and to encrypt transmitted data with high strength when accessing a local Wi-Fi network. This effectively prevents unauthorized devices from accessing the network or eavesdropping on network communications.

[0116] Physical isolation is a more direct security measure, referring to the complete physical separation of network communication between the edge gateway and the embedded smart terminal from other networks (such as office Wi-Fi and guest Wi-Fi). For example, a dedicated switch or network segment can be set up separately for the edge gateway and the embedded smart terminal, without connection to the external network. This method physically eliminates the possibility of external attacks.

[0117] The security mechanism of the vehicle-side authentication layer is as follows: During the process of establishing a secure connection between the vehicle terminal and the cloud server, both parties can verify each other's identity through pre-issued and installed digital certificates (such as X.509 certificates) to achieve two-way authentication, so as to ensure that the other party in the communication is a legitimate and trustworthy device, rather than a fake or unauthorized terminal.

[0118] For example, when an in-vehicle terminal attempts to connect to a cloud server, it first presents its X.509 certificate to the cloud server. The cloud server verifies whether the X.509 certificate presented by the in-vehicle terminal was issued by a trusted Certificate Authority (CA), whether it is valid, and whether it has been revoked. Simultaneously, the cloud server also presents its X.509 certificate to the in-vehicle terminal, which performs the same verification. Only after both parties have successfully verified each other's certificates is a secure connection established, and subsequent encrypted communication (such as TLS 1.3 + AES-256-GCM) can then proceed.

[0119] The security mechanism of the edge authentication layer is as follows: When the edge gateway communicates with other devices in the vehicle-to-cloud collaborative system (such as cloud servers and smart terminals), OAuth 2.0 tokens can be used for authentication.

[0120] For example, before communicating with the cloud server, the edge gateway can prove its identity to the cloud server using the standard OAuth 2.0 protocol. After successful authentication, the cloud server will issue an access token with a time expiration period (e.g., the token may be valid for 24 hours) to the edge gateway. In subsequent communications with the cloud server, the edge gateway presents this access token to the cloud server. The cloud server verifies the validity of the access token to complete the continuous authentication of the edge gateway's identity, without having to repeatedly submit sensitive credentials such as usernames and passwords.

[0121] The security mechanism of the embodied smart terminal authentication layer is as follows: During the process of establishing a communication connection between the edge gateway and the embodied smart terminal, the identity of the embodied smart terminal can be verified by periodically rotating the pre-shared key (PSK).

[0122] Among them, key rotation refers to generating a new pre-shared key at fixed intervals to replace the old pre-shared key.

[0123] The security mechanism for access control hierarchy is as follows: This application can achieve access control for each device in the vehicle-machine cloud collaborative system by adopting a hierarchical data reading method.

[0124] For example, data can be classified according to the sensitivity and importance of the data transmitted and stored in the vehicle-machine cloud collaborative system or the usage scenario. Then, different data access permissions can be set for different visitors in the vehicle-machine cloud collaborative system (such as smart terminals, cloud servers, edge gateways, car owners, service personnel, etc.), allowing only the reading of data within the scope of the data access permissions.

[0125] It should be noted that the smart terminal only reads publicly available status data and has no vehicle control permissions.

[0126] Through the aforementioned dual encryption and access control security mechanisms, vehicle status information (such as core vehicle condition data) can be protected from leakage and unauthorized control, in accordance with automotive industry data security standards.

[0127] Figure 5 This is a schematic diagram of a security mechanism provided in an embodiment of this application, such as... Figure 5 As shown, the security mechanism provided in this application embodiment can be implemented by the following modules: transmission encryption module 501, device identity authentication module 502, and data permission hierarchical control module 503.

[0128] Among them, the transmission encryption module 501 is used to implement the security mechanism of the communication layer between the vehicle terminal and the cloud server and the communication layer between the edge gateway and the embodied smart terminal; the device identity authentication module 502 is used to implement the security mechanism of the vehicle authentication layer, the edge authentication layer and the embodied smart terminal authentication; and the data permission hierarchical control module 503 is used to implement the security mechanism of the permission control layer.

[0129] The integration method between the vehicle-machine cloud collaborative system provided in this application embodiment and the existing system is described below.

[0130] When the vehicle-machine cloud collaborative system is integrated with the TSP platform, it reuses the existing vehicle data access channel, adds a new "embodied intelligent service" data type identifier, and adds a service scheduling module in the cloud to run in parallel with the existing vehicle control module.

[0131] When the vehicle-machine cloud collaborative system is integrated with the 4S store DMS system, the edge gateway connects with the DMS through a RESTful API, and the environmental perception data obtained by the smart terminal is automatically written into the customer profile.

[0132] Optionally, when the vehicle-to-infrastructure (V2I) cloud collaboration system is integrated with the vehicle system, the vehicle models that support the application installation can develop a vehicle-to-infrastructure (V2I) APP, which obtains data through the Android Automotive OS standard API and does not directly access the CAN bus to ensure security.

[0133] The vehicle-machine cloud collaborative system provided in this application embodiment is applicable to a range of vehicle types including but not limited to: passenger cars, hybrid vehicles, and pure electric vehicles, covering all categories of passenger vehicles such as sedans, SUVs, and MPVs, and can also be extended to commercial vehicles and special vehicles for park shuttles.

[0134] The specific application scenarios of the vehicle-machine cloud collaborative system provided in this application include, but are not limited to: intelligent after-sales service of car 4S stores, linkage of home intelligent garages, vehicle shuttle of intelligent parking lots in commercial complexes, remote assisted repair of vehicles with road malfunctions, linkage of user welcoming vehicles, and collaboration between autonomous driving vehicles and service robots in parks.

[0135] The vehicle-machine cloud collaborative system architecture provided in this application embodiment is compatible with the following: it is compatible with existing vehicle-machine systems, TSP vehicle networking service platforms, and 4S store after-sales management systems. It does not require overturning the existing architecture, but only requires adding an edge gateway module and a protocol adaptation layer, making the transformation difficult.

[0136] The vehicle-machine cloud collaborative system provided in this application embodiment can be used in new scenarios such as intelligent welcome service in 4S stores, self-service maintenance, intelligent parking lot shuttle, and roadside assistance. The following description uses the intelligent welcome service in 4S stores as an example to illustrate the vehicle-machine cloud collaborative system provided in this application embodiment.

[0137] Figure 6 This is a flowchart illustrating an application scenario example of a vehicle-machine cloud collaborative system provided in this application embodiment.

[0138] The following are the prerequisites that the vehicle, 4S store, and car owner must meet in this application scenario: Vehicle: EACP OBD module or vehicle infotainment software has been installed.

[0139] 4S stores: Edge gateways and service robots have been deployed.

[0140] Car owner: I have authorized the 4S store to obtain the vehicle's location information.

[0141] Step S601: When the vehicle terminal detects that a vehicle has entered the geofence, it uploads the vehicle status information to the cloud server.

[0142] Specifically, the vehicle's onboard terminal can obtain the vehicle's GPS location and compare it with the pre-configured geofence of the 4S store. When the vehicle's GPS location is detected to be within the geofence, the vehicle's onboard terminal automatically collects vehicle status information (such as location information) and uploads the vehicle status information to the cloud server.

[0143] Then, the vehicle terminal converts the vehicle status information into JSON-LD format through the VSS layer, and then uploads it to the cloud server via an encrypted TLS channel through the 4G / 5G network.

[0144] Among them, the 4S store geofence refers to the electronic fence centered on the 4S store. For example, the radius of the 4S store geofence can be 500 meters.

[0145] Step S602: The cloud server sends the service task to the edge gateway.

[0146] Specifically, after receiving vehicle status information, the cloud server can identify the vehicle's destination as the 4S store through map or business system matching. After confirming that the vehicle's destination is the 4S store, the cloud server automatically generates service tasks, such as a welcome service task, according to preset business logic.

[0147] The service task may include the target vehicle ID (such as license plate) and service type (such as welcoming guests), and the service task can be described in a standardized ISD format.

[0148] Then, the cloud server sends the above service tasks to the edge gateway corresponding to the target 4S store through a secure link.

[0149] Step S603: The edge gateway wakes up the embodied smart terminal.

[0150] In this embodiment, the embodied intelligent terminal can be a welcoming robot.

[0151] Specifically, after receiving a service task, the edge gateway converts the task into action commands that the welcoming robot can execute, such as moving to the waiting area. The action commands are then sent to the welcoming robot to wake it up from standby. Simultaneously, the edge gateway caches the service task and vehicle status data locally to prepare for potential network outages (i.e., offline disaster recovery).

[0152] Step S604: The embodied smart terminal executes a physical action based on the action command.

[0153] Specifically, after the vehicle arrives at the store and comes to a complete stop, the welcoming robot uses a camera to recognize the license plate and confirm that the vehicle that has arrived at the store is the target vehicle specified in the service task.

[0154] After confirming the target vehicle, the welcoming robot performs welcoming services, such as giving a voice greeting, guiding parking, and taking photos of the exterior.

[0155] For example, a welcoming robot can play a welcome message and then guide the driver to park in a designated or suitable parking space through voice, light, or screen instructions. At the same time, it can take panoramic photos of the vehicle's exterior for archiving or quick exterior inspection.

[0156] Step S605: The cloud server synchronizes the environmental perception data uploaded by the smart terminal to the DMS system.

[0157] Specifically, the smart terminal will encode the license plate recognition results, the captured exterior photos, and other environmental perception data into RAA format and send them back to the edge gateway. The edge gateway will then upload the environmental perception data to the cloud server, and the cloud server will synchronize the aforementioned environmental perception data to the 4S store's DMS system and the car owner's APP.

[0158] For example, after the cloud server synchronizes the above environmental perception data to the 4S store's DMS system, the service advisor's workstation will pop up a prompt showing "The customer with license plate XX has arrived at the store, and exterior photos have been taken." The service advisor can then proactively go to greet the customer, achieving seamless service integration.

[0159] After the cloud server synchronizes the above environmental perception data to the car owner's mobile app, the car owner can immediately view the notification and photos of "Your vehicle has arrived at the store and the exterior inspection has been completed".

[0160] Step S606: If the edge gateway detects an interruption in the network connection with the cloud server, the edge gateway performs a basic welcome based on the local cache.

[0161] Basic greeting refers to the greeting service performed when the real-time location of the vehicle cannot be obtained.

[0162] For example, the edge gateway drives the welcoming robot to perform a set of preset basic welcoming procedures (e.g., moving to a fixed point to give a general voice greeting) based on vehicle data cached locally before the network interruption (e.g., knowing that a vehicle is about to arrive at the store). However, it cannot achieve license plate recognition and personalized guidance that depend on real-time location.

[0163] If the edge gateway detects that the welcome robot is unresponsive or reports a fault, it will upload the fault information to the cloud server. Upon receiving this information, the cloud server will push it to the car owner's app, where the owner can receive a notification to guide them to the store. For example, the cloud server might send a message to the owner's app saying, "Sorry, the welcome robot is temporarily unavailable. Please come to the store yourself."

[0164] This application also provides a vehicle-machine cloud collaboration method, which is applied to the above-mentioned vehicle-machine cloud collaboration system. Figure 7 This is a flowchart illustrating a vehicle-machine-cloud collaborative method provided in an embodiment of the present invention.

[0165] like Figure 7 As shown, the vehicle-to-cloud collaboration method provided in this application embodiment may include: Step S701: The vehicle terminal obtains vehicle status information and uploads the vehicle status information to the cloud server.

[0166] For a description of this step, please refer to [link / reference]. Figure 1 The description of the vehicle-mounted terminal in the illustrated embodiment will not be repeated here.

[0167] Step S702: The cloud server generates a service task based on the vehicle status information and sends the service task to the edge gateway.

[0168] For a description of this step, please refer to [link / reference]. Figure 1 The description of the cloud server in the illustrated embodiment will not be repeated here.

[0169] Step S703: The edge gateway converts the service task into an action command and sends the action command to the embodied smart terminal.

[0170] For a description of this step, please refer to [link / reference]. Figure 1 The description of the edge gateway in the illustrated embodiment will not be repeated here.

[0171] Step S704: The embodied smart terminal responds to the action command and executes a physical action.

[0172] For a description of this step, please refer to [link / reference]. Figure 1 The description of the embodied smart terminal in the illustrated embodiments will not be repeated here.

[0173] like Figure 8 As shown, the computer device provided in this application embodiment may include a processor 801, a bus 802, a communication interface 803, and a memory 804. The processor 801, memory 804, and communication interface 803 communicate with each other via the bus 802. It should be understood that this application does not limit the number of processors and memories in the network device.

[0174] The 802 bus can be a PCI bus, an Extended Industry Standard Architecture (EISA) bus, or a UB bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 8 The bus 802 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 802 may include a path for transmitting information between various components of the network device (e.g., memory 804, processor 801, communication interface 803).

[0175] Processor 801 may include any one or more processors such as CPU, graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0176] The memory 804 may include volatile memory, such as random access memory (RAM). The processor 801 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0177] The communication interface 803 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between network devices and other devices or communication networks.

[0178] The memory 804 stores executable program code, and the processor 801 executes the executable program code to implement the functions of the aforementioned method embodiments. That is, the memory 804 stores instructions for executing the above-described vehicle-to-cloud collaborative method.

[0179] In another aspect, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the vehicle-machine-cloud collaborative method as provided in the above-described method embodiments.

[0180] On another front, a computer program product is provided, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the vehicle-machine-cloud collaboration method provided in the above-described method embodiments is implemented.

[0181] Through the above description of the implementation methods, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the module can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, modules, and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0182] Since the vehicle-machine cloud collaboration module, computer-readable storage medium, and computer program product in the embodiments of the present invention can be applied to the above methods, the technical effects that can be obtained can also be referred to the above method embodiments. The embodiments of the present invention will not be repeated here.

[0183] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. One exemplary embodiment couples a storage medium to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a network device. Of course, the processor and storage medium can also exist as discrete components in the network device.

[0184] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, the processes or functions of the embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable module. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0185] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vehicle-machine cloud collaborative system, characterized in that, The system includes: The vehicle-mounted terminal is used to acquire vehicle status information and upload the vehicle status information to a cloud server. A cloud server is used to generate service tasks based on the vehicle status information and send the service tasks to the edge gateway. An edge gateway is used to convert the service tasks into action commands and send the action commands to the embody smart terminal. The smart terminal is used to perform physical actions in response to the action command.

2. The system according to claim 1, characterized in that, The edge gateway is also used for: After determining that the network connection between the edge gateway and the cloud server is interrupted, the service task is transformed into a disaster recovery control instruction based on the local vehicle status information. The disaster recovery control instruction is used to control the embodied smart terminal to perform basic service actions in the offline state. The disaster recovery control command is sent to the embodied smart terminal.

3. The system according to claim 2, characterized in that, The determination that the network connection between the edge gateway and the cloud server is interrupted includes: Obtain the heartbeat packet sent by the cloud server; When the number of consecutive heartbeat packet losses exceeds a threshold, it is determined that the network connection between the edge gateway and the cloud server is interrupted.

4. The system according to claim 1, characterized in that, The step of generating a service task based on the vehicle status information includes: The vehicle status information is matched with preset business rules to obtain the service task. The preset business rules refer to the correspondence between the vehicle status information and the service task built into the cloud server.

5. The system according to claim 1, characterized in that, The vehicle-mounted terminal is also used for: Acquire raw signals from the vehicle's CAN bus; The vehicle status information is obtained by standardizing and semantically converting the original signals of the vehicle CAN bus.

6. The system according to claim 1, characterized in that, The embodied intelligent terminal is also used to acquire environmental perception data and send the environmental perception data to the edge gateway; The edge gateway is also used to upload the environmental perception data to the cloud server; The cloud server is also used to send the environmental perception data to the vehicle owner's application terminal for the vehicle owner to make vehicle control decisions.

7. A vehicle-machine-cloud collaborative method, characterized in that, An application is made to a vehicle-to-infrastructure (V2I) cloud-based collaborative system, comprising: an in-vehicle terminal for acquiring vehicle status information and uploading the vehicle status information to a cloud server; a cloud server for generating service tasks based on the vehicle status information and sending the service tasks to an edge gateway; an edge gateway for converting the service tasks into action commands and sending the action commands to a embodied intelligent terminal; and an embodied intelligent terminal for performing physical actions in response to the action commands. The method includes: The vehicle-mounted terminal acquires vehicle status information and uploads the vehicle status information to the cloud server; The cloud server generates a service task based on the vehicle status information and sends the service task to the edge gateway. The edge gateway converts the service task into an action command and sends the action command to the embodied smart terminal; The embodied smart terminal responds to the action command and performs a physical action.

8. A computer device, characterized in that, The computer device includes a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the vehicle-machine-cloud collaborative method as described in claim 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the vehicle-machine-cloud collaborative method as described in claim 7.

Images