GNSS data backup and playback method and system based on SOME IP, and electronic equipment
By adding a GNSS Service to the IVI's Android system and adopting a dual-buffer caching and multi-threaded mode, the problem of high difficulty in indoor testing of GNSS satellite positioning systems was solved, GNSS data backup and playback were realized, development costs were reduced, and data sources were expanded.
Patent Information
- Application Number
- CN202511846218.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-09
- Publication Date
- 2026-03-17
AI Technical Summary
GNSS satellite positioning systems are basically unable to receive data indoors, which makes indoor testing difficult and costly. Existing testing methods are not suitable for systematic testing and are also costly.
In the Android system architecture of IVI, a GNSS Service is added. The function switch is set through the factory pattern to control the writing or reading of data. A dual-buffer caching mechanism and a multi-threaded producer-consumer pattern are adopted to realize the backup and playback of GNSS data, and USB flash drive storage and cloud data source are used.
It enables GNSS data simulation testing, reduces development costs, expands data sources, supports bench testing and problem reproduction, and directly simulates GNSS data for use by all applications.
Smart Images

Figure CN121680735A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data transmission, and in particular to a GNSS data backup and playback method based on SOME IP, a GNSS data backup and playback system based on SOME IP, electronic devices, storage media, and vehicle cockpits. Background Technology
[0002] Currently, the GNSS data for vehicle systems comes from the counterpart TBOX. The SOA (Service-Oriented Architecture) service of the in-vehicle infotainment system forwards GNSS signals based on the SOME IP protocol. The IVI connects the GNSS data to the Android platform through the service and provides the GNSS data to the required applications through the native interface of the Android platform.
[0003] GNSS satellite positioning systems are basically unable to receive data indoors and can only be tested outdoors dynamically, which results in high development costs. Therefore, if testing can be conducted using simulated data, the development difficulty and cost of positioning-related functions will be greatly reduced.
[0004] Limitations: There are two main methods for GNSS simulation data testing. One is for the navigation application to access the test data itself for testing. This method can only test the navigation application and cannot perform systematic testing. The second method is to test using external GNSS equipment. This requires purchasing the equipment and conducting on-road testing with actual vehicles, which is also costly.
[0005] Therefore, a GNSS data backup and playback solution based on SOME IP is needed to solve the problem that GNSS satellite positioning systems can hardly receive data indoors. Summary of the Invention
[0006] The purpose of this invention is to provide a GNSS data backup and playback method based on SOME IP, a GNSS data backup and playback system based on SOME IP, an electronic device, a storage medium, and a vehicle cockpit, thereby solving at least one of a number of technical problems.
[0007] For example, GNSS satellite positioning systems are basically unable to receive data indoors.
[0008] This invention provides the following solution:
[0009] According to a first aspect of the present invention, a method for GNSS data backup and playback based on SOME IP is provided, comprising:
[0010] Based on the IVI-based Android system architecture, a GNSS Service is added.
[0011] The GNSS Service establishes data interaction with the vehicle-mounted telematics terminal (TBox) and the GNSS hardware abstraction layer (HAL).
[0012] Among them, a function switch is set through the factory mode to control the GNSS Service to perform data write or data read operations;
[0013] When data is written, the GNSS Service subscribes to the TBox's GNSS events and receives the data, storing it to the USB drive;
[0014] When data is read, the GNSS Service stops subscribing to the TBox's GNSS events, reads data from the USB drive and transmits it to the GNSS HAL, which then provides it to the upper-layer application via the LocationManagerService in the JNI layer and the Framework layer.
[0015] Furthermore, including:
[0016] A dual-buffer caching mechanism is used when writing data;
[0017] The dual-buffer caching mechanism involves the system creating two data buffers, buffer one and buffer two.
[0018] Buffer 1 caches the data of received GNSS events in real time. When the data reaches the specified size, the contents of Buffer 1 are copied to Buffer 2 and Buffer 1 is cleared. The data in Buffer 2 is synchronously written to the USB flash drive.
[0019] Furthermore, including:
[0020] Data reading employs a multi-threaded producer-consumer pattern.
[0021] The multi-threaded producer-consumer pattern includes reading data from the USB drive through a first independent thread, parsing the read data through a second independent thread, and then passing the parsed data to the GNSS HAL in a loop.
[0022] Furthermore, it also includes:
[0023] Retrieve GNSS data uploaded by TBox;
[0024] The data is deployed to the IVI, read by the GNSS Service, and transmitted to the GNSS HAL for playback.
[0025] Furthermore, including:
[0026] During data reading, the data from the USB drive is read in a loop according to the GNSS data output frequency to achieve data loop playback.
[0027] According to a second aspect of the present invention, a GNSS data backup and playback system based on SOME IP is provided, comprising:
[0028] Upper-layer application module, factory mode control module, TBox module;
[0029] Based on the IVI-based Android system architecture, GNSS HAL serves as the core middleware layer connecting the underlying hardware capabilities with the upper-layer applications.
[0030] Among them, a GNSS Service module has been added for data interaction between the TBox module and the GNSS HAL;
[0031] The factory mode control module provides a function switch to select the data writing or data reading mode;
[0032] It also includes a data storage module, used to store the received TBox module data to a USB flash drive via GNSS Service;
[0033] The data playback module is used to read data from the USB flash drive via GNSS Service and transmit it to GNSS HAL for use by upper-layer application modules.
[0034] Furthermore, including:
[0035] The GNSS Service module transmits the parsed GNSS data to the upper-layer architecture by calling the iccGnssLocationCb interface of GNSS HAL.
[0036] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;
[0037] The memory stores a computer program that, when executed by the processor, causes the processor to perform steps such as the GNSS data backup and playback method based on SOME IP.
[0038] According to a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform steps such as the GNSS data backup and playback method based on SOME IP.
[0039] According to a fifth aspect of the present invention, a vehicle cabin is provided, comprising:
[0040] Electronic equipment used to implement steps such as GNSS data backup and playback methods based on SOME IP;
[0041] The processor runs a program that, when running, executes steps such as the SOMEIP-based GNSS data backup and playback method based on data output from the electronic device.
[0042] Storage medium used to store programs that, when running, perform steps such as the SOME IP-based GNSS data backup and playback method on data output from electronic devices.
[0043] The above solution achieves the following beneficial technical effects:
[0044] This application can directly simulate Tbox sending navigation data to GNSS HAL by performing data playback at the IVI system layer. The simulated GNSS data is directly provided to all applications that need to use GNSS data, such as navigation, system bar, settings, etc., through the Android system interface.
[0045] This application expands data sources and makes full use of cloud data by replaying data stored in the cloud.
[0046] This application reduces development costs by adding data backup capabilities, allowing data to be saved to a USB drive for problem reproduction, bench testing, and other purposes. Attached Figure Description
[0047] Figure 1 This is a flowchart of a GNSS data backup and playback method based on SOME IP provided by one or more embodiments of the present invention.
[0048] Figure 2 This is a structural diagram of a GNSS data backup and playback system based on SOME IP provided by one or more embodiments of the present invention.
[0049] Figure 3 This is a schematic diagram of the IVI GNSS data playback and backup function design provided by one or more embodiments of the present invention.
[0050] Figure 4 This is a schematic diagram illustrating how data obtained from the cloud is directly deployed to an IVI for data playback, provided by one or more embodiments of the present invention.
[0051] Figure 5 This is a schematic diagram of data flow stored to a USB flash drive provided by one or more embodiments of the present invention.
[0052] Figure 6This is a schematic diagram illustrating the implementation of the producer-consumer pattern according to one or more embodiments of the present invention.
[0053] Figure 7 This is a schematic diagram of the data playback timing provided by one or more embodiments of the present invention.
[0054] Figure 8 This is a schematic diagram of data playback timing update provided by one or more embodiments of the present invention.
[0055] Figure 9 This is a block diagram of an electronic device structure for a GNSS data backup and playback method based on SOME IP provided in one or more embodiments of the present invention. Detailed Implementation
[0056] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0057] Figure 1 This is a flowchart of a GNSS data backup and playback method based on SOME IP provided by one or more embodiments of the present invention.
[0058] like Figure 1 The GNSS data backup and playback method based on SOME IP shown includes:
[0059] Step S1: Based on the IVI-based Android system architecture, add a GNSS Service;
[0060] Step S2: GNSS Service establishes data interaction with the vehicle-mounted telematics terminal TBox and the hardware abstraction layer HAL of GNSS respectively;
[0061] Step S3: A function switch is set in the factory mode to control the GNSS Service to perform data writing or data reading operations;
[0062] Step S4: When data is written, the GNSS Service subscribes to the TBox's GNSS events and receives the data, storing the data to the USB drive;
[0063] Step S5: When data is read, the GNSS Service stops subscribing to the TBox's GNSS events, reads data from the USB drive and transmits it to the GNSS HAL, which then provides it to the upper-layer application via the LocationManagerService of the JNI layer and the Framework layer.
[0064] In this embodiment, it includes:
[0065] A dual-buffer caching mechanism is used when writing data;
[0066] The dual-buffer caching mechanism involves the system creating two data buffers, buffer one and buffer two.
[0067] Buffer 1 caches the data of received GNSS events in real time. When the data reaches the specified size, the contents of Buffer 1 are copied to Buffer 2 and Buffer 1 is cleared. The data in Buffer 2 is synchronously written to the USB flash drive.
[0068] In this embodiment, it includes:
[0069] Data reading employs a multi-threaded producer-consumer pattern.
[0070] The multi-threaded producer-consumer pattern includes reading data from the USB drive through a first independent thread, parsing the read data through a second independent thread, and then passing the parsed data to the GNSS HAL in a loop.
[0071] In this embodiment, it also includes:
[0072] Retrieve GNSS data uploaded by TBox;
[0073] The data is deployed to the IVI, read by the GNSS Service, and transmitted to the GNSS HAL for playback.
[0074] In this embodiment, it includes:
[0075] During data reading, the data from the USB drive is read in a loop according to the GNSS data output frequency to achieve data loop playback.
[0076] Figure 2 This is a structural diagram of a GNSS data backup and playback system based on SOME IP provided by one or more embodiments of the present invention.
[0077] like Figure 2 The SOME IP-based GNSS data backup and playback system shown includes:
[0078] Upper-layer application module, factory mode control module, TBox module;
[0079] Based on the IVI-based Android system architecture, GNSS HAL serves as the core middleware layer connecting the underlying hardware capabilities with the upper-layer applications.
[0080] Among them, a GNSS Service module has been added for data interaction between the TBox module and the GNSS HAL;
[0081] The factory mode control module provides a function switch to select the data writing or data reading mode;
[0082] It also includes a data storage module, used to store the received TBox module data to a USB flash drive via GNSS Service;
[0083] The data playback module is used to read data from the USB flash drive via GNSS Service and transmit it to GNSS HAL for use by upper-layer application modules.
[0084] Specifically, GNSS HAL (Hardware Abstraction Layer) is an intermediate layer in the Android system responsible for interacting with GNSS modules (such as GPS, Beidou and other satellite positioning devices). Its main functions include location data acquisition, status callback, XTRA data injection, etc.
[0085] In this embodiment, it includes:
[0086] The GNSS Service module transmits the parsed GNSS data to the upper-layer architecture by calling the iccGnssLocationCb interface of GNSS HAL.
[0087] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.
[0088] In one specific embodiment, a method as follows is disclosed Figure 3 The IVI GNSS data playback and backup function design shown includes:
[0089] IVI GNSS data playback and backup function design scheme:
[0090] In the Android system architecture, the Framework layer sits above the HAL (Hardware Abstraction Layer) and is the core middleware connecting the underlying hardware capabilities with the upper-layer applications. Based on the hardware abstraction interface provided by the HAL layer, it encapsulates standardized services and APIs that are easier to use and more aligned with application development, providing them for the application layer to call.
[0091] LocationManagerService is a location-related service in the Framework layer that defines a series of location-related APIs for use by the application layer.
[0092] com_Android_server_location_GnssLocationProvider is a JNI layer responsible for connecting the Framework and HAL layers.
[0093] A separate GNSS service is added to the IVI and connected to the TBox. When the data backup function is enabled, data can be received directly from the TBox and stored on a USB drive. When the data playback function is enabled, navigation data can be read directly from the USB drive and sent to the GNSS HAL.
[0094] from Figure 3 As can be seen, data flows layer by layer: HAL -> native -> JNI -> Framework. As long as the underlying data entry point is handled properly, the data source can be modified without affecting the upper layers. This is one of the advantages of the Android system framework.
[0095] In this embodiment, as Figure 4 The data obtained from the cloud is directly deployed to the IVI for data playback, as shown below:
[0096] The cloud data, including latitude and longitude coordinates and timestamps, is uploaded to the server by Tbox. After retrieving the data from the cloud, it can be directly deployed to IVI for data playback.
[0097] This project extends the GNSS HAL on top of the native Android system by adding a GNSS Service. Through the GNSS Service interface, it enables data interaction between the extended GNSS HAL and the GNSS Service. Furthermore, it adds read and write data operations to the GNSS Service. The specific design is as follows:
[0098] 1. Add a switch to control GNSS data read / write in factory mode. It is off by default; when turned on, you can choose to read or write data.
[0099] 1: Write location data; 2: Read location data.
[0100] 2. GNSS Service adds data processing capabilities: 1. Data can be written back to a USB drive; 2. Data can be read from a USB drive and parsed.
[0101] When writing data, the GNSS Service subscribes to TBox GNSS events and receives GNSS data. To reduce system memory overhead, the system creates two new buffers: one to cache GNSS data locally, and when the data reaches a specified size, the contents of buffer1 are copied directly to buffer2, buffer1 is cleared, and data is written to buffer1 again. The data in buffer2 is then written to the USB drive.
[0102] When reading data, the GNSS Service stops subscribing to TBox GNSS events and begins reading files from the USB drive. It reads a specified amount of data at a time, and then loops through the data, playing it back in a loop.
[0103] The GNSS Service resides at the system's lowest level and is written in C++, allowing for file reading and writing using the C++ standard library. For example... Figure 5 The data update is shown below.
[0104] Reading files can be accomplished using multithreading to overlap file reading and parsing operations, a common high-performance optimization technique. Specifically, this can be implemented using the producer-consumer pattern, such as... Figure 6 As shown.
[0105] like Figure 7 ,like Figure 8 As shown, after the GNSS Service reads the data, it calls the GNSS HAL interface iccGnssLocationCb method in a loop according to the GNSS signal output frequency to pass the data to the upper layer.
[0106] Figure 9 This is a block diagram of an electronic device structure for a GNSS data backup and playback method based on SOME IP provided in one or more embodiments of the present invention.
[0107] like Figure 9 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0108] The memory stores a computer program that, when executed by the processor, causes the processor to perform steps of a GNSS data backup and playback method based on SOME IP.
[0109] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a GNSS data backup and playback method based on SOME IP.
[0110] This application also provides a vehicle cabin, including:
[0111] Electronic equipment for implementing the steps of a GNSS data backup and playback method based on SOME IP;
[0112] The processor runs a program that, when running, executes the steps of a GNSS data backup and playback method based on SOME IP from data output by the electronic device.
[0113] Storage medium for storing programs that, when running, execute steps of a GNSS data backup and playback method based on SOME IP for data output from electronic devices.
[0114] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.
[0115] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.
[0116] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.
[0117] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.
[0118] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.
[0119] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.
[0120] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.
[0121] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.
[0122] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.
[0123] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. A method for GNSS data backup and playback based on SOME IP, characterized in that, The SOME IP-based GNSS data backup and playback method comprises: An IVI-based Android system architecture, with a GNSS Service added; The GNSS Service respectively establishes data interaction with a vehicle-mounted telematics terminal TBox and a hardware abstraction layer HAL of the GNSS; The factory mode is provided with a function switch to control the GNSS Service to perform data writing or data reading; When data is written, the GNSS Service subscribes to GNSS events of the TBox and receives data, and stores the data to a U disk; When data is read, the GNSS Service stops subscribing to the GNSS events of the TBox, reads data from the U disk and delivers the data to the GNSS HAL, which provides the data to an upper-layer application through a JNI layer and a Framework layer.
2. The SOME IP based GNSS data backup and playback method of claim 1, wherein, Comprising: A double-buffer caching mechanism is used when data is written; The double-buffer caching mechanism comprises that the system creates two data cache areas, a cache area 1 and a cache area 2; The cache area 1 caches GNSS event data in real time, and when the data reaches a specified size, the content of the cache area 1 is copied to the cache area 2 and the cache area 1 is emptied, and the data in the cache area 2 is synchronously written to the U disk.
3. The SOME IP based GNSS data backup and playback method of claim 1, wherein, Comprising: A multi-threaded producer-consumer mode is used when data is read; The multi-threaded producer-consumer mode comprises that a first independent thread reads U disk data, a second independent thread parses the read data, and the parsed data is cyclically delivered to the GNSS HAL.
4. The SOME IP based GNSS data backup and playback method of claim 1, wherein, Further comprising: GNSS data uploaded by the TBox is acquired; The data is deployed to the IVI, read by the GNSS Service and delivered to the GNSS HAL to realize playback.
5. The SOME IP based GNSS data backup and playback method of claim 1, wherein, Comprising: When data is read, U disk data is cyclically read according to a GNSS data output frequency, to realize cyclic playback of the data.
6. A SOME IP based GNSS data backup and playback system characterized in that, The SOME IP-based GNSS data backup and playback system comprises: An upper-layer application module, a factory mode control module and a TBox module; An IVI-based Android system architecture, with the GNSS HAL as a core intermediate layer connecting a bottom-layer hardware capability and an upper-layer application; The GNSS Service module is added to realize data interaction between the TBox module and the GNSS HAL; The factory mode control module is used to provide a function switch to select a data writing mode or a data reading mode; Further comprising a data storage module for storing TBox module data received by the GNSS Service to a U disk; A data playback module for reading data from the U disk by the GNSS Service and delivering the data to the GNSS HAL for calling by the upper-layer application module.
7. The SOME IP based GNSS data backup and playback system of claim 6, wherein, Comprising: The GNSS Service module delivers parsed GNSS data to the upper-layer architecture by calling an iccGnssLocationCb interface of the GNSS HAL.
8. An electronic device, comprising: Comprising: A processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the SOME IP-based GNSS data backup and playback method according to any one of claims 1 to 5.
9. A computer-readable storage medium, characterized in that, The memory stores a computer program executable by the electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the SOME IP-based GNSS data backup and playback method according to any one of claims 1 to 5.
10. A vehicle cabin, characterized by Comprising: The electronic device is used to implement the steps of the SOME IP-based GNSS data backup and playback method according to any one of claims 1 to 5; The processor runs the program, and when the program runs, the data output from the electronic device executes the steps of the SOME IP-based GNSS data backup and playback method according to any one of claims 1 to 5; The storage medium is used to store the program, and when the program runs, the data output from the electronic device executes the steps of the SOME IP-based GNSS data backup and playback method according to any one of claims 1 to 5.