Universal storage method, device and equipment based on automobile open system architecture and storage medium

Abstract

The invention discloses a general storage method, device and equipment based on an automobile open system architecture and a storage medium, and relates to the technical field of vehicle storage management, and the general storage method based on the automobile open system architecture comprises the following steps: receiving a data storage request and to-be-stored data; confirming a target storage space of the to-be-stored data according to the identifier of the data storage request; and writing the to-be-stored data into the target storage space after mask setting. According to the method and the device, the data consistency can be ensured when multiple users concurrently store the data, the data conflict is avoided, meanwhile, the stability of the system is improved, the service life of the storage medium is prolonged, and the accuracy, efficiency and reliability of data storage are ensured.

Description

Technical Field

[0001] This application relates to the technical field of vehicle storage management, and in particular, to a general storage method, device, equipment, and storage medium based on the automotive open system architecture. Background Art

[0002] With the rapid development of automotive electronics technology, the number of electronic control units (ECUs) integrated in vehicles has been increasing continuously. These ECUs need to process and store a large amount of data. AUTOSAR (AUTomotive Open System ARchitecture), as an automotive open system architecture, provides a standardized software framework to support the design and development of automotive electronic systems. In this architecture, the memory management module / non-volatile memory (NVM) is responsible for storing critical data, such as vehicle configuration information, fault codes, etc. These data need to maintain consistency and reliability during the life cycle of the ECU to ensure the normal operation and safety of the vehicle. Therefore, for the field of automotive electronic control, implementing an efficient and reliable data storage solution is crucial.

[0003] In the AUTOSAR architecture, the memory management module is responsible for data storage. Developers need to manually implement write operations and consider the problems that may occur when multiple requests occur simultaneously. Generally, when there is data to be stored, the ECU will write the data through the interface provided by the NVM module. This process involves operations such as interface calls and status judgments. If multiple users (i.e., different ECUs or software modules) perform data storage simultaneously, developers need to solve the problems of data consistency and write operation conflicts by themselves. In existing practices, each project needs to manually implement write operations and needs to consider various problems during the data storage process, such as data consistency and concurrent write conflicts.

[0004] Existing NVM modules have some limitations when dealing with multi-user concurrent storage. First, when multiple users request to store data simultaneously, data write conflicts may occur, resulting in data inconsistency or software failures. Second, each project needs to manually implement write operations, which not only increases the development difficulty and cost but also is not conducive to software stability and maintainability. In addition, for the storage information required by the diagnostic module, users need to re-develop the code, which increases the workload. Moreover, for the storage of other data, there is a lack of a unified interface, making it difficult for users to directly call and difficult to avoid conflicts and other problems. Therefore, how to ensure data consistency when multiple users concurrently store data and avoid data conflicts has become an urgent problem to be solved.

[0005] The above content is only used to assist in understanding the technical solution of the present application, and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The purpose of the present application is to provide a general storage method, device, equipment and storage medium based on the automotive open system architecture, aiming to solve the technical problem of how to ensure data consistency when multiple users concurrently store data and avoid data conflicts.

[0007] To achieve the above object, the present application proposes a general storage method based on the automotive open system architecture, and the method includes:

[0008] Receiving a data storage request and data to be stored;

[0009] Confirming the target storage space of the data to be stored according to the identifier of the data storage request;

[0010] Writing the data to be stored into the target storage space after mask setting.

[0011] In an embodiment, the step of writing the data to be stored into the target storage space after mask setting includes:

[0012] Setting the mask corresponding to the target storage space;

[0013] Copying the data to be stored into the cache;

[0014] Writing the data to be stored in the cache into the target storage space after mask setting.

[0015] In an embodiment, the target storage space is located in a non-volatile memory;

[0016] The step of writing the data to be stored in the cache into the target storage space after mask setting includes:

[0017] Obtaining the working state of the non-volatile memory;

[0018] When the working state is the idle state, switching the working state to the changing state through the write interface of the non-volatile memory;

[0019] When the working state is the changing state, writing the data to be stored in the cache into the target storage space after mask setting through a data block write function.

[0020] In an embodiment, after the step of writing the data to be stored in the cache into the target storage space after mask setting when the working state is the changing state, the method further includes:

[0021] Switch the working state from the changed state to the data writing state;

[0022] When the working state is the data writing state and the writing operation starts, switch the working state to the waiting for completion state;

[0023] When the time that the non-volatile memory is in the waiting for completion state is greater than a preset writing duration, switch the working state to the busy state until all the data to be stored is written into the target storage space.

[0024] In one embodiment, the target storage space is located in the non-volatile memory;

[0025] The step of setting the mask corresponding to the target storage space includes:

[0026] Periodically detect the status of the mask of the target storage space through a periodic function;

[0027] When the status of the mask is set, check the working state of the non-volatile memory;

[0028] When the working state is the idle state, clear the bits of the mask through the writing interface of the non-volatile memory.

[0029] In one embodiment, before the step of receiving the data storage request and the data to be stored, it further includes:

[0030] When the data to be stored is diagnostic data, configure the diagnostic identifier corresponding to the diagnostic data;

[0031] After the configuration is completed, generate the service port corresponding to the diagnostic data through a preset configuration tool;

[0032] Connect to the service port through the operation trigger event access mode.

[0033] In one embodiment, the step of generating the service port corresponding to the diagnostic data through a preset configuration tool includes:

[0034] Determine the data type, data interaction frequency, and data interaction conditions according to the data to be stored;

[0035] Determine the data transmission direction, data transmission rate, and data identifier in the preset configuration tool according to the data type, the data interaction frequency, and the data interaction conditions;

[0036] Create a port instance and allocate communication signals to the port instance;

[0037] Assign parameters to the port instance after the communication signal is allocated according to the data transmission direction, the data transmission rate, and the data identifier;

[0038] Map the port instance after the parameters are assigned to a communication channel to obtain a service port corresponding to the diagnostic data.

[0039] In addition, to achieve the above object, the present application also proposes a general storage device based on the automotive open system architecture, and the device includes:

[0040] A data acquisition module, configured to receive a data storage request and data to be stored;

[0041] A storage space determination module, configured to confirm a target storage space for the data to be stored according to an identifier of the data storage request;

[0042] A data storage module, configured to write the data to be stored into the target storage space after the mask is set.

[0043] In addition, to achieve the above object, the present application also proposes a general storage device based on the automotive open system architecture, and the device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, where the computer program is configured to implement the steps of the general storage method based on the automotive open system architecture as described above.

[0044] In addition, to achieve the above object, the present application also proposes a storage medium, where the storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the general storage method based on the automotive open system architecture as described above are implemented.

[0045] In addition, to achieve the above object, the present application also provides a computer program product, where the computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the general storage method based on the automotive open system architecture as described above are implemented.

[0046] One or more technical solutions proposed by the present application have at least the following technical effects:

[0047] Receive a data storage request and the data to be stored; confirm the target storage space for the data to be stored according to the identifier of the data storage request; write the data to be stored into the target storage space after the mask is set. The general data storage module (MEMC) first receives the data storage request and the data to be stored from other modules or systems of the ECU. This step ensures that the data is correctly identified and prepared before entering the storage process, laying a foundation for subsequent storage operations. Next, MEMC looks up the corresponding record in the internal mapping table or database according to the identifier in the data storage request to determine the exact storage location of the data to be stored in the EEPROM, that is, the target storage space. This is done to ensure that each data item is stored in the correct location, avoiding data misalignment or overwriting, which is crucial for data integrity and system reliability. Finally, MEMC writes the data to be stored into the target storage space after the mask is set. After determining the target storage space, MEMC writes the data to be stored into this space and marks that this data item needs to be written by setting the corresponding bits in the mask. In periodic checks, MEMC will detect the status of the mask and perform the write operation when the mask bit is set. This is done to ensure that the write operation is only performed when the mask bit is set, that is, only when the data actually needs to be written, which can avoid unnecessary writes, reduce wear on the storage medium, and improve the write efficiency. These steps combined can ensure data consistency when multiple users concurrently store data, avoid data conflicts, improve system stability and the service life of the storage medium, and ensure the accuracy, efficiency, and reliability of data storage. Description of the Drawings

[0048] The drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0049] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0050] Figure 1 It is a schematic flowchart provided for Embodiment 1 of the general storage method based on the automotive open system architecture of the present application;

[0051] Figure 2 It is a schematic diagram of a data storage request provided for Embodiment 1 of the general storage method based on the automotive open system architecture of the present application;

[0052] Figure 3Schematic diagram of diagnostic data flow provided for Embodiment 1 of the general storage method based on the automotive open system architecture in this application;

[0053] Figure 4 Flow chart provided for Embodiment 2 of the general storage method based on the automotive open system architecture in this application;

[0054] Figure 5 Schematic diagram of the working state of NVM provided for Embodiment 2 of the general storage method based on the automotive open system architecture in this application;

[0055] Figure 6 Schematic diagram of the design framework of the MEMC module storage provided for Embodiment 2 of the general storage method based on the automotive open system architecture in this application;

[0056] Figure 7 Schematic diagram of the data storage process provided for Embodiment 2 of the general storage method based on the automotive open system architecture in this application;

[0057] Figure 8 Schematic diagram of the module structure of the general storage device based on the automotive open system architecture for the embodiment of this application;

[0058] Figure 9 Schematic diagram of the device structure of the hardware operating environment involved in the general storage method based on the automotive open system architecture in the embodiment of this application.

[0059] The realization of the purpose, functional features and advantages of this application will be further described with reference to the embodiments and the accompanying drawings. Detailed implementation manners

[0060] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not used to limit this application.

[0061] In order to better understand the technical solutions of this application, the following will be described in detail with reference to the accompanying drawings of the specification and the specific implementation manners.

[0062] With the development of automotive electronic technology, the number of ECUs and their data processing requirements are increasing continuously. The memory management module (NVM) in the AUTOSAR architecture is responsible for storing critical data to ensure its consistency and reliability. However, the existing NVM modules have limitations in dealing with multi-user concurrent storage: when multiple users request to store data simultaneously, write conflicts and data inconsistency problems may occur; each project needs to manually implement the write operation, which increases the development difficulty, cost, and affects the software stability and maintainability. In addition, the lack of a unified interface requires developers to rewrite code for different data storage requirements, further increasing the workload and complexity. Therefore, implementing an efficient and reliable data storage solution is crucial for the automotive electronic control field.

[0063] The main solution of the embodiment of this application is that the general data storage module (MEMC) receives a data storage request and data from the ECU, determines the target storage location in the EEPROM according to the identifier in the request, ensures that the data is accurately stored, and avoids misalignment or overwriting. Subsequently, the MEMC writes the data into the target storage space after the mask is set, and only performs the write operation when the mask bit is set, so as to reduce unnecessary writes, reduce the wear of the storage medium and improve the efficiency.

[0064] It should be noted that the execution subject of the embodiment of this application can be a computing service device with data processing, network communication, and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a general data storage module, etc. that can implement the above functions. Hereinafter, the general data storage module is taken as an example to illustrate this embodiment and the following embodiments.

[0065] Based on this, the embodiment of this application provides a general storage method based on the automotive open system architecture, referring to Figure 1 , Figure 1 is the flowchart of the first embodiment of the general storage method based on the automotive open system architecture of this application.

[0066] In this embodiment, the general storage method based on the automotive open system architecture includes steps S10 to S30:

[0067] Step S10, receiving a data storage request and data to be stored;

[0068] It should be noted that a data storage request refers to a request issued when a certain module or system in the ECU needs to save data to a non-volatile memory (NVM). Such requests are usually initiated by software modules in the ECU, which need to ensure that certain critical data can still be retained after a power outage. In the AUTOSAR architecture, data storage requests are carried out through specific interfaces and protocols. These requests go through a series of processing flows and finally reach the module responsible for storage. For example, the General Data Storage Module (MEMC) receives data storage requests from the Diagnostic Communication Management Module (DCM). These requests may be due to the need to write data such as the Vehicle Identification Number (VIN) and vehicle configuration information into the Electrically Erasable Programmable Read-Only Memory (EEPROM) by a diagnostic instrument. The data to be stored refers to the data that has been determined to need to be stored in the NVM. These data may include vehicle configuration parameters, fault codes, calibration parameters, etc., which are required for the normal operation of the ECU. The data to be stored refers to the data that has been received by the MEMC module and is ready to be written into the EEPROM. The MEMC module will find the corresponding storage space according to the request ID, then copy these data to be stored into the corresponding storage space, and mark the data with this ID, indicating that storage is required.

[0069] Please refer to Figure 2 , Figure 2 FIG. is a schematic diagram of a data storage request provided for Embodiment 1 of the general storage method based on the automotive open system architecture of the present application. This figure shows how the General Data Storage Module (MEMC) processes data storage requests by synchronously calling read and write data functions in the service interface under the AUTOSAR architecture. In the figure, multiple Synchronous Server Call Points can be seen, which respectively correspond to different NVM services (Nvm_Service), including ReadData and WriteData operations. These call points communicate with the NVM service through the Client Port to achieve data reading and writing. For example, "SC_Nvm_Service_0" represents a service instance, which may be responsible for processing specific data storage requests from the MEMC module. When the MEMC module receives a data storage request, it determines the target storage space according to the identifier of the request and copies the data to be stored into the cache. Subsequently, the MEMC module writes the data in the cache into the masked target storage space through these synchronous call points.

[0070] It is understandable that the general data storage module listens for data storage requests and data to be stored from other modules such as DCM. These requests contain the key information that needs to be stored in the EEPROM.

[0071] As an example, before the step of receiving the data storage request and the data to be stored, it further includes: when the data to be stored is diagnostic data, configuring the diagnostic identifier corresponding to the diagnostic data; in the case of completion of the configuration, generating the service port corresponding to the diagnostic data through a preset configuration tool; and connecting to the service port through the operation trigger event access mode.

[0072] Diagnostic data refers to the data related to the vehicle diagnostic function, such as the VIN number of the vehicle, vehicle configuration information, etc. These data are usually written through a diagnostic instrument when the vehicle comes off the production line and need to be stored in the EEPROM for subsequent diagnosis and configuration. The diagnostic identifier (DID) is an identifier used to uniquely identify diagnostic data in the AUTOSAR architecture. Each diagnostic data to be stored will have a corresponding DID, which is configured in the DCM module to distinguish different diagnostic data. The preset configuration tool refers to the tool used to configure and generate system parameters, interfaces, and modules during the AUTOSAR development process. For example, using configuration tools such as ETAS INCA or Vector DAEMON, developers can define and configure the parameters and interfaces of the ECU, including the DID of the diagnostic data and the corresponding service port. The service port (RPORT) is an interface for data transmission in the AUTOSAR architecture. After the DCM module configures the DID of the diagnostic data, a corresponding service port will be generated. This service port is used to transmit the diagnostic data from the DCM module to the MEMC module. The operation trigger event access mode (operationinvokeevent) is a communication mechanism in AUTOSAR that allows a module (such as MEMC) to trigger a Runnable (runnable code block) to process data when receiving a specific event. When a diagnostic data storage request occurs, it will trigger the Runnable in the MEMC module, and this Runnable will further process the storage request, including calling the service interface function of the NVM module to prepare for data storage.

[0073] First, when the general data storage module (MEMC) processes diagnostic data to be stored, it needs to cooperate with the diagnostic communication management (DCM) module of the ECU. For this purpose, MEMC configures a unique diagnostic identifier (DID) for each piece of diagnostic data. This identifier is a string of numbers used to uniquely identify specific diagnostic information within the ECU. This is done to ensure the accuracy and uniqueness of data during transmission and storage. Secondly, MEMC uses the preset configuration tool of AUTOSAR to generate a corresponding service port (RPORT) based on each DID. This service port is the channel for data transmission, which allows the DCM module to send diagnostic data to the MEMC module. The specific operation of generating the service port is configured through the graphical interface or script of the configuration tool, specifying the path and method of data transmission. This is done to establish a standardized data transmission interface to ensure that data can be safely and efficiently transmitted from DCM to MEMC. Finally, MEMC connects to the service port generated by the DCM module by setting the operation trigger event access mode (operationinvokeevent). This means that when the DCM module sends a storage request through the service port, the MEMC module can immediately respond and trigger a Runnable for data processing. This Runnable will perform the data storage operation according to the specific content of the storage request. This achieves real-time response and processing of diagnostic data, improves the efficiency of data processing, and through this event-driven method, the MEMC module can handle multiple storage requests simultaneously without data conflicts or storage failures due to concurrent operations, thus ensuring data consistency and system stability.

[0074] Please refer to Figure 3 , Figure 3This is a schematic diagram of the diagnostic data flow provided by the first embodiment of the general storage method based on the automotive open system architecture in this application. This diagram shows the flow of diagnostic data from the diagnostic instrument to the non-volatile memory (NVM) under the AUTOSAR architecture. When the diagnostic instrument issues a data write request, the request is first received by the CAN driver (CANDrv) and then passed to the CAN interface (CANIF) module. Next, the CANIF module identifies that this is a diagnostic request and passes the data to the CAN transport protocol (CANTP) layer. After the CANTP layer processes the request, it sends the request to the physical diagnostic user (PDUR) module. The PDUR module passes the request to the diagnostic communication management (DCM) module according to the preset configuration information. After receiving the read / write request, the DCM module passes the request to the general data storage module (MEMC). Subsequently, the MEMC module calls the NVM interface and performs a series of logical operations, including copying the data to the cache, setting the mask bits, periodically checking the NVM status, and writing the data to the specified storage space when the NVM is idle. This process ensures that the data can be correctly and securely stored in the NVM, while avoiding data conflicts during multi-user concurrent storage, improving the data storage consistency and system stability. Finally, the MEMC module interacts with the NVM through the MEMIF (memory interface) to complete the data write operation.

[0075] As an example, the step of generating the service port corresponding to the diagnostic data by the preset configuration tool includes: determining the data type, data interaction frequency, and data interaction conditions according to the data to be stored; determining the data transmission direction, data transmission rate, and data identifier in the preset configuration tool according to the data type, the data interaction frequency, and the data interaction conditions; creating a port instance and allocating communication signals to the port instance; allocating parameters to the port instance after allocating communication signals according to the data transmission direction, the data transmission rate, and the data identifier; mapping the port instance after allocating parameters to the communication channel to obtain the service port corresponding to the diagnostic data.

[0076] Data type refers to the format and type of diagnostic data to be stored. In the AUTOSAR architecture, data types can be integers, floating-point numbers, strings, etc., depending on the content and purpose of the data. For example, the VIN number of a vehicle may be a string type, while configuration parameters may be integer types. Data interaction frequency refers to the frequency at which diagnostic data is exchanged between ECUs or with external devices. This can be real-time, periodic, or event-based. For example, some diagnostic data may be exchanged only once when the vehicle starts, while other data may need to be exchanged multiple times per second. Data interaction conditions refer to the specific conditions or events that trigger data interaction. This may include specific time points, system state changes, user operations, or other predefined conditions. For example, certain diagnostic data may only be exchanged when a specific fault occurs in the vehicle. Data transfer direction refers to the direction in which data flows. It can be from the ECU to other modules (transmission), from other modules to the ECU (reception), or two-way transfer. In the context of diagnostic data, it may involve write operations from the diagnostic tool to the ECU and read operations from the ECU to the diagnostic tool. Data transfer rate refers to the speed at which data is transmitted in the communication channel, usually measured in bits per second (bps). For diagnostic data, this rate needs to be determined based on the size and interaction frequency of the data to ensure that the data can be transmitted in a timely and accurate manner. Data identifiers (such as DIDs) are identifiers used in the AUTOSAR architecture to uniquely identify specific diagnostic data. It is a string of numbers or characters used to distinguish different data items during the communication process. A port instance refers to a specific object created in the AUTOSAR configuration tool. It represents the interface for data transfer. The port instance defines how data is transferred from one module to another, including the data format, transfer method, etc. A communication signal refers to a data packet transmitted within or between ECUs. These signals contain the actual data to be transmitted, as well as possible control information such as synchronization signals and error detection codes. A communication channel refers to the path for data transfer, which can be physical (such as CAN bus, LIN bus) or logical (such as network protocols). In the AUTOSAR architecture, the communication channel is responsible for transmitting communication signals from one ECU to another ECU or external device.

[0077] First, when the general data storage module (MEMC) processes diagnostic data to be stored, it determines the data type according to the characteristics and uses of the data. For example, if the data is the VIN number of a vehicle, it will be defined as a string type. At the same time, MEMC determines the frequency of data interaction according to the usage scenario of the data. For example, some data may only need to be interacted once when the vehicle starts, while other data may need to be updated in real time. In addition, MEMC also determines the conditions for data interaction. For example, data interaction only occurs when a specific fault code is detected. This is done to ensure that data is processed and stored in the correct format at the correct time, improving the efficiency and accuracy of data management.

[0078] Secondly, MEMC sets the specific parameters of data transmission in the preset configuration tool according to the determined data type, interaction frequency, and conditions, including the direction of data transmission (whether it is sent from one module to another module or received from an external device), the rate of data transmission (ensuring that data can be transmitted in a timely manner without delay due to too low a rate), and the data identifier (DID), which is a string of numbers used to uniquely identify specific diagnostic data in the ECU. These settings ensure that data can be correctly identified and routed in the ECU network, improving the reliability of communication.

[0079] Then, MEMC creates a port instance, which is the specific implementation of the data transmission interface, and assigns communication signals to this port instance. These signals contain the actual data to be transmitted and necessary control information, such as synchronization signals, error detection codes, etc. Then, MEMC assigns parameters to the port instance according to the previously set transmission direction, rate, and identifier. These parameters define how the data is encapsulated and transmitted, ensuring the transmission efficiency and correctness of data in the ECU network.

[0080] Finally, MEMC maps the configured port instance to the communication channel. This channel can be physical (such as a CAN bus) or logical (such as a network protocol). By associating the port instance with the communication channel, it ensures that diagnostic data can be transmitted to the target ECU or device through the correct path, thus realizing the efficient and accurate transmission and storage of diagnostic data, and improving the diagnostic ability and reliability of the entire automotive electronic system.

[0081] Step S20, confirm the target storage space of the data to be stored according to the identifier of the data storage request;

[0082] It should be noted that the Request Identifier is a unique identification code associated with a data storage request. When a certain module or system in the ECU needs to store data in the EEPROM, it issues a request containing the identifier, which is used to find the corresponding storage space in the General Data Storage Module. The identifier can be a number, a string, or any other form of unique identifier, which ensures that the request can be correctly identified and processed. In the AUTOSAR architecture, this identifier may be associated with specific diagnostic data (DID) or the key value of user data. The target storage space refers to the storage area allocated or determined for the data to be stored in the non-volatile memory (NVM). The MEMC module determines the location in the EEPROM where the data should be stored based on the received identifier, and this location is the so-called target storage space. The target storage space can be a specific memory address, a data block, or any other form of storage area, which is configured to store specific types of data. In the MEMC module, each identifier is associated with a specific target storage space, so that when the MEMC receives a storage request, it can directly write the data to the correct location.

[0083] It can be understood that, first, when the MEMC receives a data storage request, it checks the identifier contained in the request, which is the unique identification code associated with the data to be stored; second, the MEMC uses this identifier as a keyword to query in the internal mapping table or database to find the record that matches this identifier, and this record specifies the exact storage location of the data to be stored in the EEPROM, that is, the target storage space; finally, the MEMC writes the data to be stored into this target storage space. The reason for doing this is that each identifier uniquely corresponds to a storage location, which can ensure that the data is correctly stored in the predetermined and appropriate location, prevent data misalignment or overwriting of other important information, thus ensuring the accuracy of the data and the reliability of the system. The effect of this mechanism is to improve the efficiency of the storage operation, because it allows the MEMC to process multiple data storage requests simultaneously without causing data chaos due to concurrent operations, and also reduces the risk of system failures caused by storage errors.

[0084] Step S30: Write the data to be stored into the target storage space after the mask is set.

[0085] It should be noted that mask setting is a technical means used to mark that specific data needs to be written into the storage space. Specifically, a mask is a binary value, and each bit corresponds to a specific data item or storage area. When a certain bit is set (masked) to 1, it indicates that the corresponding data item needs to be written into the storage space. This is a common marking mechanism used to manage at the software level which data needs to be written into non-volatile memory (such as EEPROM).

[0086] It can be understood that, first, after receiving a data storage request, the general data storage module will, according to the identifier in the request, find the specific bit corresponding to the identifier in the internally maintained mask data structure and set it to 1. This operation is called "mask setting", and this is done to mark which data items need to be written to the storage device; second, MEMC will periodically check this mask. Once it finds that a bit is set to 1, it will know that the corresponding data item needs to be written into the EEPROM. MEMC will copy the data to be stored to the target storage space associated with the identifier, that is, the predetermined position in the EEPROM; finally, after completing the data copy, MEMC will clear the corresponding bit in the mask and reset it to 0, indicating that the write operation of the data item has been completed. This enables MEMC to effectively manage concurrent data storage requests, ensure that data is written to the storage device in the correct order and position, and at the same time avoid data conflicts and storage errors, improving the reliability and efficiency of the storage operation.

[0087] This embodiment provides a general storage method based on the automotive open system architecture, which receives a data storage request and data to be stored; confirms the target storage space of the data to be stored according to the identifier of the data storage request; and writes the data to be stored into the target storage space after the mask is set. The general data storage module (MEMC) first receives a data storage request and data to be stored from other modules or systems of the ECU. This step ensures that the data is correctly identified and prepared before entering the storage process, laying a foundation for subsequent storage operations. Then, MEMC looks up the corresponding record in the internal mapping table or database according to the identifier in the data storage request to determine the exact storage location of the data to be stored in the EEPROM, that is, the target storage space. This is to ensure that each data item is stored in the correct location, avoiding data misalignment or overwriting, which is crucial for data integrity and system reliability. Finally, MEMC writes the data to be stored into the target storage space after the mask is set. After determining the target storage space, MEMC will write the data to be stored into this space and mark that this data item needs to be written by setting the corresponding bits in the mask. During periodic checks, MEMC will detect the status of the mask and perform the write operation when the mask bit is set. This is to ensure that the write operation is only performed when the mask bit is set, that is, only when the data actually needs to be written, which can avoid unnecessary writes, reduce wear on the storage medium, and improve write efficiency. These steps combined can ensure data consistency when multiple users concurrently store data, avoid data conflicts, improve system stability and the service life of the storage medium, and ensure the accuracy, efficiency, and reliability of data storage.

[0088] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the above-mentioned embodiment one can be referred to the above introduction and will not be elaborated hereinafter. On this basis, please refer to Figure 4 , Figure 4 which is a schematic flowchart of the second embodiment of the general storage method based on the automotive open system architecture of this application. The step S30 of the general storage method based on the automotive open system architecture includes steps S31 to S33:

[0089] Step S31, set the mask corresponding to the target storage space;

[0090] It can be understood that, first, after receiving a data storage request and determining the target storage space for the data to be stored, the universal data storage module (MEMC) will check the internally maintained mask data structure. This mask is a binary sequence in which each bit corresponds to a specific storage space; secondly, the MEMC will find the specific bit corresponding to the target storage space, and then perform a bit operation to change the bit from 0 to 1. This operation is called "setting", which means marking the data to be written to the storage space. It provides a clear indication for subsequent periodic checks, so that the MEMC can identify which storage spaces need to be written when checking the mask. It allows the MEMC to handle multiple concurrent storage requests in an efficient and orderly manner, avoiding conflicts when writing data, and ensuring that data can be correctly written to the predetermined location.

[0091] As an example, the target storage space is located in a non-volatile memory; the step of setting the mask corresponding to the target storage space includes: detecting the state of the mask of the target storage space through a periodic function loop; when the state of the mask is set, checking the working state of the non-volatile memory; when the working state is an idle state, clearing the mask bit through the write interface of the non-volatile memory.

[0092] Non-volatile memory (NVM) refers to a storage device that can keep data intact even when power is off, such as EEPROM (Electrically Erasable Programmable Read-Only Memory). In automotive electronic systems, NVM is used to store important configuration data and diagnostic information that need to be stored for a long time. A periodic function refers to a function or task that is executed regularly in software. It runs repeatedly at a certain time interval or period. In the MEMC module, this function is used to periodically check the status of the mask to determine whether there is data to be stored that needs to be written to the NVM. A mask is a bit field used to mark a specific condition or state. It is usually used to control and track multiple data items or operations. In MEMC, the mask is used to mark which data items need to be written to the NVM. The state here refers to the current value of the mask, especially whether a bit in the mask is set (set to 1), indicating that the corresponding data item needs to be written to the NVM. The working state refers to the current working mode of the NVM, such as whether a write operation is being performed, whether it is available, etc. The idle state means that the NVM has no ongoing read or write operations and is in a standby state, ready to accept new write requests. The write interface refers to the software function or hardware interface provided by NVM for performing data write operations. Through this interface, MEMC can send data to NVM and perform write operations. The mask bit refers to a single binary bit in the mask. Each bit corresponds to a specific data item or storage space. When a bit is set, it indicates that the corresponding data item needs to be written to NVM.

[0093] Please refer to Figure 5 , Figure 5 This is a schematic diagram of the NVM working state provided for the second embodiment of the general storage method based on the automotive open system architecture in this application. This diagram shows the working state transition process of the non-volatile memory (NVM) under the AUTOSAR architecture. The initial state is idle, indicating that the NVM is not performing any write operations currently and is in a standby state. When the general data storage module (MEMC) receives a write request and is ready to execute the write operation, it calls the SetRamBlockStatus function to set the status information of the RAM block, which is to ensure the correctness and integrity of the data before writing. Subsequently, if the NVM is in the idle state, MEMC will switch the status of the NVM to WriteBlock (write data state) and start writing the data in the cache to the NVM. During the writing process, if the working state of the NVM is busy (non-idle state), this may mean that the NVM is processing other write requests, or the write operation takes longer to complete. In this case, MEMC will continuously monitor the status of the NVM until the write operation is completed. Once the write operation starts, the status of the NVM may change to WaitDone (waiting for write completion), which means that the NVM is waiting for the final confirmation of the write operation. If the NVM remains in the waiting-for-completion state for a duration exceeding the preset write duration, the status of the NVM will remain busy until all data is successfully written to the target storage space. This state transition process ensures the accuracy and efficiency of data writing, while avoiding data conflicts and storage errors, and improving the stability and reliability of the system.

[0094] First, the periodic function implemented in the MEMC module periodically checks a specific mask variable, which is a binary sequence where each bit corresponds to a specific storage request. The purpose of this periodic check is to determine if there is new data to be written to the NVM, as each set (set to 1) bit indicates that the corresponding data item has not yet been written to the memory. Second, when the periodic function detects that a bit in the mask is set, it further checks the working status of the NVM, which is done by querying the status register of the NVM or listening to the status signals of the NVM. Since new write requests can only be processed when the NVM is not busy with other write or read operations, this ensures that data is not overwritten or corrupted when the NVM is busy. Finally, once it is confirmed that the NVM is idle, the MEMC writes the data to be stored to the specified target storage space by calling the write interface function provided by the NVM, and then clears (sets to 0) the corresponding bit in the mask. This action indicates that the data item has been successfully written and no further write operation is required. This enables the MEMC to ensure the correct storage of data in the NVM, avoid data conflicts and storage errors, improve the accuracy and efficiency of storage operations, and reduce unnecessary wear on the NVM by performing write operations only when it is idle, extending its service life. At the same time, it can also ensure data consistency when multiple users concurrently store data and avoid data conflicts.

[0095] Step S32, copy the data to be stored into the cache;

[0096] It should be noted that the cache refers to the memory area set in software to temporarily store data to be written to the non-volatile memory (NVM). This cache area is usually located in the volatile random access memory (RAM) and serves as a transitional storage point for data from the application layer to the NVM.

[0097] It can be understood that, first, the MEMC finds the corresponding cache area according to the identifier in the request. This cache area is pre-allocated in the volatile random access memory to temporarily store data to be written to the non-volatile memory. Then, the MEMC copies the data to be stored from the sending module to this cache area. This is done to temporarily store the data in a fast-access memory area so that when the NVM is ready to write, the write operation can be quickly executed, while reducing the direct access times to the NVM, reducing its wear and improving the write efficiency.

[0098] Please refer to Figure 6 , Figure 6This is a schematic diagram of the storage design framework of the MEMC module provided in the second embodiment of the general storage method based on the automotive open system architecture of this application. This figure shows the storage design framework of the general data storage module (MEMC) in the AUTOSAR architecture. In this framework, the upper-layer application interacts with the MEMC module through multiple readWrite interface clients. These interfaces allow the application layer to send data storage and retrieval requests. Inside the MEMC module, multiple readWrite interface servers are maintained. Each server corresponds to a data buffer (data buffer1 to data buffer5) for temporarily storing the data received from the upper-layer application. These buffers serve as temporary storage areas for data, providing the ability for rapid access and processing of data. When the MEMC receives a write request, it copies the data from the corresponding data buffer to the corresponding buffer (buffer1 to buffer5) in the non-volatile memory (NVM). These buffers are mapped to the physical flash storage space. The MEMC monitors the status of the NVM through periodic checks or event triggers and performs the data write operation when the NVM is idle. This design allows the MEMC to process multiple data storage requests asynchronously, ensuring data storage consistency and system stability, while avoiding data conflicts during multi-user concurrent storage, improving the efficiency and reliability of data storage.

[0099] Please refer to Figure 7 , Figure 7 This is a schematic diagram of the data storage process provided in the second embodiment of the general storage method based on the automotive open system architecture of this application. This figure shows the storage process of the general data storage module (MEMC) for processing data storage requests under the AUTOSAR architecture. The process starts with the application layer sending a storage data request. After receiving the request, the MEMC first sets the corresponding mask bit to mark that there is data to be written. Then, the MEMC copies the data to be stored to the corresponding cache to temporarily store the data and prepare for writing to the non-volatile memory (NVM). The periodic function will loop to detect the status of the mask. Once the mask is set, the MEMC will check the status of the write data task to confirm whether there is a write task in progress. If there is no write task in progress, the MEMC will call the write interface of the NVM to start writing the data in the cache to the specified target storage space in the NVM and clear the corresponding mask bit, indicating that the write task is completed. This process ensures that the data can be written to the NVM in the correct order and location, while avoiding data conflicts during multi-user concurrent storage, improving the accuracy and efficiency of data storage. Through this asynchronous write mechanism, the MEMC can efficiently manage data storage requests, ensuring system stability and reliability.

[0100] Step S33: Write the data to be stored in the cache into the target storage space after the mask is set.

[0101] It can be understood that when it is detected that the corresponding bit in the mask is set, MEMC will check the working state of the NVM to ensure that the NVM is in the idle state and ready to accept the write operation. Once it is confirmed that the NVM is idle, MEMC will write the data in the cache into the target storage space through the write interface provided by the NVM, and clear (set to 0) the corresponding bit in the mask, indicating that the write operation of this data item has been completed. This enables MEMC to ensure that data is written to the predetermined location at the correct time, avoiding data conflicts and storage errors, improving the accuracy and efficiency of the storage operation, and reducing unnecessary wear on the NVM by performing write operations only when the NVM is idle, thus extending its service life.

[0102] As an example, the target storage space is located in a non-volatile memory; the step of writing the data to be stored in the cache into the target storage space after the mask is set includes: obtaining the working state of the non-volatile memory; when the working state is the idle state, switching the working state to the changing state through the write interface of the non-volatile memory; when the working state is the changing state, writing the data to be stored in the cache into the target storage space after the mask is set through a data block write function.

[0103] The changing state refers to a temporary working state of the non-volatile memory (NVM), indicating that the NVM is about to perform a data write operation. When MEMC detects that the mask is set, that is, there is data to be written to the NVM, it will switch the working state of the NVM from the idle state to the changing state through the write interface. The setting of this state is to notify other parts of the system that the NVM is about to perform a write operation, thus avoiding new write requests from being processed before the current write operation is completed, and ensuring the integrity and consistency of the data write. The data block write function refers to a specific function or service program provided by the NVM for performing data write operations. This function is responsible for writing a certain amount of data (data block) from the cache or other temporary storage areas to the specified location in the NVM. In the AUTOSAR architecture, this function may be closely integrated with the NVM driver or management module to ensure that the data can be correctly written to the NVM according to the predetermined format and protocol. The data block write function will handle all the details of communicating with the NVM, including error detection, checksum, and write confirmation, etc.

[0104] First, the general data storage module (MEMC) obtains its current working state by querying the status register of the non-volatile memory (NVM) or listening to the status signal. This step is to determine whether the NVM is in a state where it can receive new write requests. Second, if the working state of the NVM is detected as the idle state, MEMC will send a command through the write interface provided by the NVM to switch the working state of the NVM from idle to the changing state. This changing state indicates that the NVM is about to perform a data write operation. This is done to prepare the NVM to accept new data and prevent other operations from interfering. Finally, when the NVM is in the changing state, MEMC calls the data block write function. This function is responsible for writing the data in the cache to the specific target storage space in the NVM according to the specified mask setting information. This operation involves safely transferring the data from volatile memory to non-volatile memory. The whole process ensures the correct storage of data in the NVM, avoids data conflicts and storage errors, improves the accuracy and efficiency of storage operations, and by performing write operations only when the NVM is idle, reduces unnecessary wear on the NVM and extends its service life.

[0105] As an example, after the step of writing the data to be stored in the cache to the target storage space after mask setting through the data block write function when the working state is the changing state, it further includes: switching the working state from the changing state to the write data state; when the working state is the write data state and the write operation starts, switching the working state to the waiting for completion state; when the time that the non-volatile memory is in the waiting for completion state is greater than the preset write duration, switching the working state to the busy state until all the data to be stored is written to the target storage space.

[0106] The write data state refers to a working state of a non-volatile memory (NVM), indicating that the NVM has started to execute a data write operation. When the data block write function is called and the data to be stored begins to be transferred from the cache to the NVM, the working state of the NVM will be switched to the write data state. This state is set to notify other parts of the system that the NVM is performing a data write to ensure data consistency and integrity. The waiting for completion state refers to an intermediate state of the NVM after the data write operation is completed, indicating that the NVM is waiting for the final confirmation of the write operation. When the write operation starts, the NVM will enter the waiting for completion state until the write operation is completely finished. This state is used to track the write progress and ensure that all data has been successfully written to the NVM. The preset write duration refers to a time length preset according to the write speed of the NVM and the size of the data to be written, used to estimate the time required to complete the write operation. For example, if it usually takes 10 milliseconds for the NVM to write 1KB of data, then this time can be used as the preset write duration. This duration is used to determine whether the write operation is completed within a reasonable time and whether error handling measures need to be taken. The busy state refers to a working state of the NVM, indicating that the NVM is busy executing the write operation and temporarily cannot accept new write requests. When the time that the NVM is in the waiting for completion state exceeds the preset write duration but the write operation has not been completed, the working state of the NVM will be switched to the busy state. This state is set to indicate to other parts of the system that the NVM is currently unavailable and prevent new write requests from interfering with the ongoing write operation.

[0107] First, when the general data storage module starts to execute a data write operation through the write interface of the non-volatile memory, it will switch the working state of the NVM from the change state to the write data state, indicating that the NVM has started to process the data write. Second, once the write operation is officially started, the MEMC will update the working state of the NVM to the waiting for completion state, at which time the NVM is waiting for the completion of the write operation. This state is used to monitor the write progress and ensure that all data is correctly written. Then, if the NVM remains in the waiting for completion state for a duration longer than the preset write duration, which may mean that the write operation takes longer to complete, the MEMC will change the working state of the NVM to the busy state to indicate that the NVM is busy completing the write task and prevent other operations from interfering with the ongoing write. Finally, the NVM will remain in the busy state until all the data to be stored is successfully written to the target storage space. After the write is completed, the MEMC will restore the working state of the NVM to the idle state, indicating that the NVM is ready to accept new write requests. This series of state transitions ensures the continuity and integrity of the data write process, while providing real-time monitoring of the write progress, guaranteeing data consistency and the reliability of NVM operations.

[0108] In this embodiment, the mask corresponding to the target storage space is set; the data to be stored is copied to the cache; and the data to be stored in the cache is written into the target storage space with the mask set. First, MEMC sets the mask corresponding to the target storage space. This step involves marking the data to be written in the mask bit array to facilitate the system to track and manage multiple data write requests, ensure the order and integrity of data writing, and reduce unnecessary access to the NVM. Then, the data to be stored is copied to the cache. This is done to reduce the number of direct writes to the NVM, use the high-speed characteristics of the RAM to temporarily store data, improve the data write efficiency, reduce NVM wear, extend its service life, and allow the system to continue processing other tasks when the NVM is busy, improving the system's responsiveness and throughput. Finally, the data in the cache is written into the target storage space with the mask set. This operation is performed after confirming that the NVM is idle, transferring the data from volatile storage to non-volatile storage to ensure data persistence, while allowing the system to process concurrent write requests, avoiding data conflicts, and improving the accuracy and efficiency of overall storage operations. These steps together ensure the efficiency, reliability of data storage and the overall performance of the system, while reducing NVM wear, extending its service life, and allowing the system to remain efficient and stable when processing data storage requests.

[0109] It should be noted that the above examples are only for understanding the present application and do not constitute a limitation to the general storage method of the present application based on the automotive open system architecture. Based on this technical concept, more forms of simple transformation are within the protection scope of the present application.

[0110] The present application also provides a general storage device based on the automotive open system architecture. Please refer to Figure 8 , the general storage device based on the automotive open system architecture includes:

[0111] A data acquisition module 10, configured to receive a data storage request and data to be stored;

[0112] A storage space determination module 20, configured to confirm the target storage space of the data to be stored according to the identifier of the data storage request;

[0113] A data storage module 30, configured to write the data to be stored into the target storage space with the mask set.

[0114] In an embodiment, the data storage module 30 is further configured to set the mask corresponding to the target storage space; copy the data to be stored to the cache; and write the data to be stored in the cache into the target storage space with the mask set.

[0115] In one embodiment, the data storage module 30 is further configured to obtain the working state of the non-volatile memory; when the working state is the idle state, switch the working state to the changing state through the writing interface of the non-volatile memory; when the working state is the changing state, write the data to be stored in the cache into the target storage space after the mask is set through the data block writing function.

[0116] In one embodiment, the data storage module 30 is further configured to switch the working state from the changing state to the data writing state; when the working state is the data writing state and the writing operation starts, switch the working state to the waiting for completion state; when the time that the non-volatile memory is in the waiting for completion state is greater than the preset writing duration, switch the working state to the busy state until all the data to be stored is written into the target storage space.

[0117] In one embodiment, the data storage module 30 is further configured to periodically detect the state of the mask of the target storage space through a periodic function; when the state of the mask is set, check the working state of the non-volatile memory; when the working state is the idle state, clear the bit of the mask through the writing interface of the non-volatile memory.

[0118] In one embodiment, when the data to be stored is diagnostic data, the data acquisition module 10 is further configured to configure a diagnostic identifier corresponding to the diagnostic data; after the configuration is completed, generate a service port corresponding to the diagnostic data through a preset configuration tool; connect to the service port through an operation trigger event access mode.

[0119] In one embodiment, the data acquisition module 10 is further configured to determine a data type, a data interaction frequency, and data interaction conditions according to the data to be stored; determine a data transmission direction, a data transmission rate, and a data identifier in a preset configuration tool according to the data type, the data interaction frequency, and the data interaction conditions; create a port instance, and allocate a communication signal to the port instance; allocate parameters to the port instance after the communication signal is allocated according to the data transmission direction, the data transmission rate, and the data identifier; map the port instance after the parameters are allocated to a communication channel to obtain a service port corresponding to the diagnostic data.

[0120] The general storage device based on the automotive open system architecture provided by this application adopts the general storage method based on the automotive open system architecture in the above embodiment, and can solve the technical problem of how to ensure data consistency when multiple users concurrently store data and avoid data conflicts. Compared with the prior art, the beneficial effects of the general storage device based on the automotive open system architecture provided by this application are the same as those of the general storage method based on the automotive open system architecture provided by the above embodiment, and other technical features in the general storage device based on the automotive open system architecture are the same as the features disclosed in the method of the above embodiment, which will not be elaborated here.

[0121] This application provides a general storage device based on the automotive open system architecture. The general storage device based on the automotive open system architecture includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the general storage method based on the automotive open system architecture in the first embodiment above.

[0122] Reference is made below to Figure 9 , which shows a schematic structural diagram of a general storage device suitable for implementing the embodiment of this application based on the automotive open system architecture. The general storage device based on the automotive open system architecture in the embodiment of this application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 9 The general storage device based on the automotive open system architecture shown is merely an example and should not impose any limitation on the functions and usage scope of the embodiment of this application.

[0123] As Figure 9As shown, the general storage device based on the automotive open system architecture may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which may perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the general storage device based on the automotive open system architecture are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 may allow the general storage device based on the automotive open system architecture to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a general storage device based on the automotive open system architecture having various systems, it should be understood that it is not required to implement or have all the shown systems. More or fewer systems may be implemented or had alternatively.

[0124] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above functions defined in the methods of the embodiments disclosed in the present application are executed.

[0125] The general storage device based on the automotive open system architecture provided by this application adopts the general storage method based on the automotive open system architecture in the above embodiment, and can solve the technical problem of how to ensure the consistency of data when multiple users concurrently store data and avoid data conflicts. Compared with the prior art, the beneficial effects of the general storage device based on the automotive open system architecture provided by this application are the same as those of the general storage method based on the automotive open system architecture provided by the above embodiment, and other technical features in the general storage device based on the automotive open system architecture are the same as those disclosed in the method of the previous embodiment, and will not be elaborated here.

[0126] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0127] As mentioned above, it is only the specific implementation manner of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed in this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claimed rights.

[0128] This application provides a computer-readable storage medium with computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the general storage method based on the automotive open system architecture in the above embodiment.

[0129] The computer-readable storage medium provided by the present application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or component. The program code contained on the computer-readable storage medium can be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0130] The above computer-readable storage medium can be included in a general storage device based on the automotive open system architecture; or it can exist independently without being assembled into a general storage device based on the automotive open system architecture.

[0131] The above computer-readable storage medium carries one or more programs. When the one or more programs are executed by a general storage device based on the automotive open system architecture, the general storage device based on the automotive open system architecture is caused to: receive a data storage request and data to be stored; confirm the target storage space for the data to be stored according to the identifier of the data storage request; and write the data to be stored into the target storage space after the mask is set.

[0132] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, by connecting through the Internet using an Internet service provider).

[0133] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, as well as the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0134] The modules described in the embodiments of this application can be implemented in software or in hardware. Among them, the name of the module does not constitute a limitation on the unit itself in some cases.

[0135] The readable storage medium provided by this application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for performing the above-mentioned general storage method based on the automotive open system architecture, and can solve the technical problems of how to ensure the consistency of data when multiple users concurrently store data and avoid data conflicts. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by this application are the same as those of the general storage method based on the automotive open system architecture provided in the above embodiments, and will not be elaborated here.

[0136] The present application further provides a computer program product, including a computer program which, when executed by a processor, implements the steps of the above-described general storage method based on the automotive open system architecture.

[0137] The computer program product provided by the present application can solve the technical problem of how to ensure data consistency when multiple users concurrently store data and avoid data conflicts. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the general storage method based on the automotive open system architecture provided in the above embodiments, and will not be elaborated herein.

[0138] The above are only some embodiments of the present application, and thus do not limit the patent scope of the present application. Any equivalent structural transformation made under the technical concept of the present application by using the content of the specification and drawings of the present application, or direct / indirect application in other related technical fields, is included in the patent protection scope of the present application.

Claims

1. A general storage method based on the automotive open system architecture, characterized in that, The method includes: Receiving a data storage request and data to be stored; Confirming a target storage space for the data to be stored according to an identifier of the data storage request; Writing the data to be stored into the target storage space after the mask is set.

2. The method according to claim 1, characterized in that, The step of writing the data to be stored into the target storage space after the mask is set includes: Setting the mask corresponding to the target storage space; Copying the data to be stored into a cache; Writing the data to be stored in the cache into the target storage space after the mask is set.

3. The method according to claim 2, characterized in that, The target storage space is located in a non-volatile memory; The step of writing the data to be stored in the cache into the target storage space after the mask is set includes: Obtaining an operating state of the non-volatile memory; When the operating state is an idle state, switching the operating state to a changing state through a write interface of the non-volatile memory; When the operating state is the changing state, writing the data to be stored in the cache into the target storage space after the mask is set through a data block writing function.

4. The method according to claim 3, wherein After the step of, when the operating state is the changing state, writing the data to be stored in the cache into the target storage space after the mask is set through a data block writing function, further includes: Switching the operating state from the changing state to a write data state; When the operating state is the write data state and a write operation starts, switching the operating state to a waiting for completion state; When a time for which the non-volatile memory is in the waiting for completion state is greater than a preset write duration, switching the operating state to a busy state until all the data to be stored is written into the target storage space.

5. The method according to claim 2, wherein The target storage space is located in a non-volatile memory; The step of setting the mask corresponding to the target storage space includes: Periodically detecting a state of a mask of the target storage space through a periodic function; When the state of the mask is set, checking an operating state of the non-volatile memory; When the operating state is an idle state, clearing bits of the mask through a write interface of the non-volatile memory.

6. The method according to claim 1, wherein Before the step of receiving a data storage request and data to be stored, further includes: When the data to be stored is diagnostic data, configuring a diagnostic identifier corresponding to the diagnostic data; After the configuration is completed, generating a service port corresponding to the diagnostic data through a preset configuration tool; Connecting to the service port through an operation trigger event access mode.

7. The method according to claim 6, wherein The step of generating a service port corresponding to the diagnostic data through a preset configuration tool includes: Determining a data type, a data interaction frequency, and a data interaction condition according to the data to be stored; Determining a data transmission direction, a data transmission rate, and a data identifier in the preset configuration tool according to the data type, the data interaction frequency, and the data interaction condition; Creating a port instance and allocating a communication signal to the port instance; Allocate parameters for the port instance after allocating the communication signal according to the data transmission direction, the data transmission rate, and the data identifier; Map the port instance after allocating the parameters onto a communication channel to obtain a service port corresponding to the diagnostic data.

8. A general storage device based on the automotive open system architecture, characterized in that, The device includes: A data acquisition module, configured to receive a data storage request and data to be stored; A storage space determination module, configured to confirm a target storage space for the data to be stored according to an identifier of the data storage request; A data storage module, configured to write the data to be stored into the target storage space after mask setting.

9. A general storage device based on the automotive open system architecture, characterized in that, The device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the general storage method based on the automotive open system architecture according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the general storage method based on the automotive open system architecture according to any one of claims 1 to 7 are implemented.

Images