Enhanced architecture system and method for vehicle end services
By introducing native service modules, expanded service modules and interface call modules into the vehicle-side service framework, the problems of insufficient security, interface uniformity and cross-platform support of the vehicle-side service framework in the existing technology have been solved, and a higher level has been achieved security and development simplicity, and support multiple platform services.
Patent Information
- Application Number
- CN202411372170.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-29
- Publication Date
- 2025-01-03
AI Technical Summary
The existing vehicle-side service framework has shortcomings in terms of security, interface uniformity and cross-platform support, resulting in increased complexity of APP development and risk of user privacy exposure.
An enhanced architecture system was designed, including native service module for hardware signal packaging, expansion service module for access to multiple platform services, and unified interface verification with interface call module to ensure parameter format and permission verification.
It improves the security and development simplicity of vehicle-side services, supports multiple platform services, reduces direct exposure to underlying services, and enhances the stability and diversity of services.
Smart Images
Figure CN119254795A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of in-vehicle communications, and more specifically, to an enhanced architecture system and method for vehicle-side services. Background Art
[0002] First, under the existing vehicle-side service framework, the vehicle-side services provided are basically just a simple forwarding and conversion of request parameters to the underlying vehicle-side CAN (Controller Area Network) signal, which makes the vehicle-side services almost directly exposed to APP developers, posing a security risk to paid services and user privacy. Secondly, the existing vehicle-side service framework does not have a unified interface parameter transmission data format, resulting in the upper-level vehicle-side APP developers needing to confirm the number and type of parameters and other information every time when calling the service, increasing the complexity of development. Finally, the existing vehicle-side service framework mainly supports services in the form of native Android vehicle attributes, but has limited support for services on other platforms. Summary of the invention
[0003] In view of the above problems, the following technical solutions are provided.
[0004] The enhanced architecture system for vehicle-side services of the present application includes: a native service module, which is configured to receive vehicle-side hardware signals and uniformly encapsulate the vehicle-side hardware signals; an extended service module, which is configured to include multiple extended service units to access various types of platform services; and an interface calling module, which is configured to use a unified interface to verify the calling request.
[0005] Optionally, the native service module includes a signal monitoring unit, and the signal monitoring unit is configured to periodically call the vehicle-side signal to monitor the status of the vehicle-side signal.
[0006] Optionally, the multiple extended service units include: a SOME / IP extended service unit, a cloud extended service unit and an IOT extended service unit.
[0007] Optionally, the cloud-side extension service unit is configured to call the cloud service via an API interface to synchronize the vehicle-side service configuration.
[0008] Optionally, the verifying the calling request by using a unified interface further includes performing interface authority verification and parameter format verification on the calling request by using the unified interface.
[0009] Optionally, the parameter format verification includes: parameter name verification, parameter type verification and serialization form verification.
[0010] The enhanced architecture method for vehicle-side services of the present application includes: a native service module receives vehicle-side hardware signals and uniformly encapsulates the vehicle-side hardware signals; a plurality of extended service units are configured in the extended service module, and the plurality of extended service units are used to access various types of platform services; and an interface call module uses a unified interface to verify the call request.
[0011] The computer-readable storage medium of the present application stores a computer program thereon, and when the computer program is executed by a processor, the above-mentioned enhanced architecture method is implemented.
[0012] The computer device of the present application includes a storage module, a processor, and a computer program stored in the storage module and executable on the processor, wherein the processor implements the above-mentioned enhanced architecture method when executing the computer program.
[0013] The computer program product of the present application includes a computer program, and when the computer program is executed by a processor, the above-mentioned enhanced architecture method is implemented.
[0014] The vehicle of the present application comprises the above-mentioned enhanced architecture system. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The above and / or other aspects and advantages of the present application will become clearer and easier to understand through the following description of various aspects in conjunction with the accompanying drawings, in which the same or similar units are represented by the same reference numerals. In the accompanying drawings:
[0016] Figure 1 A schematic block diagram of an enhanced architecture system 100 for vehicle-side services according to an embodiment of the present application is shown;
[0017] Figure 2 A schematic flow chart of an enhanced architecture method for vehicle-side services according to an embodiment of the present application is shown. DETAILED DESCRIPTION
[0018] The description of the following specific embodiments is merely exemplary in nature and is not intended to limit the disclosed technology or the application and use of the disclosed technology. In addition, it is not intended to be bound by any express or implied theory presented in the aforementioned technical field, background technology or the following specific embodiments.
[0019] In the following detailed description of the embodiments, many specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it is apparent to one of ordinary skill in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features are not described in detail to avoid unnecessarily complicating the description.
[0020] Terms such as “comprise” and “include” indicate that in addition to the units and steps directly and explicitly stated in the specification, the technical solution of the present application does not exclude the situation where there are other units and steps that are not directly or explicitly stated.
[0021] Hereinafter, various exemplary embodiments according to the present application will be described in detail with reference to the accompanying drawings.
[0022] Reference now Figure 1 , Figure 1 A schematic block diagram of an enhanced architecture system 100 for vehicle-side services according to an embodiment of the present application is shown.
[0023] like Figure 1 As shown, the enhanced architecture system 100 includes a native service module 110 , an extended service module 120 and an interface calling module 130 .
[0024] The native service module 110 is configured to receive vehicle-side hardware signals and uniformly encapsulate the vehicle-side hardware signals. Specifically, the native service module 110 captures the status and data of the vehicle hardware and also performs a uniform encapsulation process on these signals, which involves converting different hardware signals into a standardized format so that these hardware signals can be more widely accepted and used in the vehicle system.
[0025] In addition, the native service module 110 replaces the previous dispersed and fragmented service structure by integrating the native services of the vehicle computer, providing a more centralized and efficient service management model.
[0026] The encapsulation and logic enhancement of native services are the core parts of the native service module 110. The encapsulation process ensures the consistency of the interface and data transmission of the native service module 110, while the logic enhancement ensures the accuracy and reliability of the native service module 110 when processing vehicle-side hardware signals. These measures jointly safeguard the integrity of the native service module 110, so that the native service module 110 can still maintain stable and efficient performance when facing different vehicle-side hardware signals.
[0027] Optionally, the native service module 110 includes a signal monitoring unit, which is configured to periodically call the vehicle-side signal to monitor the status of the vehicle-side signal. The signal monitoring unit periodically checks and calls all signals on the vehicle computer by setting a timing period, including various key parameters of the vehicle, such as speed, engine status, fuel level, battery power, etc. This timed periodic call not only ensures the survival of the signal itself, but also through regular inspections, it also ensures that the system can capture any changes in the signal status in a timely manner. This real-time monitoring is crucial to the safety and reliability of the vehicle, especially in situations where a quick response is required, such as an autonomous driving assistance system or a vehicle's emergency braking system.
[0028] The extended service module 120 is configured to include multiple extended service units to access various types of platform services.
[0029] Optionally, the multiple extended service units include: SOME / IP extended service unit, cloud extended service unit and IOT (Internet of Things) extended service unit. The extended service module 120 implements the function of cross-platform service call by integrating SDK (Software Development Kit) and API (Application Programming Interface) of multiple platforms. The extended service module 120 includes multiple extended service units:
[0030] In terms of the SOME / IP extended service unit, the extended service module uses a specific SDK to access services based on the SOME / IP protocol. SOME / IP, or Scalable service-oriented MiddlewarE over IP, is an efficient automotive communication protocol that supports a service-oriented communication mode, allowing vehicles to flexibly interact with various services.
[0031] In terms of the cloud extension service unit, the connection with the cloud server is achieved by utilizing the API provided by the cloud service. This allows the vehicle to access the rich services provided on the cloud, such as real-time weather updates, the latest news information, online entertainment content, etc., greatly enhancing the vehicle's information service capabilities. In some embodiments, the cloud extension service unit also calls the cloud service through the API interface to synchronize the vehicle-side service configuration.
[0032] In terms of IOT expansion service units, the connection between vehicles and various IOT devices is realized by integrating the SDK of IoT devices. This not only allows the vehicle to monitor and control smart home devices, but also brings more intelligent convenience to the vehicle, such as remote monitoring of vehicle status and automatic adjustment of the in-vehicle environment.
[0033] In general, the extended service module 120 not only improves the service capabilities and user experience of the vehicle information system through cross-platform SDK and API integration, but also provides more possibilities for the connection between the vehicle and the outside world, and promotes the development of vehicles towards intelligence and networking.
[0034] The interface calling module 130 is configured to verify the calling request using a unified interface.
[0035] Optionally, the interface calling module 130 uses a unified interface to verify the calling request, including interface authority verification and parameter format verification. Optionally, the parameter format verification includes: parameter name verification, parameter type verification and serialization form verification.
[0036] The following is an example process of an upper-level APP initiating a call request to the unified interface: the upper-level APP first initiates a call request to the unified interface, which includes the configuration information of the APP. After receiving the call request, the unified interface performs interface permission verification, that is, verifies whether the configuration information in the call request contains the calling permission for the unified interface. If not, the unified interface sends a notification of insufficient permission and call failure to the APP. If it does, it then performs parameter format verification. The unified interface further verifies whether the format of the incoming parameters included in the call request, including parameter name, parameter type, and serialization format (such as JSON, XML, or Protocol Buffers, etc.), complies with the regulations. If not, the unified interface sends a notification of invalid parameters and call failure to the APP. If it complies, the call request is successful, and the unified interface returns the status to the APP.
[0037] To sum up, the external interface is a further packaging of the vehicle-side service. Through a unified interface, that is, by specifying the input parameters and serialization form of the APP, the APP level can make direct calls, which weakens the exposure of the underlying services and simplifies the parsing of upper-level requests by the vehicle-machine service. At the same time, it blocks direct calls to the vehicle-machine service, so that only through the unified interface can the security of the service itself be enhanced.
[0038] Reference now Figure 2 , Figure 2 A schematic flow chart of an enhanced architecture method for vehicle-side services according to an embodiment of the present application is shown.
[0039] like Figure 2 As shown, the enhanced architecture method includes the following steps:
[0040] Step S210: The native service module receives the vehicle-side hardware signal and uniformly encapsulates the vehicle-side hardware signal;
[0041] Step S220: multiple extended service units are configured in the extended service module, and the multiple extended service units are used to access various types of platform services;
[0042] Step S230: The interface calling module uses a unified interface to verify the calling request.
[0043] The enhanced architecture system and method for vehicle-side services provided in the present application are expanded upon the existing native service framework and integrated into the framework's own architecture. A unified calling interface is additionally encapsulated to intercept the implementation details of the underlying services from the outside, thereby achieving the security and concealment of the underlying services while ensuring the ease of calling the upper-level APP. In addition, expansion functions are added to be compatible with multiple protocols, allowing access to services from more platforms, greatly increasing the diversity of vehicle-side services.
[0044] The present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the enhanced architecture method of the present application is implemented. The computer-readable medium referred to in the present application includes various types of computer storage media, which can be any available medium that a general or special computer can access. For example, the computer-readable medium may include RAM, ROM, EPROM, E2PROM, registers, hard disks, removable disks, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other temporary or non-temporary medium that can be used to carry or store a desired program code unit in the form of an instruction or data structure and can be accessed by a general or special computer, or a general or special processor. As used herein, the disk usually copies data magnetically, while the dish uses a laser to optically copy data. The above combination should also be included in the scope of protection of the computer-readable medium. The exemplary storage medium is coupled to the processor so that the processor can read and write information from / to the storage medium. In an alternative solution, the storage medium can be integrated into the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal (eg, an onboard vehicle system, an external diagnostic device).
[0045] The present application also provides a computer device, including a storage module, a processor, and a computer program stored on the storage module and executable on the processor, wherein the processor implements the enhanced architecture method of the present application when executing the computer program.
[0046] The present application also provides a computer program product, including a computer program, which implements the enhanced architecture method of the present application when executed by a processor.
[0047] The present application also provides a vehicle, the vehicle comprising the enhanced architecture system of the present application. The vehicle referred to in the present application may represent any appropriate vehicle having a drive system consisting of at least a battery, a power conversion device, and a drive motor, such as a hybrid vehicle, an electric vehicle, a plug-in hybrid electric vehicle, etc. A hybrid vehicle is a vehicle having two or more power sources, such as a gasoline-powered and an electric vehicle.
[0048] The specific embodiments described above in this application are only for more clearly describing the principles of this application, wherein each component is clearly shown or described to make the principles of this application easier to understand. Without departing from the scope of this application, those skilled in the art can easily make various modifications or changes to this application. Therefore, it should be understood that these modifications or changes should be included in the scope of patent protection of this application.
Claims
1. An enhanced architecture system for vehicle-side services, characterized in that: The system comprises: A native service module, wherein the native service module is configured to receive a vehicle-side hardware signal and uniformly encapsulate the vehicle-side hardware signal; An extended service module, the extended service module being configured to include a plurality of extended service units to access various types of platform services; and An interface calling module is configured to verify the calling request using a unified interface.
2. The enhanced architecture system according to claim 1, characterized in that: The native service module includes a signal monitoring unit, which is configured to periodically call a vehicle-side signal to monitor a state of the vehicle-side signal.
3. The enhanced architecture system according to claim 1, characterized in that: Multiple expansion service units include: SOME / IP expansion service unit, cloud expansion service unit and IOT expansion service unit.
4. The enhanced architecture system according to claim 3, characterized in that: The cloud-side extension service unit is configured to call the cloud service via an API interface to synchronize the vehicle-side service configuration.
5. The enhanced architecture system according to claim 1, characterized in that: The using a unified interface to verify the call request further includes using the unified interface to perform interface authority verification and parameter format verification on the call request.
6. The enhanced architecture system according to claim 5, characterized in that: The parameter format verification includes: parameter name verification, parameter type verification and serialization form verification.
7. An enhanced architecture method for vehicle-side services, characterized in that: The method comprises: The native service module receives the vehicle-side hardware signal and uniformly encapsulates the vehicle-side hardware signal; A plurality of extended service units are configured in the extended service module, and the plurality of extended service units are used to access various types of platform services; and The interface calling module uses a unified interface to verify the calling request.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the enhanced architecture method of claim 7 is implemented.
9. A computer device comprising a storage module, a processor, and a computer program stored in the storage module and executable on the processor, characterized in that: When the processor executes the computer program, the enhanced architecture method of claim 7 is implemented.
10. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the enhanced architecture method according to claim 7 is implemented.
11. A vehicle, characterized in that: The vehicle comprises the enhanced architecture system according to any one of claims 1-6.