Vehicle-mounted communication method and device, computer device and storage medium

Abstract

The application provides a vehicle-mounted communication method and device, computer equipment and a storage medium, and belongs to the technical field of vehicles. The method comprises the following steps: analyzing a request CAN message of a client to obtain a request identifier and request message content of the client carried by the request CAN message, wherein the request message content comprises a server identifier, a service identifier and request data; in the case that the server identifier is an identifier of a target server, calling a target vehicle service indicated by the service identifier based on the request data to obtain response data; and returning a response CAN message to the client based on the request identifier of the client, wherein the response CAN message carries a response identifier and response message content of the target server, and the response message content comprises the server identifier, the service identifier, a service execution state and the response data. Compared with the calling mode through a CAN signal, the above technical solution reduces the testing and verification cost when the vehicle service is expanded.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, in particular to a vehicle communication method and device, computer equipment and a storage medium. BACKGROUND

[0002] With the development of vehicle intelligence, vehicle communication networks have gradually developed into networks that provide vehicle services. The vehicle services include opening a central lock, opening an air conditioner, or one-key ventilation, etc. In the whole vehicle electronic control, when multiple initiator controllers call the same vehicle service, each initiator controller defines different CAN (Controller Area Network) signals and sends them to the executor controller respectively, so as to realize the vehicle service call.

[0003] The above technical solution has the problem that the number of input signal interfaces of the executor controller is large, and the control logic is complex. When the vehicle service request is expanded, the newly added vehicle service will change the software of the executor controller, thereby increasing the testing and verification cost. SUMMARY

[0004] The embodiments of the present application provide a vehicle communication method and device, computer equipment and a storage medium, which realize the way of calling a vehicle service through a CAN message, compared with the way of calling through a CAN signal. When the vehicle service is expanded, the server does not need to change the software, but only needs to change the content of the message to adaptively realize the expanded service, thereby reducing the testing and verification cost. The technical solution is as follows:

[0005] In one aspect, a vehicle communication method is provided, applied to a target server, and the method comprises:

[0006] parsing a request CAN message of a client to obtain a request identifier and a request message content of the client carried by the request CAN message, the request message content comprising a server identifier, a service identifier and request data, the client being any client connected to a CAN of a vehicle;

[0007] in a case where the server identifier is an identifier of the target server, calling a target vehicle service indicated by the service identifier based on the request data to obtain response data;

[0008] returning a response CAN message to the client based on the request identifier of the client, the response CAN message carrying a response identifier and a response message content of the target server, the response message content comprising the server identifier, the service identifier, a service execution state and the response data.

[0009] In another aspect, a vehicle-mounted communication method is provided, which is applied to a target client, and the method comprises:

[0010] sending a request CAN message on a CAN of a vehicle, the request CAN message being used to request calling a target vehicle service, the request CAN message carrying a request identifier and a request message content of the target client, the request message content comprising a server identifier, a service identifier and request data of the target server;

[0011] receiving a response CAN message returned by the target server based on the CAN of the vehicle;

[0012] parsing the response CAN message to obtain a response identifier and a response message content of the target server carried by the response CAN message, the response message content comprising the server identifier, the service identifier, a service execution status and response data.

[0013] In another aspect, a vehicle-mounted communication device is provided, which is applied to a target server, and the device comprises:

[0014] a parsing module, configured to parse a request CAN message of a client to obtain a request identifier and a request message content of the client carried by the request CAN message, the request message content comprising a server identifier, a service identifier and request data, the client being any client connected to a CAN of a vehicle;

[0015] a calling module, configured to, in a case where the server identifier is an identifier of the target server, call a target vehicle service indicated by the service identifier based on the request data to obtain response data;

[0016] a first returning module, configured to return a response CAN message to the client based on the request identifier of the client, the response CAN message carrying a response identifier and a response message content of the target server, the response message content comprising the server identifier, the service identifier, a service execution status and the response data.

[0017] In some embodiments, the parsing module is configured to parse a message header of the request CAN message of the client to obtain the request identifier of the client, and parse a message body of the request CAN message of the client to obtain the request message content, the request message content comprising eight bytes, a first byte, a seventh byte and an eighth byte being reserved bytes for extending other vehicle services, a second byte being the server identifier, a third byte being the service identifier, a fourth byte being a service execution status, and a fifth byte being the request data.

[0018] In some embodiments, the device further comprises:

[0019] an ignoring module, configured to ignore the request CAN message when the service end identifier is not the target service end identifier.

[0020] In some embodiments, the apparatus further includes:

[0021] a determining module, configured to determine a response duration of the target service end from receiving the request CAN message to obtaining the response data.

[0022] a first generating module, configured to generate the response CAN message when the response duration is not greater than a preset response duration.

[0023] In some embodiments, the apparatus further includes:

[0024] a second generating module, configured to generate response failure information when the response duration is greater than the preset response duration, the response failure information being used to indicate that the request CAN message is not successfully responded.

[0025] a second returning module, configured to return the response failure information to the client based on the request identifier of the client.

[0026] In another aspect, a vehicle-mounted communication apparatus is provided, applied to a target client, and the apparatus includes:

[0027] a sending module, configured to send a request CAN message on a CAN of a vehicle, the request CAN message being used to request to invoke a target vehicle service, the request CAN message carrying a request identifier of the target client and request message content, the request message content including a service end identifier of a target service end, a service identifier, and request data.

[0028] a receiving module, configured to receive a response CAN message returned by the target service end based on the CAN of the vehicle.

[0029] a parsing module, configured to parse the response CAN message to obtain the response identifier of the target service end and response message content carried by the response CAN message, the response message content including the service end identifier, the service identifier, a service execution state, and response data.

[0030] In some embodiments, the parsing module is configured to parse a message header of the response CAN message to obtain a response identifier of the target service end; and parse a message body of the response CAN message to obtain the response message content, wherein the response message content includes 8 bytes, the first byte, the seventh byte and the eighth byte are reserved bytes for extending other vehicle services, the second byte is the service end identifier, the third byte is the service identifier, the fourth byte data is the service execution status, and the fifth byte is the response data.

[0031] In some embodiments, the device further comprises:

[0032] The determining module is configured to determine a request duration between sending the request CAN message and receiving the response CAN message.

[0033] The ignoring module is configured to, in a case where the request duration is greater than a preset request duration, determine that the request fails, and ignore the response CAN message.

[0034] In another aspect, a computer device is provided, which comprises a processor and a memory, the memory being configured to store at least one piece of computer program, the at least one piece of computer program being loaded and executed by the processor to implement any of the vehicle-mounted communication methods in the embodiments of the present application.

[0035] In another aspect, a computer readable storage medium is provided, which stores at least one piece of computer program, the at least one piece of computer program being loaded and executed by a processor to implement any of the vehicle-mounted communication methods in the embodiments of the present application.

[0036] The embodiments of the present application provide a vehicle-mounted communication method, which can determine whether to call a vehicle service provided by a target service end by parsing a request CAN message on a CAN network by the target service end. If a service end identifier in the request CAN message is an identifier of the target service end, the target service end will call a target vehicle service requested in the request CAN message. After the calling is completed, the target service end returns a response CAN message to the client, thereby realizing a manner of calling a vehicle service through a CAN message. Compared with a manner of calling through a CAN signal, when a vehicle service is extended, the service end does not need to be changed in software, but only needs to change the content of the message to adaptively realize the extended service, thereby reducing the testing and verification cost. BRIEF DESCRIPTION OF DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0038] Figure 1 is a schematic diagram of an implementation environment of a vehicle-mounted communication method according to an embodiment of the present application;

[0039] Figure 2 is a flowchart of a vehicle-mounted communication method applied to a target server according to an embodiment of the present application;

[0040] Figure 3 is a flowchart of a vehicle-mounted communication method applied to a target client according to an embodiment of the present application;

[0041] Figure 4 is an interaction flowchart of a target client and a target server according to an embodiment of the present application;

[0042] Figure 5 is an interaction schematic diagram of a target client and a target server according to an embodiment of the present application;

[0043] Figure 6 is a vehicle-mounted communication schematic diagram for implementing a central locking service according to an embodiment of the present application;

[0044] Figure 7 is a block diagram of a vehicle-mounted communication device applied to a target server according to an embodiment of the present application;

[0045] Figure 8 is a block diagram of another vehicle-mounted communication device applied to a target server according to an embodiment of the present application;

[0046] Figure 9 is a block diagram of a vehicle-mounted communication device applied to a target client according to an embodiment of the present application;

[0047] Figure 10 is a block diagram of another vehicle-mounted communication device applied to a target client according to an embodiment of the present application. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical solutions and advantages of the present application more clear, the embodiments of the present application will be further described in detail with reference to the drawings.

[0049] The terms "first", "second", and the like are used herein to distinguish between similar items or items of the same type, and it should be understood that there is no logical or chronological dependency between "first", "second", and "nth", and there is no limitation on the number and execution order.

[0050] The term "at least one" in the present application refers to one or more, and the term "multiple" refers to two or more.

[0051] The terms involved in the present application are explained as follows.

[0052] CAN (Controller Area Network) is one of the most widely used field buses in the world. CAN bus protocol has become a standard bus for automotive computer control systems and embedded industrial control LAN, and is widely used in automotive computer control systems and industrial environments with harsh environmental temperature, strong electromagnetic radiation and strong vibration.

[0053] The vehicle-mounted communication method provided by the embodiments of the present application can be executed by a computer device. In some embodiments, the computer device is a terminal or a server. Figure 1 is a schematic diagram of an implementation environment of a vehicle-mounted communication method according to an embodiment of the present application. Referring to Figure 1 , the implementation environment includes a target client 101 and a target server 102.

[0054] The target client 101 and the target server 102 can be directly or indirectly connected through wired or wireless communication, which is not limited in the present application.

[0055] In some embodiments, the target client 101 is a TBOX (Telematics Box, remote communication terminal), an IHU (Infotainment Head Unit, vehicle-mounted entertainment information system), or a VCU (Vehicle Control Unit, vehicle controller), but is not limited thereto. The target client 101 is installed and runs an application program supporting vehicle-mounted communication.

[0056] In some embodiments, the target server 102 is a BCM (Body Control Module, vehicle body control module) and an ACCM (Air-Condition Control Module, air conditioner control module), but is not limited thereto.

[0057] Figure 2 is a flowchart of a vehicle-mounted communication method applied to a target server according to an embodiment of the present application, as shown in Figure 2As shown, in the embodiments of the present application, the method is described by taking the execution by the target server as an example. The method comprises the following steps:

[0058] 201. The target server parses the request CAN message of the client to obtain the request identifier and the request message content of the client carried by the request CAN message, wherein the request message content comprises the server identifier, the service identifier and the request data, and the client is any client of the CAN network of the vehicle.

[0059] In the embodiments of the present application, the target server is used to execute the vehicle service. For example, the BCM (Body Control Module) can execute the vehicle service of controlling the central lock, controlling the light and power management, etc., and the ACCM (Air-Condition Control Module) can execute the vehicle service of controlling the air conditioner. The client is any terminal of the CAN network of the vehicle, such as the TBOX (Telematics Box), the IHU (Infotainment Head Unit) or the VCU (Vehicle Control Unit). When any client wants to call any vehicle service controlled by the target server, such as opening the central lock, opening the air conditioner or one-key ventilation, etc., the client can send a request CAN message on the vehicle CAN network, and the target server acquires and parses the request CAN message on the vehicle CAN network, thereby realizing the vehicle communication.

[0060] It should be noted that multiple clients can simultaneously send multiple request CAN messages to the vehicle CAN network. For any request CAN message, the target server can parse the request CAN message to obtain the request identifier and the request message content of the client. By parsing the request CAN message, the content of the request CAN message can be determined, so as to determine the corresponding server according to the message content to execute the vehicle service.

[0061] 202. In the case where the server identifier is the identifier of the target server, the target server calls the target vehicle service indicated by the service identifier based on the request data to obtain the response data.

[0062] In the embodiments of the present application, since multiple clients are connected to the vehicle CAN network, the multiple clients send multiple request CAN messages on the vehicle CAN network. The vehicle services requested by the multiple request CAN messages can be the same or different, and different servers execute different vehicle services, so it is necessary to determine whether the request CAN message parsed in the above steps is sent to the target server.

[0063] Since one service end corresponds to one service end identifier, when the service end identifier of the request CAN message is the identifier of the target service end, that is, the client sends the request CAN message to the target service end, the target vehicle service requested by the client is executed by the target service end. Then, the target service end can call the target vehicle service to obtain the response data of the target service end. The service identifier is used to identify the data representation of the target vehicle service requested by the client in the request CAN message. By calling the target vehicle service to obtain the response data in the case that the target vehicle service requested by the client is executed by the target service end, the response CAN message of the target service end is generated.

[0064] 203、The target service end returns a response CAN message to the client based on the request identifier of the client, and the response CAN message carries the response identifier and the response message content of the target service end, and the response message content includes the service end identifier, the service identifier, the service execution state, and the response data.

[0065] In the embodiment of the application, after the target service end completes the calling of the target vehicle service, since one client corresponds to one request identifier, the target service end can return a response CAN message to the corresponding client based on the request identifier. The response CAN message carries the execution result of the target vehicle service by the target service end. For example, it is assumed that the client sends a request CAN message to request to open the central lock, and generates a response CAN message after the target service end is unlocked. Then, the target service end sends the response CAN message to the corresponding client based on the request identifier. By returning the response CAN message to the client based on the request identifier of the client, the vehicle communication based on the CAN message can be realized.

[0066] The embodiment of the application provides a vehicle communication method, which can determine whether to call the vehicle service provided by the target service end by analyzing the request CAN message on the CAN network by the target service end. If the service end identifier in the request CAN message is the identifier of the target service end, the target vehicle service requested in the request CAN message will be called by the target service end. After the calling is completed, the target service end returns a response CAN message to the client, so as to realize the calling of the vehicle service through the CAN message. Compared with the calling through the CAN signal, when the vehicle service is expanded, the service end does not need to be changed, and only the content of the message needs to be changed to adaptively realize the expanded service, so that the test and verification cost is reduced.

[0067] Figure 3 is a flowchart of another vehicle communication method applied to a target client according to the embodiment of the application, as shown in Figure 3As shown, in the embodiments of the present application, the method is described by taking the execution by the target client as an example. The method comprises the following steps.

[0068] 301. The target client sends a request CAN message on the CAN of the vehicle, the request CAN message being used to request to call the target vehicle service, and the request CAN message carrying a request identifier of the target client and a request message content, the request message content comprising a server identifier of the target server, a service identifier, and request data.

[0069] In the embodiments of the present application, since the vehicle CAN network accesses a plurality of clients, the plurality of clients can call the vehicle service through the CAN message. When the target client wants to call any target vehicle service, the target client can send a request CAN message to the vehicle CAN network, so that the corresponding target server can execute the target vehicle service, thereby realizing the vehicle communication. The target client is any terminal accessed by the vehicle CAN network, such as a TBOX (Telematics Box, remote communication terminal), an IHU (Infotainment Head Unit, vehicle entertainment information system), or a VCU (Vehicle Control Unit, vehicle controller).

[0070] 302. The target client receives a response CAN message returned by the target server based on the CAN of the vehicle.

[0071] In the embodiments of the present application, when the target server completes the call of the target vehicle service requested by the target client, the target server can return a response CAN message to the target client. Then, the target client can receive the response CAN message through the vehicle CAN network, thereby realizing the vehicle communication.

[0072] 303. The target client parses the response CAN message to obtain a response identifier of the target server and a response message content carried by the response CAN message, the response message content comprising a server identifier, a service identifier, a service execution state, and response data.

[0073] In the embodiments of the present application, taking the request CAN message sent by the target client to request to start the air conditioner as an example, the corresponding target server can generate a response CAN message and return the response CAN message to the target client after starting the air conditioner. Then, the target client can parse the response CAN message to obtain the execution result of the target vehicle service by the target server, thereby realizing the vehicle communication.

[0074] The embodiment of the present application provides a vehicle-mounted communication method, a target client sends a request CAN message to a CAN network to call a target vehicle service. After a target service end calls the target vehicle service requested by the target client, a response CAN message can be returned to the target client. The target client can receive and analyze the response CAN message, so that the vehicle service calling mode through the CAN message is realized. Compared with the vehicle service calling mode through different CAN signals by multiple clients, the unique service interface, i.e., the CAN message, can simplify the control logic of vehicle-mounted communication, so that the test and verification cost is reduced.

[0075] Figure 4 The embodiment of the present application provides an interaction flowchart of a target client and a target service end, as shown in Figure 4 The method comprises the following steps:

[0076] 401. The target client sends a request CAN message based on a vehicle CAN, the request CAN message is used for requesting to call a target vehicle service, the request CAN message carries a request identifier of the target client and request message content, and the request message content comprises a service end identifier, a service identifier and request data of the target service end.

[0077] In the embodiment of the present application, when the target client requests to call the target vehicle service, the request CAN message can be sent on the accessed vehicle CAN network, so that the vehicle-mounted communication process is started. The request CAN message carries the request identifier and the request message content.

[0078] 402. The target service end analyzes the request CAN message of the target client, and obtains the request identifier and the request message content of the target client carried in the request CAN message.

[0079] In the embodiment of the present application, the target service end can receive the request CAN message from the vehicle CAN network. Then, the target service end can analyze the request CAN message, obtain the request identifier and the request message content of the target client, and determine the target service end that can execute the target vehicle service requested to be called in the request CAN message, so as to prepare for realizing the vehicle-mounted communication.

[0080] In some embodiments, the target server can obtain the request identifier and the request message content by analyzing the request CAN message. Accordingly, the target server analyzes the message header of the request CAN message of the target client to obtain the request identifier of the target client. Then, the target server analyzes the message body of the request CAN message of the target client to obtain the request message content, which includes 8 bytes. The first byte, the seventh byte and the eighth byte are reserved bytes for extending other vehicle services. The second byte is the server identifier. The third byte is the service identifier. The fourth byte is the service execution status. The fifth byte is the request data. The request identifier is used to identify that the CAN message is a service request message. The interval of the request identifier is 0x5A0-0x5BF. The server identifier is used to identify the controller that can execute the target vehicle service, for example, the BCM controller is 0x1A and the ACCM controller is 0x1B. The service identifier is used to identify the vehicle service that the target server can execute, for example, the BCM target server includes the central lock sub-service 0x0001, the brake light sub-service 0x0002 or the one-key ventilation sub-service 0x0003. The service execution status is the preset 0x00, indicating that the service request is normal. The request data is the target client service request data value, for example, for the central lock service, the request data sent by the target client for unlocking is 0x01. By analyzing the request CAN message, the request identifier and the content of each byte in the request message content can be obtained, thereby preparing for calling the target vehicle service.

[0081] It should be noted that the first byte, the seventh byte and the eighth byte are used to extend other vehicle services, but the data of the newly added vehicle service is not randomly filled in the three reserved bytes. For any newly added vehicle service, the target server and the target client can obtain the byte data of the vehicle service based on the vehicle service, so as to fill the byte data of the vehicle service into the corresponding byte.

[0082] 403、In the case that the server identifier is the identifier of the target server, the target server calls the target vehicle service indicated by the service identifier based on the request data to obtain the response data.

[0083] In the embodiments of the present application, since multiple clients are connected to the vehicle CAN network, the multiple clients can send multiple request CAN messages on the vehicle CAN network for calling the same or different vehicle services. There are also multiple servers in the vehicle for executing different vehicle services. Therefore, it is necessary to determine whether the target client is the target server sending the request CAN message, that is, by judging whether the server identifier is the identifier of the target server, so that the target vehicle service requested by the target client can be executed by the corresponding target server, thereby realizing the vehicle communication.

[0084] In some embodiments, when the service identifier is the identifier of the target service end, that is, the target client sends the request CAN message to the target service end. Since the target service end can execute multiple vehicle services, the target service end invokes the target vehicle service indicated by the service identifier based on the request data in the request CAN message, obtains the response data for the target vehicle service, and generates a response CAN message, thereby realizing vehicle communication.

[0085] In some embodiments, when the service identifier is not the identifier of the target service end, that is, the target client does not send the CAN message to the target service end. At this time, the target service end cannot execute the target vehicle service requested by the target client. At this time, the target service end will ignore the request CAN message and continue to receive and parse the next request CAN message. Through the service identifier and the identifier of the target service end, it can be determined whether the request CAN message of the target client is sent to the target service end, so that different operations can be performed to improve the efficiency of vehicle communication.

[0086] 404, the target service end determines the response time from receiving the request CAN message to obtaining the response data.

[0087] In the embodiments of the present application, the target service end can determine the response time from receiving the request CAN message to obtaining the response data. Then, the target service end can perform different operations through the size relationship between the response time and the preset response time. The preset response time can be 100 milliseconds, 120 milliseconds or 150 milliseconds, and the embodiments of the present application do not limit this. By determining the response time, it can be determined whether the target service end responds successfully, thereby realizing vehicle communication.

[0088] In some embodiments, in the case where the response time is greater than the preset response time, the target service end fails to respond at this time. The target service end can generate a response failure information and return the response failure information to the target client corresponding to the request identifier. The response failure information is used to indicate that the request CAN message is not successfully responded. Correspondingly, in the case where the response time is greater than the preset response time, the target service end generates a response failure information. Then, the target service end returns the response failure information to the client based on the request identifier of the client. Through the size relationship between the response time and the preset response time, it can be determined whether the target service end responds successfully, thereby different operations can be performed to improve the efficiency of vehicle communication.

[0089] In some embodiments, in the case where the response time is not greater than the preset response time, the target service end responds successfully at this time. The target service end can return the response CAN message generated when the response is successful to the target client by performing the following steps 405-407, thereby realizing vehicle communication.

[0090] 405、In the case that the response duration is not greater than the preset response duration, the target service end generates a response CAN message, and the response CAN message carries a response identifier and a response message content of the target service end, and the response message content includes a service end identifier, a service identifier, a service execution state and response data.

[0091] In the embodiment of the application, in the case that the response duration is not greater than the preset response duration, that is, the target service end responds successfully. At this time, the target service end generates a response CAN message based on the execution result of the target vehicle service, so as to return the response CAN message to the target client, thereby realizing the vehicle-mounted communication.

[0092] 406、The target service end returns the response CAN message to the target client based on the request identifier of the client.

[0093] In the embodiment of the application, since the vehicle CAN network accesses a plurality of clients, and one client corresponds to one request identifier, the target service end can return the response CAN message to the corresponding target client based on the request identifier, thereby realizing the vehicle-mounted communication.

[0094] 407、The target client receives the response CAN message returned by the target service end based on the CAN of the vehicle.

[0095] In the embodiment of the application, the target client can receive the execution result of the target vehicle service, that is, the response CAN message, by the vehicle CAN network, thereby realizing the vehicle-mounted communication.

[0096] In some embodiments, the target client determines the request duration between sending the request CAN message and receiving the response CAN message, and then performs different operations based on the size relationship between the request duration and the preset request duration. The preset request duration can be 200 milliseconds, 220 milliseconds or 250 milliseconds, and the embodiments of the application do not limit this. Correspondingly, in the case that the request duration is greater than the preset request duration, it is determined that the request fails, and the target client ignores the response CAN message. In the case that the request duration is not greater than the preset request duration, it is determined that the request is successful, that is, the steps 401-408 are successfully executed. Then, the target client analyzes the response CAN message through the following step 408, so as to obtain the execution result of the target vehicle service.

[0097] 408、The target client analyzes the response CAN message to obtain the response identifier and the response message content of the target service end carried by the response CAN message.

[0098] In the embodiments of the present application, the target client can receive the response CAN message from the vehicle CAN network. Then, the target client can parse the response CAN message to obtain the response identifier and the response message content, so as to obtain the execution result of the target vehicle service.

[0099] In some embodiments, the target client can obtain the response identifier and the response message content by parsing the response CAN message. Accordingly, the target client parses the message header of the response CAN message of the target service end to obtain the response identifier of the target service end. Then, the target client parses the message body of the response CAN message of the target service end to obtain the response message content, which includes 8 bytes. The first byte, the seventh byte and the eighth byte are reserved bytes for extending other vehicle services. The second byte is a service end identifier. The third byte is a service identifier. The fourth byte is a service execution status. The fifth byte is response data. The response identifier is used to identify that the CAN message is a service response message, and the interval of the response identifier is 0x5D0-0x5EF. The service end identifier is used to identify the controller that can execute the target vehicle service, for example, the BCM controller is 0x1A, and the ACCM controller is 0x1B. The service identifier is used to identify the vehicle service that can be executed by the target service end, for example, the BCM target service end includes the central lock service 0x0001, the brake light service 0x0002 or the one-key ventilation service 0x0003. The service execution status is used to identify the execution success or failure of the target vehicle service, which can be represented by 0x00 for execution success and 0x01 for execution failure. The response data is the service response data value of the target service end, for example, for the central lock service, the response data returned by the target service end for unlocking is 0x01. By parsing the response CAN message, the content of each byte in the response identifier and the response message content can be obtained, so that the execution result of the target vehicle service requested by the target client can be obtained.

[0100] It should be noted that the first byte, the seventh byte and the eighth byte are all used to extend other vehicle services, but the data of the newly added vehicle service is not randomly filled in the three reserved bytes. For any newly added vehicle service, the target service end and the target client can obtain the byte data of the vehicle service based on the data of the vehicle service, so as to fill the byte data of the vehicle service into the corresponding byte.

[0101] It should be noted that for vehicle services with encryption requirements, a security check service can be extended in the vehicle communication process between the target service end and the target client, so as to meet the control requirements of vehicle service security and vehicle CAN network security. The byte data of the security check service can be filled in the reserved bytes of the request CAN message and the response CAN message.

[0102] For example, Figure 5 is an interaction schematic diagram of a target client and a target server provided by an embodiment of the present application. As shown in Figure 5 , the target client and the target server interact through steps 401-408 described above, thereby realizing vehicle-mounted communication.

[0103] For example, taking the target client calling the central lock service as an example, the vehicle-mounted communication process of the target client and the target server is described. Figure 6 is a vehicle-mounted communication schematic diagram for realizing the central lock service provided by an embodiment of the present application. As shown in Figure 6As shown, the target client can be any one of the TBOX, the IHU or the VCU, and the target server can be the BCM. The target client accesses the vehicle CAN network and sends a request CAN message for opening the central lock on the vehicle CAN network. The request CAN message is (0x5A0 00 1A 00 01 00 01 00 00). 0x5A0 is used to represent the request identifier of the target client; 00 represents a reserved byte, which is filled with 00 when no new vehicle service is added; 1A is the server identifier, indicating the BCM controller providing the central lock service, that is, the target server; 00 01 is the service identifier, indicating the central lock service provided by the BCM; 00 is the service execution state, which is the preset value of the target client, indicating that the service request is normal; 01 is the central lock request data value of the target client, that is, unlocking the central lock; 00 represents a reserved byte; and 00 represents a reserved byte. Then, the target server receives the request CAN message and parses the request CAN message to obtain the request identifier 0x5A0 of the target client and the request message content (00 1A 00 01 00 01 00 00). Then, the parsed server identifier 1A is the identifier 1A of the target server BCM, that is, the request CAN message is sent to the BCM. Then, the BCM calls the central lock service based on the target vehicle service indicated by the service identifier 00 01, and obtains the response data as 01. Then, the response time of the BCM is calculated as 70 milliseconds, which is less than the preset response time 100 milliseconds, indicating that the BCM responds successfully. Then, the BCM generates a response CAN message. The response CAN message is (0x5D0 00 1A 00 01 00 01 00 00). 0x5D0 is used to represent the response identifier of the target server; 00 represents a reserved byte, which is filled with 00 when no new vehicle service is added; 1A is the server identifier, indicating the BCM controller providing the central lock service, that is, the target server; 00 01 is the service identifier, indicating the central lock service provided by the BCM; 00 is the service execution state, which is filled with 00 when the target server is successfully executed; 01 is the central lock response data value of the target server, that is, unlocking the central lock; 00 represents a reserved byte; and 00 represents a reserved byte. Then, the target server returns the response CAN message to the target client based on the request identifier 0x5A0 of the target client. Then, the target client receives the response CAN message through the vehicle CAN network. Then, the target client determines the request time between sending the request CAN message and receiving the response CAN message as 150 milliseconds. Since the request time 150 milliseconds is less than the preset request time 200 milliseconds, it is determined that the request is successful. Then, the target client can parse the response CAN message to obtain the response identifier 0x5D0 of the target server and the response message content (001A 00 01 00 01 00 00).

[0104] The embodiment of the present application provides a vehicle-mounted communication method, which can determine whether to call a vehicle service provided by a target service end by analyzing a request CAN message on a CAN network by the target service end. If the service end identifier in the request CAN message is the identifier of the target service end, then the target service end will call the target vehicle service requested in the request CAN message. After the calling is completed, the target service end returns a response CAN message to the client, so that the vehicle service calling mode through the CAN message is realized. Compared with the calling mode through the CAN signal, when the vehicle service is extended, the service end does not need to be changed in software, but only needs to change the content of the message to adaptively realize the extended service, so that the test and verification cost is reduced.

[0105] Figure 7 is a block diagram of a vehicle-mounted communication device applied to a target service end according to the embodiment of the present application. The device is used to execute the steps in the method, and the device is shown in Figure 7 The device includes an analysis module 701, a calling module 702 and a returning module 703.

[0106] The analysis module 701 is used to analyze the request CAN message of the client, to obtain the request identifier and the request message content of the client carried in the request CAN message, wherein the request message content includes the service end identifier, the service identifier and the request data, and the client is any client of the CAN access of the vehicle;

[0107] The calling module 702 is used to call the target vehicle service indicated by the service identifier based on the request data in the case that the service end identifier is the identifier of the target service end, to obtain the response data;

[0108] The first returning module 703 is used to return the response CAN message to the client based on the request identifier of the client, wherein the response CAN message carries the response identifier and the response message content of the target service end, and the response message content includes the service end identifier, the service identifier, the service execution state and the response data.

[0109] In some embodiments, Figure 8 is another block diagram of a vehicle-mounted communication device applied to a target service end according to the embodiment of the present application. Referring to Figure 8 The analysis module 701 is used to analyze the message header of the request CAN message of the client, to obtain the request identifier of the client; and analyze the message body of the request CAN message of the client, to obtain the request message content, wherein the request message content includes eight bytes, the first byte, the seventh byte and the eighth byte are reserved bytes for extending other vehicle services, the second byte is the service end identifier, the third byte is the service identifier, the fourth byte is the service execution state, and the fifth byte is the request data.

[0110] In some embodiments, referring to Figure 8 The apparatus further includes, as shown in

[0111] The ignoring module 704 is configured to ignore the request CAN message in a case where the service end identifier is not the identifier of the target service end.

[0112] In some embodiments, referring to Figure 8 The apparatus further includes, as shown in

[0113] The determining module 705 is configured to determine a response duration of the target service end from receiving the request CAN message to obtaining the response data.

[0114] The first generating module 706 is configured to generate a response CAN message in a case where the response duration is not greater than a preset response duration.

[0115] In some embodiments, referring to Figure 8 The apparatus further includes, as shown in

[0116] The second generating module 707 is configured to generate a response failure information in a case where the response duration is greater than the preset response duration, the response failure information being used to indicate that the request CAN message is not successfully responded.

[0117] The second returning module 708 is configured to return the response failure information to the client based on the request identifier of the client.

[0118] The embodiments of the present application provide a vehicle-mounted communication apparatus. By analyzing the request CAN message on the CAN network by the target service end, it can be determined whether to call the vehicle service provided by the target service end. If the service end identifier in the request CAN message is the identifier of the target service end, the target service end will call the target vehicle service requested in the request CAN message. After the calling is completed, the target service end returns a response CAN message to the client, so as to realize the calling of the vehicle service through the CAN message. Compared with the calling through the CAN signal, when the vehicle service is expanded, the service end does not need to be changed, and only the content of the message needs to be changed to adaptively realize the expanded service, so as to reduce the test and verification cost.

[0119] It should be noted that: the vehicle-mounted communication apparatus provided in the above embodiments is running an application, and only the division of the above functional modules is exemplified, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the apparatus is divided into different functional modules to complete all or part of the functions described above. In addition, the vehicle-mounted communication apparatus and the vehicle-mounted communication method provided in the above embodiments belong to the same concept, and the specific implementation process is described in the method embodiments, which will not be repeated here.

[0120] Figure 9 is a block diagram of a vehicle-mounted communication device applied to a target client according to an embodiment of the present application. The device is used to execute the steps in the method described above, see Figure 9 , the device comprises a sending module 901, a receiving module 902 and an analysis module 903.

[0121] The sending module 901 is configured to send a request CAN message on the CAN of the vehicle, the request CAN message being used to request to call a target vehicle service, the request CAN message carrying a request identifier of the target client and a request message content, the request message content comprising a server identifier of the target server, a service identifier and request data.

[0122] The receiving module 902 is configured to receive a response CAN message returned by the target server based on the CAN of the vehicle.

[0123] The analysis module 903 is configured to analyze the response CAN message to obtain a response identifier of the target server and a response message content carried by the response CAN message, the response message content comprising the server identifier, the service identifier, a service execution state and response data.

[0124] In some embodiments, Figure 10 is another block diagram of a vehicle-mounted communication device applied to a target client according to an embodiment of the present application. Referring to 10, the analysis module 903 is configured to analyze a message header of the response CAN message to obtain a response identifier of the target server, and analyze a message body of the response CAN message to obtain a response message content, the response message content comprising eight bytes, the first byte, the seventh byte and the eighth byte being reserved bytes for extending other vehicle services, the second byte being the server identifier, the third byte being the service identifier, the fourth byte data being the service execution state, and the fifth byte being the response data.

[0125] In some embodiments, referring to Figure 10 , the device further comprises:

[0126] The determination module 904 is configured to determine a request duration between sending the request CAN message and receiving the response CAN message.

[0127] The ignoring module 905 is configured to determine that the request fails and ignore the response CAN message in a case where the request duration is greater than a preset request duration.

[0128] The embodiment of the present application provides a vehicle-mounted communication device, a target client calls a target vehicle service by sending a request CAN message to a CAN network. After the target service end calls the target vehicle service requested by the target client, a response CAN message can be returned to the target client. The target client can receive and analyze the response CAN message, so that the vehicle service calling mode through the CAN message is realized. Compared with the vehicle service calling mode through different CAN signals by multiple clients, the unique service interface, i.e., the CAN message, can simplify the control logic of vehicle-mounted communication, thereby reducing the test and verification cost.

[0129] It should be noted that the vehicle-mounted communication device provided by the above embodiment is used to run an application program, and the above-mentioned functions are only used as an example for the division of the functional modules. In actual application, the above-mentioned functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the vehicle-mounted communication device and the vehicle-mounted communication method provided by the above embodiment belong to the same concept, and the specific implementation process is described in the method embodiment, which will not be repeated here.

[0130] In the embodiment of the present application, the computer device can be configured as a target client or a target service end. When the computer device is configured as a target client, the target client can be used as an execution subject to implement the technical solution provided by the embodiment of the present application. When the computer device is configured as a target service end, the target service end can be used as an execution subject to implement the technical solution provided by the embodiment of the present application. The technical solution provided by the present application can also be implemented through the interaction between the target client and the target service end, and the embodiment of the present application does not limit this.

[0131] The embodiment of the present application further provides a computer readable storage medium, and the computer readable storage medium stores at least one computer program. The at least one computer program is loaded and executed by a processor to implement the vehicle-mounted communication method applied to the target client in the embodiment of the present application, or the at least one computer program is loaded and executed by the processor to implement the vehicle-mounted communication method applied to the target service end in the embodiment of the present application.

[0132] Those skilled in the art can understand that all or part of the steps of the above-mentioned embodiments can be completed by hardware, or the program can be used to instruct the related hardware to complete, and the program can be stored in a computer readable storage medium. The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk.

[0133] The above merely provides the optional embodiments of the present application, and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A vehicle-mounted communication method characterized by comprising: The method is applied to a target service end, the target service end is a body control module, the target service end is used for executing a vehicle service, the vehicle service includes at least one of controlling a central lock, controlling light, power management and controlling air conditioning, and the method includes: Parses a message header of a request CAN message of a client to obtain a request identifier of the client; and parses a message body of the request CAN message of the client to obtain request message content, the request message content including a service end identifier, a service identifier and request data, the client being any client of CAN access of a vehicle; the request message content including 8 bytes, the first byte, the seventh byte and the eighth byte being reserved bytes for extending other vehicle services, the second byte being the service end identifier, the third byte being the service identifier, the fourth byte being a service execution state, and the fifth byte being the request data; In a case where the service end identifier is an identifier of the target service end, a target vehicle service indicated by the service identifier is called based on the request data to obtain response data; A response time length of the target service end from receiving the request CAN message to obtaining the response data is determined; in a case where the response time length is greater than a preset response time length, response failure information is generated, the response failure information being used for indicating that the request CAN message is not successfully responded; and the response failure information is returned to the client based on the request identifier of the client; In a case where the response time length is not greater than the preset response time length, a response CAN message is generated; and the response CAN message is returned to the client based on the request identifier of the client, the response CAN message carrying a response identifier of the target service end and response message content, the response message content including the service end identifier, the service identifier, the service execution state and the response data, the response message content including 8 bytes, the first byte, the seventh byte and the eighth byte being reserved bytes for extending other vehicle services, the second byte being the service end identifier, the third byte being the service identifier, the fourth byte data being the service execution state, and the fifth byte being the response data; byte data of any added vehicle service and byte data of a security check service being filled in the corresponding reserved bytes of the request CAN message and the response CAN message; In a case where the service end identifier is not the identifier of the target service end, the request CAN message is ignored.

2. A vehicle-mounted communication method characterized by comprising: The method is applied to a target client, and the method includes: A vehicle-based CAN transmits a request CAN message, the request CAN message being used to request to invoke a target vehicle service, the request CAN message carrying a request identifier and a request message content of the target client, the request message content including a service identifier, a service identifier and request data of a target service, and the target service ignoring the request CAN message in a case where the service identifier is not an identifier of the target service; the target service is configured to execute a vehicle service, the target service being a body control module, and the vehicle service including at least one of controlling a central lock, controlling a light, power management and controlling an air conditioner; the request message content includes 8 bytes, the first byte, the seventh byte and the eighth byte are reserved bytes for extending other vehicle services, the second byte is the service identifier, the third byte is the service identifier, the fourth byte is a service execution state, and the fifth byte is the request data; The vehicle-based CAN receives a response CAN message returned by the target service, the response CAN message being generated in a case where a response time length is not greater than a preset response time length, and the response time length being a time length from receiving the request CAN message to obtaining response data of the target service; The response CAN message is parsed to obtain a response identifier and a response message content of the target service carried by the response CAN message, the response message content including the service identifier, the service identifier, a service execution state and the response data, the response message content including 8 bytes, the first byte, the seventh byte and the eighth byte being reserved bytes for extending other vehicle services, the second byte being the service identifier, the third byte being the service identifier, the fourth byte being the service execution state, and the fifth byte being the response data; byte data of any newly added vehicle service and byte data of a security check service are filled in the corresponding reserved bytes of the request CAN message and the response CAN message; The response CAN message of the parsing client is parsed to obtain a response identifier and a response message content of the target service carried by the response CAN message, including: The message header of the response CAN message is parsed to obtain the response identifier of the target service; The message body of the response CAN message is parsed to obtain the response message content; Before the response CAN message is parsed to obtain the response identifier and the response message content of the target service carried by the response CAN message, the method further includes: Determining a request time length between transmitting the request CAN message and receiving the response CAN message; In a case where the request time length is greater than a preset request time length, determining that the request fails, and ignoring the response CAN message.

3. An in-vehicle communication device characterized by comprising: The application is applied to a target service, the target service being a body control module, the target service being configured to execute a vehicle service, the vehicle service including at least one of controlling a central lock, controlling a light, power management and controlling an air conditioner, and the device including: The analysis module is configured to analyze a message header of a request CAN message of a client to obtain a request identifier of the client, and analyze a message body of the request CAN message of the client to obtain request message content, the request message content including a server identifier, a service identifier, and request data, the client being any client of a CAN access of a vehicle. The calling module is configured to, when the server identifier is an identifier of the target server, call a target vehicle service indicated by the service identifier based on the request data to obtain response data, determine a response duration of the target server from receiving the request CAN message to obtaining the response data, generate response failure information when the response duration is greater than a preset response duration, the response failure information being used to indicate that the request CAN message is not successfully responded, return the response failure information to the client based on the request identifier of the client, and generate a response CAN message when the response duration is not greater than the preset response duration. The first returning module is configured to return the response CAN message to the client based on the request identifier of the client, the response CAN message carrying a response identifier and response message content of the target server, the response message content including the server identifier, the service identifier, a service execution state, and the response data, the response message content including eight bytes, the first byte, the seventh byte, and the eighth byte being reserved bytes used to expand other vehicle services, the second byte being the server identifier, the third byte being the service identifier, the fourth byte data being the service execution state, and the fifth byte being the response data, byte data of any added vehicle service, and byte data of a security check service being filled in the reserved bytes corresponding to the request CAN message and the response CAN message.

4. An in-vehicle communication device characterized by comprising: The device is applied to a target client and includes: The sending module is configured to send a request CAN message on a CAN of a vehicle, the request CAN message being used to request calling a target vehicle service, the request CAN message carrying a request identifier of the target client and request message content, the request message content including a service identifier of a target service end, a service identifier, and request data, and the target service end ignoring the request CAN message in a case where the service identifier is not an identifier of the target service end; the target service end is configured to execute a vehicle service, the target service end being a body control module, and the vehicle service including at least one of controlling a central lock, controlling a light, power management, and controlling an air conditioner; the request message content includes 8 bytes, a first byte, a seventh byte, and an eighth byte being reserved bytes used to extend other vehicle services, a second byte being the service identifier, a third byte being the service identifier, a fourth byte being a service execution state, and a fifth byte being the request data; The receiving module is configured to receive a response CAN message returned by the target service end based on the CAN of the vehicle, the response CAN message being generated in a case where a response time length is not greater than a preset response time length, the response time length being a time length from receiving the request CAN message to obtaining response data of the target service end; The analyzing module is configured to analyze the response CAN message to obtain a response identifier of the target service end and response message content carried by the response CAN message, the response message content including the service identifier, the service identifier, a service execution state, and response data, the response message content including 8 bytes, a first byte, a seventh byte, and an eighth byte being reserved bytes used to extend other vehicle services, a second byte being the service identifier, a third byte being the service identifier, a fourth byte being the service execution state, and a fifth byte being the response data; byte data of any newly added vehicle service and byte data of a security check service being filled in corresponding reserved bytes of the request CAN message and the response CAN message.

5. A computer device, comprising: The computer device includes a processor and a memory, the memory being used to store at least one piece of computer program, the at least one piece of computer program being loaded and executed by the processor to execute the vehicle-mounted communication method in claim 1, or the at least one piece of computer program being loaded and executed by the processor to execute the vehicle-mounted communication method in claim 2.

6. A computer-readable storage medium, characterized in that, The computer readable storage medium is used to store at least one piece of computer program, the at least one piece of computer program being used to execute the vehicle-mounted communication method in claim 1, or the at least one piece of computer program being used to execute the vehicle-mounted communication method in claim 2.

Images