Data processing method and device, computer equipment and storage medium

Abstract

The invention discloses a data processing method and device, computer equipment and a storage medium, and belongs to the field of vehicle IMU software development, and the method comprises the steps: obtaining an original data flow of an IMU sensor of a vehicle based on an MCAL layer; based on the running environment, acquiring auxiliary motion state information of application layer software of the vehicle; determining whether the vehicle is in a stationary state based on the original data stream and the auxiliary motion state information; in response to the vehicle being in a stationary state, determining a zero offset compensation value, and storing the zero offset compensation value in a non-volatile memory based on a non-volatile memory manager; based on a communication interface of an ECU abstraction layer, packaging an original data stream into a standardized data format; based on a storage interface of an ECU abstraction layer, managing reading and writing of a zero offset compensation value; and interacting with a runtime environment and providing standardized service for an application layer. According to the invention, the development of the IMU has higher standardization, portability and measurement precision, the maintenance burden of an engineer is not increased, and the operation efficiency of the system is not influenced.

Description

Technical Field

[0001] This application relates to a data processing method, apparatus, computer equipment, and storage medium, belonging to the field of vehicle IMU software development technology. Background Technology

[0002] Inertial measurement units (IMUs) are core components in attitude sensing, playing a crucial role in motion state measurement due to their high precision, high update rate, and strong robustness. A typical IMU consists of a three-axis accelerometer, a three-axis gyroscope, and an application-specific integrated circuit (ASIC) signal processing chip. Its system interaction with a microcontroller is illustrated in the diagram below. Figure 1 .

[0003] In this system, the microcontroller unit (MCU) acts as the main controller, establishing a physical connection with the IMU and exchanging data via a standard serial communication interface. The MCU configures the IMU's parameters and initializes its mode through this link, and periodically reads its raw motion data output. Simultaneously, the MCU monitors the IMU's alarm status in real time through general-purpose input / output pins. When an internal fault occurs in the IMU, it will report it to the MCU via an interrupt or a level signal, thereby achieving operational status monitoring and fault diagnosis.

[0004] However, given the complex automotive electronic and electrical architecture and increasingly stringent functional safety requirements, the traditional bare-metal or real-time operating system approach for IMU driver development has the following shortcomings: 1. Inconsistent coding style and lack of unified architectural standards; 2. High degree of coupling between hardware and software, and low degree of modularity; 3. Even when stationary, the accelerometer and gyroscope in the IMU will still output a non-zero fixed bias, i.e., zero bias, which will directly contaminate all subsequent measurement data.

[0005] To address the above issues, the industry's standard technical solutions are as follows: Regarding architectural standardization issues: This is usually addressed by establishing internal coding standards, unifying naming rules, file organization, and function interfaces, and supplementing this with a code review mechanism, with the project leader regularly checking and urging rectification.

[0006] To address the issue of hardware-software coupling, a hardware abstraction layer (HAL) is typically introduced into the driver to encapsulate low-level register operations into a unified interface, decoupling the core driver from the hardware. Simultaneously, hardware-related parameters are centrally managed in a separate configuration file using macro definitions. When changing the MCU platform, only the HAL layer and configuration file need to be adapted; the core driver code remains unchanged.

[0007] To address the zero-bias issue: A zero-bias acquisition and compensation mechanism is typically implemented in the IMU driver. During system initialization or when the vehicle is stationary, multiple sets of data are continuously acquired, and their average value is calculated as the zero-bias value, stored in random access memory or electrically erasable programmable read-only memory (RAM or EEPROM). During normal operation, this zero-bias value is subtracted from the real-time raw data to obtain the compensated effective data. The process is as follows: Figure 2 As shown.

[0008] While the above solutions can address some of the challenges of traditional development models, they still present numerous problems in practical engineering applications. 1. Due to differences between developers and projects, architectural specifications are difficult to unify, and interface definitions and file organization are arbitrary, resulting in poor code reuse and portability across projects; 2. The hardware abstraction level is inconsistent, the parameter configuration management is scattered, the driver reusability is still not ideal when the MCU is replaced, and the boundary between the driver and the application module is blurred; 3. The zero-bias compensation mechanism is imperfect: the determination of the static state is inaccurate; if the compensation value is stored in EEPROM, it may lead to large data errors and low reliability due to improper writing timing, insufficient power-off protection or lack of verification mechanism; the overall solution has deficiencies in terms of functional safety compliance. Summary of the Invention

[0009] In view of this, this application provides a data processing method, apparatus, computer equipment, and storage medium. The embodiments of this application enable IMU development to have higher standardization, portability, and measurement accuracy, without increasing the maintenance burden on engineers or affecting the system's operating efficiency.

[0010] The first aspect of this application discloses a data processing method, the method comprising: acquiring raw data streams from the IMU sensors of a target vehicle based on the MCAL layer of the AUTOSAR architecture, wherein the raw data streams are transmitted to the ECU abstraction layer through a standardized interface; acquiring auxiliary motion state information of at least one application layer software component of the target vehicle based on the runtime environment of the AUTOSAR architecture; collaboratively determining whether the target vehicle is stationary based on the raw data streams and the auxiliary motion state information; determining a zero-bias compensation value in response to the target vehicle being stationary, and storing the zero-bias compensation value in a non-volatile memory based on an AUTOSAR non-volatile memory manager; encapsulating the raw data streams into a standardized data format and transmitting it to the runtime environment based on the communication interface of the ECU abstraction layer; managing the reading and writing of the zero-bias compensation value based on the storage interface of the ECU abstraction layer; and providing standardized IMU data access and status query services for the application layer software components by interacting with the runtime environment through an AUTOSAR Interface.

[0011] In some embodiments, the MCAL layer based on the AUTOSAR architecture acquires the raw data stream of the IMU sensor of the target vehicle by: establishing a physical connection with the IMU sensor and interacting with data frames by configuring the SPI driver, I2C driver or UART driver of the MCAL layer; monitoring the alarm pin status of the IMU sensor by configuring the DIO driver of the MCAL layer; and acquiring the analog signal output by the IMU sensor by configuring the ADC driver of the MCAL layer.

[0012] In some embodiments, the AUTOSAR-based non-volatile memory manager stores the zero-bias compensation value in the non-volatile memory, including: generating a cyclic redundancy check (CRC) code for the zero-bias compensation value; and writing the zero-bias compensation value with the CRC code appended to it into different physical storage areas of the non-volatile memory in at least two copies.

[0013] In some embodiments, the raw data stream includes triaxial acceleration and triaxial angular velocity data, and the auxiliary motion state information includes vehicle speed signal and wheel speed signal. The collaborative determination of whether the target vehicle is stationary based on the raw data stream and the auxiliary motion state information includes: when the vehicle speed signal and wheel speed signal both continuously indicate zero values ​​within a first time window, and the statistical fluctuation of the triaxial acceleration and triaxial angular velocity data within a second time window is lower than a preset threshold, the target vehicle is determined to be stationary. The duration of the first time window is greater than the duration of the second time window.

[0014] In some embodiments, the communication interface is a unified service interface that abstracts the operations of various underlying drivers. The standardized interface is configured by the configuration tool of the MCAL layer, and the storage interface is the standardized interface of the MemIf module.

[0015] In some embodiments, the application layer software components access data through a predefined AUTOSAR Interface.

[0016] In some embodiments, the method further includes: compensating the real-time acquired raw data stream based on the zero-bias compensation value to obtain compensated data.

[0017] A second aspect of this application discloses a data processing apparatus, comprising: a first acquisition module for acquiring raw data streams from the IMU sensors of a target vehicle based on the MCAL layer of the AUTOSAR architecture; a second acquisition module for acquiring auxiliary motion state information of at least one application layer software component of the target vehicle based on the runtime environment of the AUTOSAR architecture; a determination module for collaboratively determining whether the target vehicle is stationary based on the raw data streams and the auxiliary motion state information; a storage module for determining a zero-bias compensation value in response to the target vehicle being stationary, and storing the zero-bias compensation value in a non-volatile memory based on an AUTOSAR non-volatile memory manager; an encapsulation module for encapsulating the raw data streams into a standardized data format and transmitting it to the runtime environment based on the communication interface of the ECU abstraction layer; a configuration module for managing the reading and writing of the zero-bias compensation value based on the storage interface of the ECU abstraction layer; and an interaction module for interacting with the runtime environment through an AUTOSAR Interface to provide standardized IMU data access and status query services for the application layer software components.

[0018] A third aspect of this application discloses a computer-readable storage medium comprising a stored program, wherein the program, when running, controls the execution of the data processing method of the above embodiments in a processor of the device.

[0019] A fourth aspect of this application discloses a computer device, the computer device including a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed by the data processing method of the above embodiments.

[0020] Compared with the prior art, the embodiments of this application have the following beneficial effects: 1. This application embodiment utilizes the combination of IMU complex device driver (CDD) under the AUTOSAR architecture and a standardized toolchain to replace the traditional bare-metal / RTOS handwritten IMU driver development method, so as to achieve the purpose of uniform IMU driver code style and eliminate the differences in architecture caused by different people; 2. This application embodiment utilizes the MCAL hardware abstraction layer under the AUTOSAR architecture and tool configuration (MCAL layer configuration tools, such as EB) to replace the traditional bare-metal / RTOS direct register operation IMU development method, thereby achieving the goal of complete decoupling of IMU software and hardware and significantly improving the degree of modularity; 3. The embodiments of this application utilize multi-source information fusion and system-level zero-bias compensation mechanism under the AUTOSAR architecture to replace the traditional bare-metal / RTOS single-point algorithm for processing IMU data, thereby achieving more accurate IMU static state detection and more effective zero-bias error suppression; 4. This application embodiment utilizes the combination mechanism of RTE multi-source information fusion and NvM non-volatile memory management under the AUTOSAR architecture to replace the traditional bare metal / RTOS manual method of zero-bias acquisition and storage of IMU, so as to achieve more accurate identification of IMU static state and zero-bias data is not lost when power is off; 5. The collaborative determination method of this application significantly improves the reliability, accuracy, and real-time performance of vehicle stationary state detection by constructing a heterogeneous signal hierarchical verification mechanism. Specifically, the method uses the vehicle's inherent vehicle speed and wheel speed signals as the primary decision criterion, requiring the signals to remain zero for a relatively long time window to achieve macroscopic steady-state confirmation against signal jitter and environmental interference. Simultaneously, it uses raw data from the high-refresh-rate inertial measurement unit as the secondary decision criterion, analyzing the statistical fluctuations of triaxial acceleration and triaxial angular velocity within a short time window to achieve microscopic dynamic perception against sensor bias and high-frequency noise. The two-level decision conditions are coordinated using logical AND relations, ensuring that the system only ultimately determines that the vehicle is stationary when both macroscopic steady-state and microscopic static conditions are simultaneously met. Compared with single-signal decision schemes, this collaborative determination mechanism effectively overcomes the problems of misjudgment and missed judgment caused by signal failure, noise interference, or environmental vibration in traditional methods. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0022] Figure 1 This is an interaction diagram between an IMU and an MCU.

[0023] Figure 2 This is a flowchart of a zero-bias compensation method.

[0024] Figure 3 This is a flowchart of a data processing method provided in an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] Example 1: like Figure 3 As shown, Figure 3 A flowchart illustrating a data processing method provided in an embodiment of this application. The data processing method includes the following steps: S101 uses the MCAL layer of the AUTOSAR architecture to acquire the raw data stream from the IMU sensors of the target vehicle.

[0028] In some embodiments, the MCAL layer based on the AUTOSAR architecture acquires the raw data stream from the IMU sensor of the target vehicle, including: establishing a physical connection with the IMU sensor and exchanging data frames by configuring the MCAL layer's SPI driver, I2C driver, or UART driver; monitoring the alarm pin status of the IMU sensor by configuring the MCAL layer's DIO driver; and acquiring the analog signal output by the IMU sensor by configuring the MCAL layer's ADC driver. This information is transmitted to the upper ECU Abstraction layer (i.e., the ECU abstraction layer) through a standardized interface.

[0029] In this embodiment, the standardized interface is implemented through the MCAL configuration tool EB. For example, the PWM signal control function Pwm_SetDutyCycle(Pwm_ChannelType Channel, Pwm_DutyCycleType DutyCycle) sets the duty cycle of a specified PWM channel; the interface is unified across different chips, but the internal implementation logic differs.

[0030] It should be noted that this embodiment is based on the ECU software layered model of the classic AUTOSAR architecture, and designs the data interaction and synchronization logic of the IMU from the hardware to the application layer. By adopting this architecture, the IMU function is implemented as a complex device driver that conforms to the AUTOSAR specification. Its interface definition, file organization and configuration methods all follow a unified standard, thereby ensuring that the code has good readability, maintainability and reusability at the architectural level.

[0031] As an optional implementation, this embodiment configures the relevant drivers for the MCU through the MCAL development tool EB.

[0032] For example, the serial communication (SPI / I²C / UART) between the IMU and the MCU is directly driven by the Communication Driver in the MCAL layer. This driver encapsulates the read and write operations of the MCU's communication peripheral registers, enabling the transmission and reception of data frames. The Communication Driver provides services to the upper-layer ECU Abstraction layer through a standardized interface, thereby shielding the hardware differences between different communication peripherals. The IMU's alarm signals and status pins are connected to the MCU's GPIO ports, and the level reading is handled by the DIO Driver in the MCAL layer: when the IMU alarm pin level changes, the upper layer can be notified of the fault handling through the DIO pin status. Some analog states of the IMU (such as temperature, acceleration, and angular velocity) need to be acquired through an ADC. The ADC Driver in the MCAL layer performs the analog-to-digital conversion and transmits the sampling results to the upper layer for threshold judgment. Both the DIO Driver and the ADC Driver provide services to the ECU Abstraction layer through a standardized interface, enabling hardware-independent I / O and analog signal acquisition operations.

[0033] S102, based on the runtime environment (RTE) of the AUTOSAR architecture, obtains the auxiliary motion state information of at least one application layer software component of the target vehicle.

[0034] S103 makes a collaborative determination on whether the target vehicle is stationary based on the original data stream and the auxiliary motion state information.

[0035] In some embodiments, the raw data stream includes triaxial acceleration and triaxial angular velocity data, and the auxiliary motion state information includes vehicle speed signal and wheel speed signal. The collaborative determination of whether the target vehicle is stationary based on the raw data stream and the auxiliary motion state information includes: when the vehicle speed signal and wheel speed signal both continuously indicate zero values ​​within a first time window, and the statistical fluctuation of the triaxial acceleration and triaxial angular velocity data within a second time window is lower than a preset threshold, the target vehicle is determined to be stationary. The duration of the first time window is greater than the duration of the second time window.

[0036] In other embodiments, the raw data stream includes triaxial acceleration and triaxial angular velocity data, and the auxiliary motion state information includes vehicle speed signal and wheel speed signal. The collaborative determination of whether the target vehicle is stationary based on the raw data stream and the auxiliary motion state information includes: when the vehicle speed signal and wheel speed signal both continuously indicate zero values ​​within a first time window, and the statistical fluctuation of the triaxial acceleration and triaxial angular velocity data within a second time window is lower than a preset threshold, the target vehicle is determined to be stationary. The duration of the first time window is equal to the duration of the second time window.

[0037] It is worth noting that acquiring multi-source information such as vehicle speed and wheel speed through RTE is the core means to achieve high-precision stationary detection under the AUTOSAR architecture. It upgrades the IMU from blind guessing with a single sensor to vehicle-level state perception, providing a clean data source for zero-bias acquisition.

[0038] S104 responds to the target vehicle being in the stationary state by determining the zero bias compensation value and storing the zero bias compensation value in non-volatile memory based on the AUTOSAR non-volatile memory manager.

[0039] In some embodiments, the AUTOSAR-based non-volatile memory manager stores the bias compensation value in non-volatile memory, including: generating a cyclic redundancy check (CRC) code for the bias compensation value; and writing the bias compensation value with the CRC code appended to it into different physical storage areas of the non-volatile memory in at least two copies. The CRC code needs to be verified before processing the bias compensation value from the non-volatile memory.

[0040] For example, to ensure the reliability of IMU data, the MCU can store key configuration parameters, zero-bias compensation values, fault logs, and historical motion data in non-volatile memory (such as Flash or EEPROM). This operation is performed by the Memory Driver in the MCAL layer. The Memory Driver encapsulates the erase and read / write operations of the memory and provides data persistence services to the upper-layer Memory Services through a standardized interface, ensuring that IMU configuration and fault data are not lost after power failure.

[0041] S105 encapsulates the raw data stream into a standardized data format based on the communication interface of the ECU abstraction layer.

[0042] Specifically, based on the communication interfaces (CAN interface, SPI interface) of the ECU Abstraction layer, protocol parsing, frame verification and data distribution of IMU data are realized, and the raw motion data is encapsulated into a standardized data format and then transmitted to the RTE.

[0043] In some embodiments, the standardized data format (uniform format) encapsulation is implemented by hand-written code. For example, the acceleration GyroData_Internal.x / y / z is transmitted via RTE, which is obtained by multiplying the internal raw data by the gain and adding the bias. Then, the data Rte_Write_IMU_AccelPort_AccelData(GyroData_Internal) is sent via the RTE standardized API.

[0044] In some embodiments, the communication interface abstracts the operations of various low-level drivers into a unified service interface. The ECU Abstraction layer further encapsulates the MCAL Driver, providing a hardware-independent ECU-level interface: it abstracts the operations of the Communication Driver, DIO Driver, ADC Driver, and Memory Driver into a unified service interface, so that upper-layer services do not need to care about the specific hardware peripheral models.

[0045] It should be noted that the abstraction of the operations of various underlying drivers is the driver abstraction at the MCAL level. The interface is unified, which is a specific example of the standardization of the interface at the MCAL level. Using this method, the code has high reusability and strong portability.

[0046] S106 manages the reading and writing of the zero-bias compensation value based on the storage interface of the ECU abstraction layer.

[0047] Specifically, based on the storage interface of the ECU Abstraction layer, services such as reading and writing IMU configuration parameters, zero-bias compensation values, and fault log management are provided to ensure data consistency and traceability.

[0048] In some embodiments, the storage interface is a standardized interface of the MemIf module. MemIf (Memory Abstraction Interface) is located at the top of the ECU abstraction layer and is the interface layer directly called by the upper-layer NvM. Its core function is to provide a unified API for abstracting the differences between the underlying Fee and Ea modules, so that the upper-layer NvM does not need to care whether the data is stored in Flash or EEPROM, and supports multi-device management (it can manage multiple storage devices simultaneously).

[0049] In some embodiments, the method further includes: compensating the real-time acquired raw data stream based on the zero-bias compensation value to obtain compensated data.

[0050] S107 interacts with the runtime environment through the AUTOSAR Interface to provide standardized IMU data access and status query services for the application layer software components.

[0051] Specifically, the service layer interacts with the RTE through a predefined AUTOSAR Interface to provide standardized IMU data access and status query services to the application layer SWC. The RTE, acting as middleware, routes the IMU data and status information provided by the service layer to various application layer software components. The application layer SWC only needs to access data through the predefined AUTOSAR Interface, without needing to understand the underlying hardware drivers or communication protocol details, thus achieving hardware-software decoupling and functional modularity.

[0052] It is worth noting that the key features of this invention lie in its clear hierarchical architecture, standardized interfaces, and coordinated cooperation among layers. Specifically, it employs MCAL (Microcontroller Abstraction Layer), ECU Abstraction Layer, and System Service Layer. When changing hardware platforms, because MCAL is closely related to the chip, this layer needs to be adapted; however, thanks to its standardized interface functions, the business logic of the ECU Abstraction Layer can remain unchanged, continuing to use the original interface.

[0053] Example 2: Embodiments of this application also provide a data processing apparatus, comprising: a first acquisition module, configured to acquire raw data streams from the IMU sensors of a target vehicle based on the MCAL layer of the AUTOSAR architecture; a second acquisition module, configured to acquire auxiliary motion state information of at least one application layer software component of the target vehicle based on the runtime environment of the AUTOSAR architecture; a determination module, configured to collaboratively determine whether the target vehicle is stationary based on the raw data streams and the auxiliary motion state information; a storage module, configured to determine a zero-bias compensation value in response to the target vehicle being stationary, and store the zero-bias compensation value in a non-volatile memory based on an AUTOSAR non-volatile memory manager; an encapsulation module, configured to encapsulate the raw data streams into a standardized data format based on the communication interface of the ECU abstraction layer; a configuration module, configured to manage the reading and writing of the zero-bias compensation value based on the storage interface of the ECU abstraction layer; and an interaction module, configured to interact with the runtime environment through an AUTOSAR Interface to provide standardized IMU data access and status query services for the application layer software components.

[0054] In some embodiments, the MCAL layer based on the AUTOSAR architecture acquires the raw data stream of the IMU sensor of the target vehicle by: establishing a physical connection with the IMU sensor and interacting with data frames by configuring the SPI driver, I2C driver or UART driver of the MCAL layer; monitoring the alarm pin status of the IMU sensor by configuring the DIO driver of the MCAL layer; and acquiring the analog signal output by the IMU sensor by configuring the ADC driver of the MCAL layer; wherein the raw data stream is transmitted to the ECU abstraction layer through a standardized interface.

[0055] In some embodiments, the AUTOSAR-based non-volatile memory manager stores the zero-bias compensation value in the non-volatile memory, including: generating a cyclic redundancy check (CRC) code for the zero-bias compensation value; and writing the zero-bias compensation value with the CRC code appended to it into different physical storage areas of the non-volatile memory in at least two copies.

[0056] In some embodiments, the raw data stream includes triaxial acceleration and triaxial angular velocity data, and the auxiliary motion state information includes vehicle speed signal and wheel speed signal. The collaborative determination of whether the target vehicle is stationary based on the raw data stream and the auxiliary motion state information includes: when the vehicle speed signal and wheel speed signal both continuously indicate zero values ​​within a first time window, and the statistical fluctuation of the triaxial acceleration and triaxial angular velocity data within a second time window is lower than a preset threshold, the target vehicle is determined to be stationary. The duration of the first time window is greater than the duration of the second time window.

[0057] In some embodiments, the communication interface is a unified service interface that abstracts the operations of various underlying drivers.

[0058] In some embodiments, the application layer software components access data through a predefined AUTOSAR Interface.

[0059] In some embodiments, the method further includes: compensating the real-time acquired raw data stream based on the zero-bias compensation value to obtain compensated data.

[0060] Example 3: Embodiments of this application also provide a computer device, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of the present invention during runtime.

[0061] The aforementioned memory can refer to devices inside a computer used to store data and programs, including RAM, hard disks, etc. RAM can be used to temporarily store running programs and data, while hard disks can be used to store programs and data long-term. Memory enables the computer to read and write data and execute programs. The aforementioned processor is responsible for executing instructions in computer programs and performing data processing. It can also be responsible for controlling and executing various operations, including arithmetic operations, logical operations, and data transmission.

[0062] Example 4: Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of the present invention.

[0063] The aforementioned computer storage media can refer to the media used in computer memory to store certain discontinuous physical quantities. Computer storage media mainly include semiconductors, magnetic cores, magnetic drums, magnetic tapes, laser discs, etc. Computer-readable storage media include stored programs, which can be a set of instructions that a computer can recognize and execute, running on an electronic computer to meet certain information needs.

[0064] Example 5: Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of the present invention.

[0065] The aforementioned computer program products can refer to software programs that have been written, tested, and released, and can run on computers or other devices. Computer program products can include application programs, operating systems, utility software, etc., used to achieve specific functions or solve specific problems.

[0066] Example 6: Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of the present invention.

[0067] The aforementioned non-volatile computer-readable storage medium can refer to a medium for storing data. Non-volatile computer-readable storage media can retain data without loss when power is off and can be used to store long-term data, such as operating systems, applications, and user files. Non-volatile storage media can include hard disk drives, solid-state drives, optical disks, and flash memory storage devices, etc.

[0068] Example 7: Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of the present invention.

[0069] The aforementioned computer program can refer to a set of instructions used to tell the computer to perform specific tasks or operations. Computer programs can be written by programmers using specific programming languages ​​and can include algorithms, data structures, logic, and control flow. Computer programs can be used for a variety of purposes, including application software, operating systems, etc.

[0070] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0071] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0072] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0073] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0074] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0075] In summary, 1. This invention adopts an IMU development method that combines complex drivers under the AUTOSAR architecture with a standardized toolchain. Compared with the traditional bare-metal / RTOS handwritten driver method, it achieves a unified code style and eliminates the differences in architecture design due to individual differences. 2. This invention adopts a method that combines the MCAL hardware abstraction layer under the AUTOSAR architecture with tool configuration. Compared with the traditional bare-metal / RTOS method of directly manipulating registers, it achieves complete decoupling of software and hardware and significantly improves the degree of modularity. 3. The present invention adopts a multi-source information fusion static detection method under the AUTOSAR architecture. Compared with the traditional bare metal / RTOS judgment method that only relies on IMU data, it significantly improves the accuracy of static state recognition and effectively avoids problems such as slope static being misjudged as moving and vibration interference being misjudged as static. 4. This invention adopts the NvM non-volatile memory management method under the AUTOSAR architecture. Compared with the traditional bare metal / RTOS manual EEPROM reading and writing method, it integrates CRC check and dual backup mechanism for zero bias storage, realizes that data is not lost when power is off and can be recovered after damage, and solves the problems caused by improper writing timing, lack of lifetime management and inability to detect data damage in manual implementation. 5. The collaborative determination method of this invention significantly improves the reliability, accuracy, and real-time performance of vehicle stationary state detection by constructing a heterogeneous signal hierarchical verification mechanism. Specifically, this method uses the vehicle's inherent vehicle speed and wheel speed signals as the primary decision criterion, requiring the signals to remain zero for a relatively long time window to achieve macroscopic steady-state confirmation against signal jitter and environmental interference. Simultaneously, it uses raw data from the high-refresh-rate inertial measurement unit as the secondary decision criterion, analyzing the statistical fluctuations of triaxial acceleration and triaxial angular velocity within a shorter time window to achieve microscopic dynamic perception against sensor bias and high-frequency noise. The two-level decision conditions are coordinated using logical AND relations, ensuring that the system only ultimately determines that the vehicle is stationary when both macroscopic steady-state and microscopic static conditions are simultaneously met. Compared with single-signal decision schemes, this collaborative determination mechanism effectively overcomes the problems of misjudgment and missed judgment caused by signal failure, noise interference, or environmental vibration in traditional methods.

[0076] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A data processing method, characterized in that, include: The MCAL layer based on the AUTOSAR architecture acquires the raw data stream from the IMU sensor of the target vehicle, and the raw data stream is transmitted to the ECU abstraction layer through a standardized interface. Based on the runtime environment of the AUTOSAR architecture, obtain the auxiliary motion state information of at least one application layer software component of the target vehicle. Based on the original data stream and the auxiliary motion state information, a collaborative determination is made as to whether the target vehicle is stationary. In response to the target vehicle being in the stationary state, a zero-bias compensation value is determined, and the zero-bias compensation value is stored in non-volatile memory based on the AUTOSAR non-volatile memory manager. Based on the communication interface of the ECU abstraction layer, the raw data stream is encapsulated into a standardized data format and transmitted to the runtime environment; The storage interface based on the ECU abstraction layer manages the reading and writing of the zero bias compensation value; By interacting with the runtime environment through the AUTOSAR Interface, standardized IMU data access and status query services are provided for the application layer software components.

2. The data processing method according to claim 1, characterized in that, The MCAL layer based on the AUTOSAR architecture acquires the raw data stream from the target vehicle's IMU sensors, including: By configuring the SPI driver, I2C driver, or UART driver of the MCAL layer, a physical connection is established with the IMU sensor and data frame interaction is performed. The alarm pin status of the IMU sensor is monitored by configuring the DIO driver of the MCAL layer; The analog signal output by the IMU sensor is acquired by configuring the ADC driver of the MCAL layer.

3. The data processing method according to claim 1, characterized in that, The AUTOSAR-based non-volatile memory manager stores the zero-bias compensation value in non-volatile memory, including: Generate a cyclic redundancy check code for the zero-bias compensation value; The zero-bias compensation value, with the cyclic redundancy check code appended, is written to different physical storage areas of the non-volatile memory in at least two copies.

4. The data processing method according to claim 1, characterized in that, The raw data stream includes triaxial acceleration and triaxial angular velocity data, and the auxiliary motion state information includes vehicle speed and wheel speed signals. The collaborative determination of whether the target vehicle is stationary based on the raw data stream and the auxiliary motion state information includes: When the vehicle speed signal and wheel speed signal both continuously indicate zero values ​​within the first time window, and the statistical fluctuation of the triaxial acceleration and triaxial angular velocity data within the second time window is lower than a preset threshold, the target vehicle is determined to be in the stationary state, and the length of the first time window is greater than the length of the second time window.

5. The data processing method according to any one of claims 1 to 4, characterized in that, The communication interface abstracts the operations of various underlying drivers into a unified service interface. The standardized interface is configured by the configuration tool of the MCAL layer, and the storage interface is the standardized interface of the MemIf module.

6. The data processing method according to any one of claims 1 to 4, characterized in that, The application layer software components access data through a predefined AUTOSAR Interface.

7. The data processing method according to any one of claims 1 to 4, characterized in that, Also includes: Based on the zero-bias compensation value, the original data stream acquired in real time is compensated to obtain compensated data.

8. A data processing apparatus, characterized in that, include: The first acquisition module is used to acquire the raw data stream from the IMU sensor of the target vehicle based on the MCAL layer of the AUTOSAR architecture. The second acquisition module is used to acquire the auxiliary motion state information of at least one application layer software component of the target vehicle based on the runtime environment of the AUTOSAR architecture. The determination module is used to collaboratively determine whether the target vehicle is stationary based on the original data stream and the auxiliary motion state information. A storage module is configured to determine a zero-bias compensation value in response to the target vehicle being in the stationary state, and store the zero-bias compensation value in a non-volatile memory based on an AUTOSAR non-volatile memory manager. An encapsulation module is used to encapsulate the raw data stream into a standardized data format and transmit it to the runtime environment based on the communication interface of the ECU abstraction layer. The configuration module is used to manage the reading and writing of the zero-bias compensation value based on the storage interface of the ECU abstraction layer; The interaction module is used to interact with the runtime environment through the AUTOSAR Interface to provide standardized IMU data access and status query services for the application layer software components.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the data processing method as described in any one of claims 1 to 7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the data processing method as described in any one of claims 1 to 7.

Images