Service architecture of vehicle chassis, communication method, electronic equipment and storage medium
By introducing service registration modules and chassis control modules into the smart chassis, a unified service management and target service interface is achieved, the problem of poor interoperability between the smart chassis and the upper body is solved, and cross-platform compatibility and expansion are improved.
Patent Information
- Application Number
- CN202411635067.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-15
- Publication Date
- 2025-03-11
AI Technical Summary
The communication between the existing smart chassis and the upper body depends on private protocols developed within the enterprise, resulting in poor interoperability between the chassis systems and the upper body of different manufacturers, limiting the compatibility and expansion of the smart chassis when cross-platform.
It provides a service architecture for vehicle chassis, including service registration module and chassis control module. Through a unified service management interface and target service interface, it realizes compatibility and expansion between different types of vehicle body and vehicle chassis.
It improves cross-platform and cross-vendor compatibility, reduces the communication complexity between the vehicle body and the vehicle control unit, and enables the vehicle control unit to focus on providing atomized services efficiently.
Smart Images
Figure CN119603368A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle technology, and in particular to a service architecture, communication method, electronic equipment and storage medium of a vehicle chassis. Background Art
[0002] With the rapid development of the automobile industry, smart cars have become the main development trend in the future. New technologies such as smart driving, automatic driving, and smart control are increasingly used in vehicles, and the electronic and electrical architecture of vehicle systems is gradually developing from centralized to distributed and integrated. Especially in the field of smart chassis, traditional chassis systems are gradually upgraded to smart chassis, integrating more sensors, electronic control units (ECUs) and communication interfaces to achieve precise control, intelligent feedback, and coordinated operation with other vehicle systems.
[0003] However, the current communication between the smart chassis and the upper body still relies on private protocols developed within the enterprise, resulting in poor interoperability between chassis systems and upper bodies from different manufacturers, thereby limiting the compatibility and scalability of the smart chassis across platforms. Summary of the invention
[0004] The present application provides a service architecture, communication method, electronic device and storage medium for a vehicle chassis to solve or partially solve the problem of how to improve the compatibility and scalability between different types of upper bodies and vehicle chassis.
[0005] In a first aspect, the present application provides a vehicle chassis service architecture, the service architecture at least comprising a service registration module and a chassis control module, the service registration module comprising a service management interface, the chassis control module being communicatively connected to the upper vehicle body; wherein, The service registration module is used to receive service registration requests and service registration information sent by each vehicle control unit, perform a registration operation on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtain a target service interface corresponding to the vehicle control unit, and store the target service interface in a callable service list; The chassis control module is used to receive a service call request sent by the upper body, determine a target service interface corresponding to the service call request from the callable service list, access the vehicle control unit in real time through the target service interface, and send a service execution command to the vehicle control unit.
[0006] In one example, the service registration module includes a security unit and a corresponding security interface; The security unit is used to call the key acquisition function of the security interface to extract the first communication key, and extract the second communication key from the service registration information; Performing key verification on the first communication key and the second communication key; When the key verification between the first communication key and the second communication key succeeds, a registration operation is performed on the vehicle control unit according to the service registration information and the service registration function of the service management interface.
[0007] In one example, the service registration module includes a test unit and a corresponding test interface; The test unit is used to call the test function of the test interface to perform functional verification on the test items of the vehicle control unit; When the functional verification of each test item of the vehicle control unit is passed, a service identifier is allocated to each atomic service of the vehicle control unit; The service identifier and the service registration information are used to define the interface of the atomic service of the vehicle control unit to obtain a target service interface for the vehicle control unit.
[0008] In one example, the chassis control module is used to return the callable service list to the upper vehicle body, and receive a service call request returned by the upper vehicle body based on the callable service list; The key acquisition function of the security interface is called to extract the temporary encryption key, so that the upper vehicle body uses the temporary encryption key to encrypt the service call request.
[0009] In one example, the chassis control module includes a communication unit and a corresponding protocol interface; The communication unit is used to call the protocol acquisition function of the protocol interface to obtain the communication protocol type, and return the communication protocol type to the upper body, so that when the upper body sends a service call request, it determines the communication protocol matching the chassis control module through the communication protocol type.
[0010] In one example, the chassis control module further includes a communication interface corresponding to the communication unit, and the service call request includes a service identifier of the upper vehicle body request; The communication unit is used to determine the vehicle-mounted control unit corresponding to the service identifier; The write data function of the communication interface is called to forward the packaged service call request to the vehicle-mounted control unit.
[0011] In one example, the service architecture further includes a service failure module; The service fault module is used to trigger a retry strategy when detecting that the service registration module and / or the chassis control module is in an abnormal working state; The retry strategy includes the number of retries and the time interval between each retry.
[0012] A second aspect of the present application provides a communication method, which is applied to a service architecture of a vehicle chassis, wherein the service architecture is communicatively connected to an upper vehicle body, and the method comprises: Receive service registration requests and service registration information sent by each vehicle control unit; Performing a registration operation on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtaining a target service interface corresponding to the vehicle control unit, and storing the target service interface in a callable service list; Receiving a service call request sent by the upper vehicle body, and determining a target service interface corresponding to the service call request from the callable service list; The vehicle-mounted control unit is accessed in real time through the target service interface, and a service execution command is sent to the vehicle-mounted control unit.
[0013] A third aspect of the present application provides an electronic device, including: Processor; and The memory stores executable codes thereon, and when the executable codes are executed by the processor, the processor is caused to execute the method as described above.
[0014] A fourth aspect of the present application provides a computer-readable storage medium having executable code stored thereon. When the executable code is executed by a processor of an electronic device, the processor is caused to execute the method as described above.
[0015] The technical solution provided by this application may have the following beneficial effects: In an embodiment of the present application, the service architecture of the vehicle chassis includes at least a service registration module and a chassis control module, the service registration module includes a service management interface, and the chassis control module is communicatively connected to the upper vehicle body; wherein, the service registration module is used to receive service registration requests and service registration information sent by each vehicle control unit, perform registration operations on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtain a target service interface corresponding to the vehicle control unit, and store the target service interface in a callable service list; the chassis control module is used to receive a service call request sent by the upper vehicle body, determine the target service interface corresponding to the service call request from the callable service list, access the vehicle control unit in real time through the target service interface, and send a service execution command to the vehicle control unit.
[0016] Compared with the related technologies, the technical solution of the present application, on the one hand, improves cross-platform and cross-manufacturer compatibility by introducing a unified service management interface and a targeted target service interface, while being easy to expand; on the other hand, the service registration module can ensure that different types of vehicle control units are registered and provide standardized service interfaces, providing a list of callable services for the chassis control module, and with the coordinated action of the chassis control module, the service call request can be accurately mapped to the target service interface, thereby reducing the complexity of communication between the vehicle body and each vehicle control unit, allowing the vehicle control unit to focus on efficiently providing atomic services.
[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] The above and other objects, features and advantages of the present application will become more apparent by describing in more detail the exemplary embodiments of the present application in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the present application.
[0019] Figure 1 is a structural schematic diagram of a service architecture of a vehicle chassis shown in an embodiment of the present application; Figure 2 is a schematic diagram of the connection relationship between various interfaces shown in the embodiment of the present application; Figure 3 is a schematic diagram of the interaction between the service architecture of the vehicle chassis and the upper vehicle body shown in an embodiment of the present application; Figure 4 It is a schematic diagram of the registration and calling process of the VCU service shown in the embodiment of the present application; Figure 5 It is a flow chart of a communication method shown in an embodiment of the present application; Figure 6 It is a schematic diagram of the structure of an electronic device shown in an embodiment of the present application. DETAILED DESCRIPTION
[0020] The embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although the embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided to make the present application more thorough and complete, and to fully convey the scope of the present application to those skilled in the art.
[0021] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.
[0022] It should be understood that although the terms "first", "second", "third", etc. may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of this application, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined.
[0023] Currently, the communication between the intelligent chassis and the upper body usually relies on private protocols developed by various manufacturers. Although this approach meets the needs of specific manufacturers in the short term, in the long run, this reliance on private protocols leads to poor interoperability between systems, insufficient compatibility, and limited scalability.
[0024] For example, one manufacturer's chassis system may not be able to communicate directly with another manufacturer's upper body system. Instead, it needs to go through cumbersome protocol conversion or rely on middleware to achieve data exchange and service calls. This not only increases the complexity of system integration, but also reduces the flexibility and scalability of the system.
[0025] In response to the above problems, an embodiment of the present application provides a service architecture for a vehicle chassis, which can improve the compatibility and scalability between different types of upper bodies and vehicle chassis.
[0026] The technical solution of the embodiments of the present application is described in detail below with reference to the accompanying drawings.
[0027] Figure 1 is a structural diagram of a service architecture of a vehicle chassis shown in an embodiment of the present application. Figure 1 The service architecture at least includes a service registration module 100 and a chassis control module 200. The service registration module 100 includes a service management interface, and the chassis control module 200 is connected to the upper vehicle body in communication; wherein, The service registration module 100 is used to receive the service registration request and service registration information sent by each vehicle control unit, perform a registration operation on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtain the target service interface corresponding to the vehicle control unit, and store the target service interface in the callable service list; The chassis control module 200 is used to receive a service call request sent by the vehicle body, determine the target service interface corresponding to the service call request from the callable service list, access the vehicle control unit in real time through the target service interface, and send a service execution command to the vehicle control unit.
[0028] In the embodiment of the present application, the service architecture of the vehicle chassis refers to the service-oriented and modular technical architecture obtained by combining the central control unit (CCU) of the intelligent chassis with the service-oriented architecture (SOA). It is actually one of the important components of the intelligent vehicle chassis system, and supports interoperability between different hardware platforms and software modules through standardized service interfaces and protocols.
[0029] SOA is a coarse-grained, loosely coupled service architecture. Each atomic service provides a specific function or business process. Atomic services can communicate with each other through simple, precisely defined interfaces. These services are usually cross-platform, cross-language and cross-vendor, and can easily achieve interoperability between different systems, applications and platforms.
[0030] In the SOA service framework, service is the basic unit of the system. Each service implements a specific function or task. The vehicle control unit needs to actively request registration of services so that other systems or modules can find, discover and call these services through the registration center.
[0031] The service registration module 100 in the service architecture of the present application can register the on-board control unit into the callable service list of the preset database through a standardized service interface, so that the upper body system can obtain the target service interface through the callable service list, and the chassis control module 200 can find the corresponding target service interface from the callable service list through the received service call request, access the on-board control unit in real time, and instruct the on-board control unit to perform service operations through the service execution command.
[0032] It can be understood that the SOA-based service framework of the present application implements standardized service interface and protocol management through the design of the service registration module 100 and the chassis control module 200, eliminates the protocol differences between different platforms, and thus realizes cross-vendor and cross-platform communication.
[0033] As an example of the present application, the SOA-based service framework includes a service registration module 100, which includes a service management interface. The service registration module 100 is mainly used to receive service registration requests and service registration information sent by each vehicle control unit, perform registration operations on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtain the target service interface corresponding to the vehicle control unit, and store the target service interface in a callable service list.
[0034] The vehicle control unit refers to the various control modules or control systems in the vehicle, which are responsible for performing specific vehicle functions or control tasks. Each vehicle control unit provides specific services, and different services can control different parts of the vehicle. For example, the vehicle control unit can include the power system (VCU), braking system, battery management system (BMS), microcontroller unit (MCU), etc.
[0035] The service registration request refers to a registration request actively sent by the vehicle control unit to the service registration module 100 . The service registration information refers to the registration related information provided to the service registration module 100 by the vehicle control unit when sending a service registration request, such as the specific function of the service, interface description, input and output parameters, service protocol type and access method, etc.
[0036] The service registration function refers to the function or method that completes the service registration process, such as ServiceMgr::register().
[0037] The target service interface refers to the access interface assigned by the vehicle control unit to the service it possesses after the registration operation. It can provide data such as the service calling address or access path, the protocol type required to interact with the service, the communication method, and the service data format. The vehicle body can interact with the registered services through the target service interface.
[0038] It should be noted that before defining the target service interface, the service framework has pre-built the initial service interface. The initial service interface only defines the data format of the interface information, such as interface name, parameter format, return value type and other basic information, while the specific detailed information needs to be provided by the on-board control unit, that is, the service registration information sent by the on-board control unit.
[0039] After obtaining the service registration information, the service registration information can be added to the corresponding location according to the predefined data format to form the final target service interface to ensure the scalability of the interface.
[0040] The callable service list refers to a list of interfaces stored in a preset database. In the present application, the callable service list is arranged in order of service identifiers.
[0041] As an example, see Figure 2 , Figure 2 It is a schematic diagram of the connection relationship between the various interfaces shown in the embodiment of the present application. In the present application, the SOA-based service framework includes other basic interfaces in addition to the core ServiceMgr interface (service management interface) and Service interface (service interface): Protocol interface (protocol interface), Test interface (test interface), Communication interface (communication interface), Secure interface (security interface), Product interface (product interface), and Ota interface (online upgrade interface).
[0042] from Figure 2 It can be seen that the ServiceMgr interface can uniformly manage the Service interface, and the Service interface is connected with the interfaces of other functions. Therefore, the services on the vehicle body only need to access the ServiceMgr interface of the CCU to obtain all the atomic services of the chassis.
[0043] Combined with the following table, the content of each interface is explained one by one: Table 1- Protocol interface description
[0044] Table 2-Test interface description
[0045] Table 3-Communication interface description
[0046] Table 4-Secure interface description
[0047] Table 5-Product interface description
[0048] Table 6-Ota interface description
[0049] Table 7-Service interface description
[0050] Table 8-ServiceMgr interface description
[0051] It is worth noting that all of the above interfaces are remotely called through the Ethernet-based RPC (Remote Procedure Call) method, and except for the Secure interface, other interfaces require encrypted access.
[0052] In the vehicle chassis architecture, the interface is the key to achieve communication and collaboration between modules. The vehicle chassis consists of multiple independent functional modules (such as VCU, BMS, MCU, etc.) and a core control unit (CCU). The interface plays a standardized and normalized role in the service framework of the vehicle chassis, enabling the vehicle chassis and the upper body to work together.
[0053] Optionally, the service registration module 100 includes a security unit and a corresponding security interface.
[0054] The security unit is mainly used to call the key acquisition function of the security interface to extract the first communication key, and extract the second communication key from the service registration information, perform key verification on the first communication key and the second communication key, and when the key verification between the first communication key and the second communication key is successful, perform a registration operation on the vehicle control unit according to the service registration information and the service registration function of the service management interface.
[0055] The key acquisition function refers to a function that extracts a communication key from a security interface or other components, such as Secure::getSecureKey().
[0056] The first communication key refers to an encryption key extracted from a security unit or a security interface through a key acquisition function.
[0057] The second communication key refers to the key extracted from the service registration information, and is usually used to verify with the first communication key to ensure the security of the communication process, especially to verify the effectiveness of the encryption process.
[0058] In the present application, if the first communication key is consistent with the second communication key, the verification is considered successful. If the key comparison is unsuccessful, the verification is considered failed, and the service registration module 100 can reject the registration request and return an error message. The key comparison method includes but is not limited to hash comparison, encrypted signature verification, etc.
[0059] Optionally, the service registration module 100 also includes a test unit and a corresponding test interface.
[0060] The test unit is mainly used to call the test function of the test interface to perform functional verification on the test items of the vehicle control unit. When the functional verification of each test item of the vehicle control unit is passed, a service identifier is assigned to each atomic service of the vehicle control unit, and the service identifier and service registration information are used to define the interface of the atomic service of the vehicle control unit to obtain the target service interface for the vehicle control unit.
[0061] Among them, the test function refers to the function that verifies the functions and stability of each functional module of the vehicle control unit (VCU, BMS, MCU, etc.), such as test::testAll().
[0062] Test items refer to the functional modules, interfaces or subsystems tested inside the vehicle control unit. Each test item corresponds to a specific function or service in the vehicle system, and the purpose of verification is to ensure its correctness and performance.
[0063] A service identifier is a unique identifier used to distinguish and identify each atomic service of a vehicle control unit. It usually consists of a set of characters, numbers or a UUID (Universally Unique Identifier).
[0064] In this application, if all the test items of the vehicle control unit are verified, it means that the vehicle control unit is in a normal working state. If one or more test items of the vehicle control unit fail to be verified, it means that the vehicle control unit may be in an abnormal working state and requires further testing.
[0065] As another example of the present application, the SOA-based service framework also includes a chassis control module 200, which is mainly used to receive a service call request sent by the vehicle body, determine the target service interface corresponding to the service call request from the callable service list, access the vehicle control unit in real time through the target service interface, and send a service execution command to the vehicle control unit.
[0066] The service call request refers to a call instruction for the upper body system to request a specific service from the chassis control module 200, which includes the service identifier requested by the upper body. For example, if the upper body needs to adjust the suspension system of the vehicle, such as adjusting the hardness or height, to adapt to different road conditions, the upper body can send a service call request of "adjusting the hardness or height of the suspension system" to the chassis control module.
[0067] The service execution command refers to the actual control instruction generated by the chassis control module 200 according to the received service call request, which can instruct the vehicle control unit to perform a specific service operation. For example, the service execution command is to instruct the suspension system to adjust the hardness to a medium hardness value.
[0068] As an example, see Figure 3 , Figure 3 This is a schematic diagram of the interaction between the vehicle chassis service architecture and the upper body shown in the embodiment of the present application, which mainly implements service registration and calling through the ServiceMgr interface of the CCU. The specific description is as follows: 1) Upper body software part The vehicle body software of manufacturer A, the vehicle body software of manufacturer B, and the vehicle body software of manufacturer C respectively represent the vehicle body control systems of different manufacturers.
[0069] The vehicle body software obtains the list of all services registered in the smart chassis by calling getServiceList() of CCU to access each functional module.
[0070] 2) Intelligent chassis The intelligent chassis consists of CCU and various functional modules, among which CCU is responsible for the core service management and external interface. CCU contains ServiceMgr interface, which is used to manage various services in the chassis. It is responsible for receiving service registration requests from different modules and providing a list of callable services for the upper body.
[0071] The CCU also communicates with other modules via an encrypted RPC protocol, ensuring that all services are key authenticated and tested during registration.
[0072] When the VCU module is started, it registers the service with the CCU by calling the Register function of ServiceMgr. If the registration is successful, the VCU service is added to the service list and provided to the vehicle body for calling.
[0073] Similar to the VCU, the BMS module and the MCU module also implement the Service interface and register services with the CCU through the Register function at startup.
[0074] 3) Service call process The vehicle body software of different manufacturers obtains the registered service list by calling the getServiceList interface of CCU.
[0075] After obtaining the list, the vehicle body software can select the required services (such as VCU, BMS, MCU) and initiate a call.
[0076] It can be understood that CCU, as the core service management unit, realizes the service registration of each chassis module and provides a unified service interface to the outside world through the ServiceMgr interface, thereby achieving high compatibility between the chassis and the upper body.
[0077] Optionally, as described above, the chassis control module 200 is mainly used to return the callable service list to the upper body, and receive the service call request returned by the upper body based on the callable service list, and call the key acquisition function of the security interface to extract the temporary encryption key, so that the upper body uses the temporary encryption key to encrypt the service call request.
[0078] Among them, the temporary encryption key refers to the encryption key used during the calling period. When the call ends, the temporary encryption key becomes invalid to ensure the security of the service call.
[0079] The difference between the temporary encryption key and the aforementioned first communication key and second communication key is that the first communication key and the second communication key are mainly used for encryption in the registration phase, while the temporary encryption key is used for encryption in the calling phase, and the temporary encryption key is dynamic and has a short life cycle.
[0080] Optionally, the chassis control module 200 includes a communication unit and a corresponding protocol interface.
[0081] The communication unit is also used to call the protocol acquisition function of the protocol interface to obtain the communication protocol type, and return the communication protocol type to the upper body, so that when the upper body sends a service call request, it can determine the communication protocol that matches the chassis control module 200 through the communication protocol type.
[0082] The protocol acquisition function refers to a function that obtains or returns the type of the communication protocol currently in use, such as Protocol::getType().
[0083] The communication protocol type refers to the protocol standard of communication methods and rules, such as TCP / IP, CAN (Controller Area Network), wireless communication protocol, etc.
[0084] Optionally, the chassis control module 200 also includes a communication interface corresponding to the communication unit, and the communication unit is mainly used to determine the vehicle control unit corresponding to the service identifier, and call the write data function of the communication interface to forward the packaged service call request to the vehicle control unit.
[0085] The write data function refers to a function that writes data to a specified communication interface or transmission channel so that the data can be transmitted to a target device, such as Communication::write(byte[] data).
[0086] In addition, the service architecture also includes a service failure module.
[0087] The service fault module is mainly used to trigger a retry strategy when it detects that the service registration module 100 and / or the chassis control module 200 is in an abnormal working state; The retry strategy includes the number of retries and the time interval between each retry, such as the number of retries is 3, 5, 8, etc., and the time interval between retries is 1 second, 3 seconds, 5 seconds, etc.
[0088] As an example, the vehicle body sends a service call request to the chassis control module 200, but due to network delay or other failures, the first request fails. Then you can wait for 5 seconds and resend the request. If the request still fails, resend the request after another 5 seconds until the preset number of retries is reached.
[0089] It should be noted that the embodiments of the present application include but are not limited to the above examples. It is understandable that under the guidance of the ideas of the embodiments of the present application, technical personnel in this field can make settings according to actual conditions, and the present application does not limit this.
[0090] In order to enable those skilled in the art to better understand the technical solution of the embodiment of the present application, the following is an example to illustrate. Figure 4 , Figure 4 It is a schematic diagram of the registration and calling process of the VCU service shown in the embodiment of the present application.
[0091] 1) VCU service registration process Step 1: VCU registers service with CCU VCU sends a service registration request to CCU through ServiceMgr::register(), hoping to add its own service to the service management list of CCU for other modules to call.
[0092] Step 2: CCU obtains the key for communication encryption After receiving the registration request, the CCU calls Secure::getSecureKey() to obtain an encrypted communication key to ensure that subsequent communications are encrypted and secure.
[0093] Step 3: VCU provides communication key The VCU provides the communication key to the CCU so that the CCU can verify the legitimacy of the VCU.
[0094] Step 4: CCU performs system testing CCU calls Test::testAll() to start a series of tests to verify whether the status of VCU is normal to ensure that the registered services are reliable.
[0095] Step 5: Test passed, registration completed If all test items pass, the CCU confirms that the VCU's registration request is valid and completes the VCU's service registration.
[0096] 2) VCU service calling process Step 1: Go to the vehicle system to get the service list The upper body system (i.e., the upper body in the figure) requests the CCU for a list of all currently callable services through ServiceMgr::getServiceList() to determine the location of the service that needs to be called.
[0097] Step 2: CCU returns to the service list The CCU returns the service list to the upper body system, which parses the list and locates the VCU service through the service identifier.
[0098] Step 3: Obtain the communication key from the vehicle system Before preparing to communicate with the VCU, the upper body system requests the CCU to obtain the key required for encrypted communication through Secure::getSecureKey() to ensure the security of data transmission.
[0099] Step 4: Obtain protocol type information from the vehicle system The upper body system obtains the communication protocol type from the CCU through Protocol::getType() to ensure that a compatible communication protocol is used when communicating with the VCU.
[0100] Step 5: The vehicle body system writes data to the VCU After confirming the key and communication protocol required for encrypted communication, the upper body system can write the requested data to the VCU through Communication::write(byte[]data) to start actual data communication.
[0101] Step 6: Data is written successfully and service call is completed After the data is successfully written, the VCU completes the service call request and returns the service result to the vehicle body system, and the entire service call process ends.
[0102] In an embodiment of the present application, the service architecture of the vehicle chassis includes at least a service registration module 100 and a chassis control module 200, wherein the service registration module 100 includes a service management interface, and the chassis control module 200 is communicatively connected with the upper vehicle body; wherein the service registration module 100 is used to receive service registration requests and service registration information sent by each vehicle control unit, perform registration operations on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtain a target service interface corresponding to the vehicle control unit, and store the target service interface in a callable service list; the chassis control module 200 is used to receive a service call request sent by the upper vehicle body, determine a target service interface corresponding to the service call request from the callable service list, access the vehicle control unit in real time through the target service interface, and send a service execution command to the vehicle control unit.
[0103] Compared with the related technologies, the technical solution of the present application, on the one hand, improves cross-platform and cross-manufacturer compatibility by introducing a unified service management interface and a targeted target service interface, while being easy to expand; on the other hand, the service registration module 100 can ensure that different types of vehicle control units are registered and provide standardized service interfaces, providing a list of callable services for the chassis control module 200, and with the coordinated action of the chassis control module 200, the service call request can be accurately mapped to the target service interface, thereby reducing the complexity of communication between the vehicle body and each vehicle control unit, allowing the vehicle control unit to focus on efficiently providing atomic services.
[0104] Corresponding to the aforementioned application function implementation service architecture embodiment, the present application also provides a communication method, an electronic device and corresponding embodiments.
[0105] Figure 5 is a flow chart of a communication method shown in an embodiment of the present application. Figure 5 , a service architecture applied to a vehicle chassis, the service architecture being communicatively connected to an upper vehicle body, the method comprising at least the following steps: Step 501, receiving a service registration request and service registration information sent by each vehicle-mounted control unit; Step 502, performing a registration operation on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtaining a target service interface corresponding to the vehicle control unit, and storing the target service interface in a callable service list; Step 503, receiving a service call request sent by the vehicle body, and determining a target service interface corresponding to the service call request from a callable service list; Step 504: access the vehicle control unit in real time through the target service interface, and send a service execution command to the vehicle control unit.
[0106] As an example of the present application, a registration operation is performed on the vehicle control unit according to the service registration information and the service registration function of the service management interface, including: Call the key acquisition function of the security interface to extract the first communication key, and extract the second communication key from the service registration information; Performing key verification on the first communication key and the second communication key; When the key verification between the first communication key and the second communication key succeeds, a registration operation is performed on the vehicle control unit according to the service registration information and the service registration function of the service management interface.
[0107] As an example of the present application, a registration operation is performed on the vehicle control unit according to the service registration information and the service registration function of the service management interface, including: Call the test function of the test interface to perform functional verification on the test items of the vehicle control unit; When the functional verification of each test item of the vehicle control unit is passed, a service identifier is allocated to each atomic service of the vehicle control unit; The service identifier and service registration information are used to define the interface of the atomic service of the vehicle control unit to obtain the target service interface for the vehicle control unit.
[0108] As an example of the present application, before receiving a service call request sent by the vehicle body and determining a target service interface corresponding to the service call request from a callable service list, the process includes: Return the callable service list to the upper vehicle body, and receive the service call request returned by the upper vehicle body based on the callable service list; The key acquisition function of the security interface is called to extract the temporary encryption key, so that the upper vehicle body uses the temporary encryption key to encrypt the service call request.
[0109] As an example of the present application, before receiving a service call request sent by the vehicle body and determining a target service interface corresponding to the service call request from a callable service list, the process includes: The protocol acquisition function of the protocol interface is called to obtain the communication protocol type, and the communication protocol type is returned to the upper body, so that when the upper body sends a service call request, it determines the communication protocol that matches the chassis control module through the communication protocol type.
[0110] As an example of the present application, the service call request includes a service identifier requested by the vehicle body, and real-time access to the vehicle control unit through the target service interface includes: Determine the on-board control unit corresponding to the service identifier; The write data function of the communication interface is called to forward the encapsulated service call request to the vehicle control unit.
[0111] As an example of the present application, the method further includes: When it is detected that the service registration module and / or the chassis control module are in an abnormal working state, a retry strategy is triggered; The retry strategy includes the number of retries and the time interval between each retry.
[0112] Regarding the method in the above embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment of the service architecture, and will not be elaborated again here.
[0113] Figure 6 It is a schematic diagram of the structure of an electronic device shown in an embodiment of the present application.
[0114] See also Figure 6 , the electronic device 600 includes a memory 610 and a processor 620 .
[0115] The processor 620 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
[0116] The memory 610 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. Among them, ROM can store static data or instructions required by the processor 620 or other modules of the computer. The permanent storage device may be a readable and writable storage device. The permanent storage device may be a non-volatile storage device that does not lose the stored instructions and data even after the computer is powered off. In some embodiments, the permanent storage device uses a large-capacity storage device (such as a magnetic or optical disk, flash memory) as a permanent storage device. In some other embodiments, the permanent storage device may be a removable storage device (such as a floppy disk, optical drive). The system memory may be a readable and writable storage device or a volatile readable and writable storage device, such as a dynamic random access memory. The system memory may store some or all instructions and data required by the processor at runtime. In addition, the memory 610 may include any combination of computer-readable storage media, including various types of semiconductor storage chips (such as DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, the memory 610 may include a readable and / or writable removable storage device, such as a laser disc (CD), a read-only digital versatile disc (such as a DVD-ROM, a double-layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (such as an SD card, a mini SD card, a Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not include carrier waves and transient electronic signals transmitted wirelessly or wired.
[0117] The memory 610 stores executable codes, and when the executable codes are processed by the processor 620 , the processor 620 can execute part or all of the above-mentioned methods.
[0118] In addition, the method according to the present application may also be implemented as a computer program or a computer program product, which includes computer program code instructions for executing some or all of the steps in the above method of the present application.
[0119] Alternatively, the present application can also be implemented as a computer-readable storage medium (or non-transitory machine-readable storage medium or machine-readable storage medium) on which executable code (or computer program or computer instruction code) is stored. When the executable code (or computer program or computer instruction code) is executed by a processor of an electronic device (or server, etc.), the processor executes part or all of the steps of the above-mentioned method according to the present application.
[0120] The embodiments of the present application have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.
Claims
1. A vehicle chassis service architecture, characterized in that: The service architecture at least includes a service registration module and a chassis control module, the service registration module includes a service management interface, and the chassis control module is connected to the upper vehicle body in communication; wherein, The service registration module is used to receive service registration requests and service registration information sent by each vehicle control unit, perform a registration operation on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtain a target service interface corresponding to the vehicle control unit, and store the target service interface in a callable service list; The chassis control module is used to receive a service call request sent by the upper body, determine a target service interface corresponding to the service call request from the callable service list, access the vehicle control unit in real time through the target service interface, and send a service execution command to the vehicle control unit.
2. The service architecture according to claim 1, characterized in that: The service registration module includes a security unit and a corresponding security interface; The security unit is used to call the key acquisition function of the security interface to extract the first communication key, and extract the second communication key from the service registration information; Performing key verification on the first communication key and the second communication key; When the key verification between the first communication key and the second communication key succeeds, a registration operation is performed on the vehicle control unit according to the service registration information and the service registration function of the service management interface.
3. The service architecture according to claim 2, characterized in that: The service registration module includes a test unit and a corresponding test interface; The test unit is used to call the test function of the test interface to perform functional verification on the test items of the vehicle control unit; When the functional verification of each test item of the vehicle control unit is passed, a service identifier is allocated to each atomic service of the vehicle control unit; The service identifier and the service registration information are used to define the interface of the atomic service of the vehicle control unit to obtain a target service interface for the vehicle control unit.
4. The service architecture according to claim 1, characterized in that: The chassis control module is used to return the callable service list to the upper vehicle body, and receive a service call request returned by the upper vehicle body based on the callable service list; The key acquisition function of the security interface is called to extract the temporary encryption key, so that the upper vehicle body uses the temporary encryption key to encrypt the service call request.
5. The service architecture according to claim 1, characterized in that: The chassis control module includes a communication unit and a corresponding protocol interface; The communication unit is used to call the protocol acquisition function of the protocol interface to obtain the communication protocol type, and return the communication protocol type to the upper body, so that when the upper body sends a service call request, it determines the communication protocol matching the chassis control module through the communication protocol type.
6. The service architecture according to claim 5, characterized in that: The chassis control module also includes a communication interface corresponding to the communication unit, and the service call request includes a service identifier of the upper vehicle body request; The communication unit is used to determine the vehicle-mounted control unit corresponding to the service identifier; The write data function of the communication interface is called to forward the packaged service call request to the vehicle-mounted control unit.
7. The service architecture according to claim 1, characterized in that: The service architecture also includes a service failure module; The service fault module is used to trigger a retry strategy when detecting that the service registration module and / or the chassis control module is in an abnormal working state; The retry strategy includes the number of retries and the time interval between each retry.
8. A communication method, characterized in that: A service architecture applied to a vehicle chassis, the service architecture being communicatively connected to an upper vehicle body, the method comprising: Receive service registration requests and service registration information sent by each vehicle control unit; Performing a registration operation on the vehicle control unit according to the service registration information and the service registration function of the service management interface, obtaining a target service interface corresponding to the vehicle control unit, and storing the target service interface in a callable service list; Receiving a service call request sent by the upper vehicle body, and determining a target service interface corresponding to the service call request from the callable service list; The vehicle-mounted control unit is accessed in real time through the target service interface, and a service execution command is sent to the vehicle-mounted control unit.
9. An electronic device, characterized in that: include: processor; as well as A memory having executable codes stored therein, which, when executed by the processor, causes the processor to execute the method according to claim 8. 10 . A computer-readable storage medium having executable codes stored thereon, which, when executed by a processor of an electronic device, causes the processor to execute the method according to claim 8 .