Atomization interface design method of vehicle adaptation layer, electronic equipment and storage medium
By using an atomic interface design for the vehicle-machine adaptation layer and employing a key-value mapping table and a chain-of-responsibility pattern to process interfaces, the problems of interface duplication and high maintenance costs in the vehicle-machine service adaptation layer are solved, achieving efficient and concise interface calls and low-cost development and maintenance.
Patent Information
- Application Number
- CN202511876880.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-12
- Publication Date
- 2026-05-01
AI Technical Summary
The existing vehicle infotainment service adaptation layer suffers from interface duplication and high maintenance costs due to the expansion of business volume and overlapping business scenarios, causing confusion and bewilderment for upper-layer application callers.
The atomic interface design method of the vehicle-machine adaptation layer is adopted. By establishing a globally unique key-value mapping table, the business identifier key is mapped one-to-one with SOA/CAN signals to form a global HashMap mapping table, which replaces the business module unit manager Manager to achieve unified management of interfaces. The chain of responsibility pattern is used to design interceptors to handle interface calls.
It reduces memory consumption, improves memory utilization, simplifies interface calls, reduces code redundancy and maintenance costs, and enhances development efficiency and scalability.
Smart Images
Figure CN121957541A_ABST
Abstract
Description
Atomized interface design method for vehicle infotainment system adapter layer, electronic devices and storage media Technical Field
[0001] This application relates to the field of cockpit development, and in particular to an atomic interface design method for vehicle-machine interface layer, vehicle-machine interface layer system, electronic devices, storage media and vehicle cockpit. Background Technology
[0002] In the past, the vehicle infotainment service adaptation layer was basically implemented according to the business manager (Manager refers to the business module unit manager) principle to implement the specific requirements of the corresponding business. For example, CarATCManager (air conditioning manager) is responsible for handling air conditioning control business, CarSeatManager (seat manager) is responsible for handling seat control business, CarSceneModeManage (scene mode manager) is responsible for handling scene mode related business, and so on. However, with the rapid expansion of business volume, coupled with the overlap and intersection of some business scenarios, the same business interface or sub-business interface dependency often appears in the management domains of these different business managers. For example, CarSeatManager needs to control seat movement, and CarSceneModeManager scene mode also needs to control seat movement (the parameters may be different). This causes confusion and even bewilderment for the upper-layer application APP caller. In the long run, the code maintenance cost will become higher and higher.
[0003] Therefore, a strategy for designing an atomic interface for the vehicle-mounted system adaptation layer is needed to address the confusion and bewilderment experienced by upper-layer application (APP) users. Summary of the Invention
[0004] The purpose of this invention is to provide a method for optimizing the display of a smart cockpit interface, a device for optimizing the display of a smart cockpit interface, an electronic device, a storage medium, and a vehicle cockpit, thereby solving at least one of a number of technical problems.
[0005] For example, it is a technical problem to solve the problem of how to reduce memory consumption and how to improve memory utilization.
[0006] This invention provides the following solution:
[0007] According to a first aspect of the present invention, an atomic interface design method for a vehicle-mounted system adapter layer is provided, comprising:
[0008] Establish a globally unique business identifier Key corresponding to the vehicle's functional attribute ID, and map it one-to-one with the vehicle's SOA signal or CAN signal to form a global HashMap mapping table based on key-value pairs;
[0009] Among them, the business identifier Key corresponds to a unique atomic functional unit, which is used to represent a basic capability unit of the vehicle system;
[0010] The CarPropertyIDManager maintains a global HashMap mapping table to replace the Business Module Unit Manager Manager, and is used for unified management of atomic interfaces.
[0011] The application layer directly indexes the target atomic interface in the HashMap global mapping table by passing in the business flag key and the corresponding value data parameter, and completes the interface call;
[0012] The data transformation process executed during the call includes:
[0013] During downlink, the standard protocol data transmitted from the application APP is converted into SOA or CAN signal data and transmitted to the AutoSAR vehicle service.
[0014] During uplink, SOA or CAN signal data is converted into standard protocol data and returned to the application (APP).
[0015] Furthermore, including:
[0016] Atomized interfaces include:
[0017] The Set interface is used to process downlink data commands;
[0018] A Get interface for synchronously obtaining upstream data;
[0019] A Callback interface used for asynchronously acquiring upstream data and monitoring status.
[0020] Furthermore, including:
[0021] The Set, Get, and Callback interfaces correspond to the Write, Read, and Notify interceptors, respectively, and are designed using the chain of responsibility pattern.
[0022] In this context, the corresponding chain of responsibility includes multiple OP operation nodes that are executed sequentially.
[0023] The OP operation nodes include at least one of the following: log printing OP, null pointer check OP, business processing OP, and anti-explosion point OP.
[0024] Furthermore, including:
[0025] HashMap's global mapping table supports dynamic expansion;
[0026] Among them, the corresponding HashMap global mapping table extension is implemented by adding a new business flag key and the corresponding SOA / CAN signal mapping relationship to realize the interface extension of the new basic capabilities of the vehicle system.
[0027] Furthermore, it also includes: a proxy layer;
[0028] After receiving the service acquisition request from the application APP, the proxy layer selectively returns the HQCarControlManager entity Binder or the CarAdapterManager entity Binder according to the service type specified by the application APP.
[0029] In this process, the application (APP) obtains the service by passing in the name of the service to be used as a parameter;
[0030] Based on the vehicle model correspondence, select the service type that the application app should enable based on the corresponding service name.
[0031] Furthermore, including:
[0032] The business identifier key is used as a globally unique vehicle infotainment function attribute ID;
[0033] Each business identifier Key corresponds to an atomic functional unit including at least one of the following: opening and closing windows, controlling the air conditioning, adjusting the seat, obtaining the remaining driving range, and monitoring vehicle speed status.
[0034] According to a second aspect of the present invention, a vehicle-machine adaptation layer system is provided, and an atomic interface design method for the vehicle-machine adaptation layer is provided. The vehicle-machine adaptation layer system includes:
[0035] The vehicle-mounted vehicle attribute ID management module is used to maintain a global HashMap mapping table to manage the mapping between Keys and SOA / CAN signals.
[0036] The interface call module is used to receive the Key and Value parameters passed in from the application layer and index the target atomic interface through the global HashMap mapping table;
[0037] The data conversion module is used to perform uplink and downlink data conversion processes, realizing bidirectional conversion between standard protocol data and SOA / CAN signal data;
[0038] The chain of responsibility processing module is used to sequentially process and extend the three types of interfaces, namely Set, Get, and Callback, through interceptors and OP operation nodes.
[0039] Furthermore, it also includes:
[0040] The proxy adaptation module is used to switch between the new service interface call mode and the old service interface call mode according to the application's service selection instructions.
[0041] The new service interface invocation mode includes direct access to atomic interfaces via a key;
[0042] The old service interface call pattern included calling the interface layer by layer through the business unit manager.
[0043] Furthermore, the data conversion module also includes:
[0044] It supports dynamic adaptation to SOA signal differences of different vehicle models, and realizes unified calling logic of atomic interfaces of different vehicle models through the key configuration of the global HashMap mapping table.
[0045] Furthermore, the vehicle-mounted system attribute ID management module also includes:
[0046] Supports adding, deleting, and modifying mapping relationships for keys;
[0047] The API call module also includes support for the application layer to initiate API call requests via the AIDL protocol.
[0048] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;
[0049] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps such as the atomic interface design method of the vehicle-machine adaptation layer.
[0050] According to a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform steps such as an atomic interface design method for a vehicle-mounted system adaptation layer.
[0051] According to a fifth aspect of the present invention, a vehicle cabin is provided, comprising:
[0052] Electronic devices, steps for implementing atomic interface design methods such as vehicle-mounted system adaptation layers;
[0053] The processor runs programs, and when the program runs, it executes steps such as the atomic interface design method of the vehicle adaptation layer based on the data output from the electronic device.
[0054] Storage medium used to store programs that, when running, execute steps of an atomic interface design method, such as that of a vehicle-mounted system adaptation layer, on data output from an electronic device.
[0055] The above solution achieves the following beneficial technical effects:
[0056] This application no longer uses the original business unit manager to divide and use API interfaces; there are no longer calling methods like CarManager.getInstance().setACState(position.Front, ON); instead, it uses the method CarManager.getInstance().set(CarPropertyKeys.HQP_AC_OnOff,CarControlValueData); including dividing all API interface calls of the whole vehicle into three types of interfaces: set (setting), get (getting), and callback (data callback reporting), and the upper-level callers (various APP applications).
[0057] In this application, you only need to remember three types of interfaces: set, get, and callback. Each type of interface can be used to distinguish different atomic business units (corresponding to a unique SOA signal) based on the different attribute IDs (Keys) passed in.
[0058] The resulting technical benefits include that users only need to know the Key value corresponding to a certain atomic business module signal to complete the call to the three types of interfaces corresponding to that signal; there is no need to first look up the business unit manager to which the signal belongs, and then look up which interface to call in the business unit manager; at the same time, it also avoids the problem of duplicate (redundant) implementation of the same signal in different business unit managers (for example, the voice manager needs to turn on the air conditioner, and the air conditioner manager also needs to turn on the air conditioner, so there will be redundant implementations of the signal to turn on the air conditioner in these two managers at the same time).
[0059] Another advantage of this application is that calling a unified API through key-value mapping is simpler, more efficient, and easier to manage and maintain. Combined with automatic code generation, the amount of code for the same business logic is greatly reduced, significantly improving development efficiency. For example, the workload of a team of 5 people can be reduced to that of 3 people in the same amount of time. Furthermore, it offers better scalability. For instance, if a requirement for an API interface changes and anti-clicking logic is added, the old approach required adding the logic in a decentralized, one-to-one manner. However, the new solution proposed in this application allows for a unified anti-clicking interceptor to handle this through a chain-of-responsibility design pattern, resulting in obvious improvements in efficiency, readability, and maintainability. Attached Figure Description
[0060] Figure 1 is a flowchart of an atomic interface design method for a vehicle-machine adaptation layer provided by one or more embodiments of the present invention.
[0061] Figure 2 is a structural diagram of a vehicle-machine adaptation layer system provided by one or more embodiments of the present invention.
[0062] Figure 3 is a schematic diagram of an atomic interface design based on Key-Value HashMap mapping provided in a specific embodiment of the present invention.
[0063] Figure 4 is a schematic diagram of an atomic interface design based on Key-Value HashMap mapping provided in a specific embodiment of the present invention.
[0064] Figure 5 is a schematic diagram of a specific implementation of SOA or CAN signals provided in a specific embodiment of the present invention.
[0065] Figure 6 is a schematic diagram of a unique SOA signal corresponding to each Key (ID) provided in a specific embodiment of the present invention.
[0066] Figure 7 is a schematic diagram of a data conversion process provided in a specific embodiment of the present invention.
[0067] Figure 8 is a schematic diagram of a specific embodiment of the present invention that is compatible with existing solutions.
[0068] Figure 9 is a block diagram of an electronic device structure based on the atomic interface design method of the vehicle-machine adaptation layer provided by one or more embodiments of the present invention. Detailed Implementation
[0069] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0070] Figure 1 is a flowchart of an atomic interface design method for a vehicle-machine adaptation layer provided by one or more embodiments of the present invention.
[0071] The atomic interface design method for the vehicle-to-everything (V2X) adapter layer, as shown in Figure 1, includes:
[0072] Step S1: Establish a globally unique business identifier Key corresponding to the vehicle's functional attribute ID, and map it one-to-one with the vehicle's SOA signal or CAN signal to form a global HashMap mapping table based on key-value pairs;
[0073] Each business identifier (Key) corresponds to a unique atomic functional unit, used to represent a basic capability unit of the vehicle's infotainment system.
[0074] Step S2: The CarPropertyIDManager maintains a global HashMap mapping table to replace the business module unit manager Manager and is used for unified management of atomic interfaces.
[0075] Step S3: The application layer directly indexes the target atomic interface in the HashMap global mapping table by passing in the business flag Key and the corresponding Value data parameter, and completes the interface call;
[0076] Step S4, the data transformation process is executed during the call, including:
[0077] During downlink, the standard protocol data transmitted from the application APP is converted into SOA or CAN signal data and transmitted to the AutoSAR vehicle service.
[0078] During uplink, SOA or CAN signal data is converted into standard protocol data and returned to the application (APP).
[0079] In this embodiment, it includes:
[0080] Atomized interfaces include:
[0081] The Set interface is used to process downlink data commands;
[0082] A Get interface for synchronously obtaining upstream data;
[0083] A Callback interface used for asynchronously acquiring upstream data and monitoring status.
[0084] In this embodiment, it includes:
[0085] The Set, Get, and Callback interfaces correspond to the Write, Read, and Notify interceptors, respectively, and are designed using the chain of responsibility pattern.
[0086] In this context, the corresponding chain of responsibility includes multiple OP operation nodes that are executed sequentially.
[0087] The OP operation nodes include at least one of the following: log printing OP, null pointer check OP, business processing OP, and anti-explosion point OP.
[0088] In this embodiment, it includes:
[0089] HashMap's global mapping table supports dynamic expansion;
[0090] Among them, the corresponding HashMap global mapping table extension is implemented by adding a new business flag key and the corresponding SOA / CAN signal mapping relationship to realize the interface extension of the new basic capabilities of the vehicle system.
[0091] In this embodiment, a proxy layer is also included;
[0092] After receiving the service acquisition request from the application APP, the proxy layer selectively returns the HQCarControlManager entity Binder or the CarAdapterManager entity Binder according to the service type specified by the application APP.
[0093] In this process, the application (APP) obtains the service by passing in the name of the service to be used as a parameter;
[0094] Based on the vehicle model correspondence, select the service type that the application app should enable based on the corresponding service name.
[0095] In this embodiment, it includes:
[0096] The business identifier key is used as a globally unique vehicle infotainment function attribute ID;
[0097] Each business identifier Key corresponds to an atomic functional unit including at least one of the following: opening and closing windows, controlling the air conditioning, adjusting the seat, obtaining the remaining driving range, and monitoring vehicle speed status.
[0098] Figure 2 is a structural diagram of a vehicle-machine adaptation layer system provided by one or more embodiments of the present invention.
[0099] As shown in Figure 2, the vehicle-to-machine (V2M) adaptation layer system uses an atomic interface design method for the V2M adaptation layer. The V2M adaptation layer system includes:
[0100] The vehicle-mounted vehicle attribute ID management module is used to maintain a global HashMap mapping table to manage the mapping between Keys and SOA / CAN signals.
[0101] The interface call module is used to receive the Key and Value parameters passed in from the application layer and index the target atomic interface through the global HashMap mapping table;
[0102] The data conversion module is used to perform uplink and downlink data conversion processes, realizing bidirectional conversion between standard protocol data and SOA / CAN signal data;
[0103] The chain of responsibility processing module is used to sequentially process and extend the three types of interfaces, namely Set, Get, and Callback, through interceptors and OP operation nodes.
[0104] In this embodiment, it also includes:
[0105] The proxy adaptation module is used to switch between the new service interface call mode and the old service interface call mode according to the application's service selection instructions.
[0106] The new service interface invocation mode includes direct access to atomic interfaces via a key;
[0107] The old service interface call pattern included calling the interface layer by layer through the business unit manager.
[0108] In this embodiment, the data conversion module further includes:
[0109] It supports dynamic adaptation to SOA signal differences of different vehicle models, and realizes unified calling logic of atomic interfaces of different vehicle models through the key configuration of the global HashMap mapping table.
[0110] In this embodiment, the vehicle-mounted attribute ID management module further includes:
[0111] Supports adding, deleting, and modifying mapping relationships for keys;
[0112] The API call module also includes support for the application layer to initiate API call requests via the AIDL protocol.
[0113] It is worth noting that although this system / device only discloses optimization modules for UI visuals, UE interaction, and UX experience, it does not mean that this device is limited to the above-mentioned basic functional modules. Rather, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technologies to form an infinite number of embodiments or technical solutions. In other words, this system / device is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be interpreted as the scope of protection of the claims of this invention being limited to the above-disclosed basic functional modules.
[0114] In one specific embodiment, the vehicle-to-everything (V2X) adaptation layer architecture shown in Figure 3 is disclosed. This is a currently known architecture, sampling the "old solution." The scene mode manager is responsible for scene mode-related business management and control modules, the seat manager is responsible for seat control, and the air conditioning manager is responsible for vehicle air conditioning control. As the intelligence level of vehicle-to-everything (V2X) systems increases, the business divisions become more numerous and complex. Currently, a high-end luxury pure electric vehicle can have up to hundreds of business modules, and there are inevitably overlapping sub-business interfaces between different business units. Designing a reasonable intermediate adaptation layer that can meet the business needs of different applications while ensuring efficient, concise, easy-to-develop, and easy-to-maintain interface design presents a significant challenge to the design of the entire vehicle's API.
[0115] Given that the vehicle-mounted system adaptation layer is becoming increasingly bloated and complex, development and maintenance costs are rising, interface management is chaotic, there is a high degree of interface overlap between different business modules, and code redundancy is becoming increasingly serious.
[0116] To fundamentally address these pain points, in another specific embodiment, an atomic interface design scheme for Key-Value HashMap mapping, as shown in Figure 4, is disclosed.
[0117] The core of this embodiment is to shift the vehicle's API (approximately 1000-2000 interfaces, varying by vehicle model) from a top-down approach based on traditional business module divisions to a bottom-up approach. Instead, it provides the interface capabilities based on the total capabilities (SOA signals) offered by the vehicle's hardware, mapped through globally unique signals. These interfaces are then transformed into atomic interfaces for use by various applications. Data transformation involves converting uplink data or commands into general data understandable to upper-layer applications, and downlink data into specific vehicle SOA signal commands.
[0118] In simple terms, as shown in Figure 4, the original set of business managers is replaced by a globally unique vehicle property ID manager (CarPropertyIDManager). In the vehicle property ID manager, a globally unique functional attribute ID mapping table is used to identify each specific atomic business interface (i.e., corresponding to a specific SOA or CAN signal implementation, as shown in Figure 5).
[0119] By using atomic interface design, overlapping or duplicate business interfaces can be effectively avoided, greatly reducing code redundancy. At the same time, for API users (various APP applications), they only need to simply pass in the Key and Value (Data) parameters to easily call various business interfaces, which is simple and convenient to use and has low maintenance costs in the later stage.
[0120] In this embodiment:
[0121] 1. The atomic interface design is centered on the underlying SOA signals. Each SOA signal represents a capability that the vehicle OS can support, such as opening and closing windows, opening and closing the air conditioning, and changes in vehicle speed status data.
[0122] 2. Each Key (ID) corresponds to a unique SOA signal, which can contain three types of interfaces: Set, Get, and Listener / Callback, as shown in Figure 6. The Set interface corresponds to the Write interface interceptor. This design adopts the chain of responsibility pattern, which facilitates unified and sequential processing of this type of interface and also facilitates subsequent logic unit expansion. The Get and Callback interfaces are similar. It should be noted that the Key's Set interface typically handles downlink data commands, the Get interface handles uplink synchronous data retrieval, and the Callback interface handles uplink asynchronous data retrieval, status monitoring, etc.
[0123] 3. The key point of this application is that a global HashMap mapping table based on key-value pairs is maintained. The key in the table corresponds to a globally unique atomic interface implementation. The specific atomic business interface implementation can be quickly indexed through the key, enabling fast call access.
[0124] 4. The data conversion process is described in Figure 7:
[0125] 1) Downlink: The client APP application sends standard protocol data, which is converted into corresponding SOA or CAN signal data and then sent to the AutoSAR vehicle service (base station) of the operating system.
[0126] 2) Uplink: SOA or CAN signal data is converted into standard protocol data and then returned to the corresponding caller (APP application).
[0127] Each call or callback is for a specific Key (which can be understood as a functional attribute ID); the Key corresponds one-to-one with the SOA or CAN signal and is globally unique, corresponding to an atomic functional unit (control), representing a basic capability that the vehicle system can provide, such as opening the windows, turning on the air conditioning, and checking the driving range, etc.
[0128] 5. The design scheme of this application is compatible with the original old scheme, has a smooth transition capability, and ensures good scalability and stability. (This scheme adopts a "dual-service" packaged design, which is compatible with the new and old vehicle ROM systems; however, it should be noted that for the same vehicle system, only one of the new and old services can be enabled at a time. That is, it is not recommended to enable both the new and old services on the same vehicle system at the same time, otherwise, timing problems may occur in certain special signal overlap scenarios.) As shown in Figure 8:
[0129] Applications (callers) can pass the specific service name parameter to be used through `getService`, and choose whether to enable a new service or an old service based on the specific vehicle model. If the old service is selected, the original API calling method will continue to be used (calling layer by layer according to the access method of the specific business unit Manager). If the new service is selected, the key-value access method will be used, and the corresponding atomic function API will be accessed directly by passing the specific atomic key value (attribute ID) (without first looking up the business unit category). Each key corresponds to three types of specific operations: set, get, and callback, which can cover various business scenarios. It is simple, efficient, easy to extend (by adding keys), and easy to manage (all sub-functions can be uniformly managed through key values), etc.
[0130] In summary, the beneficial effects of this embodiment are as follows:
[0131] 1. Provide an API design and access method based on HashMap for rapid adaptation to the core service capabilities of the vehicle system;
[0132] 2. Accessing vehicle API-related interfaces via atomic business property ID (CarPropertyID) eliminates the need to first obtain instances of each business Manager unit and then call specific business interfaces through those instances. This effectively reduces business interface overlap and redundant code.
[0133] 3. All interfaces are based on the Key-Value design (a globally maintained HashMap mapping table ensures that the specific atomic business interface implementation is dynamically matched during application calls), which is simple and easy to use, and facilitates unified interface generation and processing, thus improving development efficiency;
[0134] 4. In the process of handling business interfaces, a chain of responsibility design is adopted, including a write chain, a read chain, and a callback chain, which correspond to three access (operation) methods for a certain key. Each chain includes multiple operation nodes (log printing OP, null pointer check OP, business processing OP, and anti-explosion point OP). This design is simple and flexible, and is very easy to intercept and process for a certain type of interface, and to add / delete business operations.
[0135] Figure 9 is a block diagram of an electronic device structure based on the atomic interface design method of the vehicle-machine adaptation layer provided by one or more embodiments of the present invention.
[0136] As shown in Figure 9, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0137] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the atomic interface design method for the vehicle-machine adaptation layer.
[0138] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the atomic interface design method for the vehicle-mounted adaptation layer.
[0139] This application also provides a vehicle cabin, including:
[0140] The steps for implementing an atomic interface design method for an electronic device's vehicle-mounted adaptation layer;
[0141] The processor runs the program, and when the program runs, it executes the steps of the atomic interface design method of the vehicle adaptation layer from the data output by the electronic device.
[0142] The storage medium is used to store the program, which, when running, executes the steps of the atomic interface design method of the vehicle-mounted adaptation layer for data output from the electronic device.
[0143] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.
[0144] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.
[0145] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.
[0146] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.
[0147] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.
[0148] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.
[0149] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.
[0150] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.
[0151] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.
[0152] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. An atomic interface design method for a vehicle-mounted infotainment system (V2S) adapter layer, characterized in that, The atomic interface design method of the vehicle-mounted system adaptation layer includes: establishing a globally unique business identifier Key corresponding to the vehicle-mounted system functional attribute ID, and mapping it one-to-one with the vehicle-mounted system SOA signal or CAN signal to form a global HashMap mapping table based on key-value pairs; wherein, the business identifier Key corresponds to a unique atomic functional unit, used to represent a basic capability unit of the vehicle-mounted system; the global HashMap mapping table is maintained by the vehicle-mounted system attribute ID manager CarPropertyIDManager, used to replace the business module unit manager Manager, for unified management of atomic interfaces; the application layer directly indexes the target atomic interface in the global HashMap mapping table by passing in the business identifier Key and the corresponding value data parameters, and completes the interface call; wherein, during the call process, a data conversion process is executed, including: when downlinking, converting the standard protocol data passed by the application APP into SOA or CAN signal data and passing it into the AutoSAR vehicle-mounted system service; when uplinking, converting the SOA or CAN signal data into standard protocol data and returning it to the application APP.
2. The atomic interface design method for the vehicle-machine adaptation layer according to claim 1, characterized in that, include: The atomic interfaces include: a Set interface for processing downlink data commands; a Get interface for synchronously acquiring uplink data; and a Callback interface for asynchronously acquiring uplink data and monitoring status.
3. The atomic interface design method for the vehicle-machine adaptation layer according to claim 2, characterized in that, include: The Set, Get, and Callback interfaces correspond to the Write, Read, and Notify interceptors, respectively, and are designed using the chain of responsibility pattern. Each interceptor in the chain of responsibility includes multiple OP operation nodes that are executed sequentially. The OP operation nodes include at least one of the following: log printing OP, null pointer check OP, business processing OP, and anti-explosion point OP.
4. The atomic interface design method for the vehicle-machine adaptation layer according to claim 1, characterized in that, include: The HashMap global mapping table supports dynamic expansion; specifically, the expansion of the HashMap global mapping table is achieved by adding a new business flag key and the corresponding SOA / CAN signal mapping relationship, thereby expanding the interface of new basic capabilities of the vehicle system.
5. The atomic interface design method for the vehicle-machine adaptation layer according to claim 1, characterized in that, Also includes: The Proxy layer receives a service request from the application (APP) and, based on the service type specified by the application (APP), selectively returns either the HQCarControlManager entity Binder or the CarAdapterManager entity Binder. The application (APP) obtains the service name parameter by using the getService method. Based on the vehicle model correspondence, the application (APP) selects the service type it wants to enable according to the corresponding service name.
6. A vehicle-mounted infotainment system, characterized in that, The atomic interface design method for the vehicle-to-everything (V2X) adaptation layer as described in any one of claims 1 to 5, wherein the V2X adaptation layer system comprises: a vehicle-to-everything (V2X) attribute ID management module, used to maintain a global HashMap mapping table to implement mapping management between Key and SOA / CAN signals; an interface calling module, used to receive Key and Value parameters passed from the application layer and index the target atomic interface through the global HashMap mapping table; a data conversion module, used to execute uplink and downlink data conversion processes to realize bidirectional conversion between standard protocol data and SOA / CAN signal data; and a chain-of-responsibility processing module, used to sequentially process and extend the Set, Get, and Callback interfaces through interceptors and OP operation nodes.
7. The vehicle-to-machine adaptation layer system according to claim 6, characterized in that, Also includes: The proxy adaptation module is used to switch between the new service interface call mode and the old service interface call mode according to the application's service selection instructions. The new service interface invocation mode includes directly accessing atomic interfaces via a key; the old service interface invocation mode includes calling interfaces layer by layer through the business unit manager.
8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the atomic interface design method for the vehicle-mounted adaptation layer as described in any one of claims 1 to 5.
9. A computer-readable storage medium, characterized in that, The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the atomic interface design method for the vehicle-machine adaptation layer as described in any one of claims 1 to 5.
10. A vehicle cabin, characterized in that, include: An electronic device for implementing the steps of the atomic interface design method for the vehicle-machine adaptation layer as described in any one of claims 1 to 5; A processor, which runs a program that, when running, executes the steps of the atomic interface design method for the vehicle-mounted adaptation layer as described in any one of claims 1 to 5 on data output from an electronic device; and a storage medium for storing a program that, when running, executes the steps of the atomic interface design method for the vehicle-mounted adaptation layer as described in any one of claims 1 to 5 on data output from an electronic device.