Vehicle-mounted central control automobile data recorder system

Abstract

The invention discloses a vehicle-mounted central control automobile data recorder system which realizes architecture in an Android hardware abstraction layer and a framework service layer, realizes two-way communication with an upper-layer application and DVR equipment through DVR middleware described by the architecture, and has higher performance, stronger expansibility, better communication efficiency and good flexibility and adaptability. According to the technical scheme, the system comprises a Linux kernel module which is provided with a socket communication interface and used for receiving data sent by the automobile data recorder and storing the data in a network buffer area in the Linux kernel module; the Android hardware abstraction layer module is used for realizing a control flow function of the automobile data recorder and data interaction related to the automobile data recorder through a socket communication interface; the framework layer service module carries out message management on different upper-layer applications and transmits request messages of the upper-layer applications to the Android hardware abstraction layer module according to priorities, and the Android hardware abstraction layer module constructs a TCP / IP data packet according to a communication protocol; and after successful packing, the instruction data stream is transmitted to the automobile data recorder through a socket communication interface of the Linux kernel module.

Description

Technical Field

[0001] The present invention relates to a vehicle-mounted central control driving recorder system, and in particular to a vehicle-mounted central control driving recorder system based on a Linux kernel socket communication driver and Android middleware. Background Art

[0002] With the rapid development of automobile intelligence and networking technology, the performance requirements and functional complexity of Dashboard Video Recorder (DVR) as an important device for vehicle safety monitoring and accident tracing are increasing. Traditional DVR systems are mainly built on the microcontroller unit (MCU) platform, or directly embedded in the application layer of the Android operating system. These design solutions have shown good practicality and certain cost-effectiveness in early vehicle monitoring applications, meeting basic driving records and data storage needs.

[0003] However, with the popularization of high-definition video technology, the surge in sensor data, and the growth in vehicle network communication needs, traditional dashcam systems have gradually exposed many limitations. First, in terms of resource utilization, MCU-based systems are limited by their processing power and memory space, and it is difficult to efficiently process high-resolution video streams and multi-sensor fusion data, resulting in low data compression efficiency and limited storage and playback performance. At the same time, although systems directly integrated into the Android application layer can take advantage of richer software resources and user interface advantages, they often affect the real-time and stability of the core functions of the dashcam due to the high overhead of the operating system itself.

[0004] Secondly, in terms of scalability, the traditional system architecture is relatively closed, making it difficult to flexibly add new functions or optimize existing algorithms, especially when faced with complex function integration such as advanced driver assistance systems (ADAS) and automatic emergency braking (AEB). In addition, with the rapid iteration of hardware technology, the traditional system is not compatible with new hardware platforms, limiting the space for performance upgrades.

[0005] Furthermore, communication efficiency has become another key factor restricting the development of traditional dashcams. In scenarios where real-time transmission requirements are increasingly stringent, such as remote monitoring and real-time road condition sharing, traditional systems are limited by the inefficiency of communication protocols and bandwidth limitations, making it difficult to achieve fast and reliable data transmission. This not only affects the user experience, but also limits the in-depth application of dashcams in the Internet of Vehicles ecosystem.

[0006] Finally, the lack of flexibility and adaptability is also a serious challenge facing traditional systems. Faced with rapidly changing market demands and emerging new technologies such as 5G communications and artificial intelligence analysis, traditional systems are difficult to quickly adjust to new hardware or software environments, thus missing out on many innovation opportunities.

[0007] In summary, the limitations of traditional driving recorder systems in terms of resource utilization, scalability, communication efficiency, flexibility and adaptability have made it difficult to meet the current and future needs of vehicle safety monitoring and intelligent development. Therefore, developing a new driving recorder system with higher performance, stronger scalability, better communication efficiency, good flexibility and adaptability has become an urgent problem to be solved in the industry. Summary of the invention

[0008] A brief summary of one or more aspects is given below to provide a basic understanding of these aspects. This summary is not an exhaustive overview of all conceived aspects, and is neither intended to identify the key or critical elements of all aspects nor to define the scope of any or all aspects. Its only purpose is to give some concepts of one or more aspects in a simplified form as a prelude to a more detailed description that will be given later.

[0009] The purpose of the present invention is to solve the above problems and provide a vehicle-mounted central control driving recorder system, which implements the architecture in the Android hardware abstraction layer and the framework service layer, and realizes two-way communication with the upper-level application (APP) and the DVR device through the DVR middleware described in the architecture, with higher performance, stronger scalability, better communication efficiency, good flexibility and adaptability.

[0010] The technical solution of the present invention is as follows: The present invention discloses a vehicle-mounted central control driving recorder system, the system includes an Android hardware abstraction layer module, a Linux kernel module and a framework layer service module, wherein:

[0011] The Linux kernel module sets a socket communication interface for receiving data sent by the driving recorder and storing it in a network buffer therein;

[0012] Android hardware abstraction layer module, used to implement the control flow function of the dashcam and the data interaction related to the dashcam through the socket communication interface;

[0013] The framework layer service module manages messages for different upper-layer applications and passes the request messages of the upper-layer applications to the Android hardware abstraction layer module according to the priority. The Android hardware abstraction layer module builds TCP / IP data packets according to the communication protocol. After the packet is successfully assembled, the command data stream is passed to the driving recorder through the socket communication interface of the Linux kernel module.

[0014] According to one embodiment of the vehicle-mounted central control driving recorder system of the present invention, a message processing unit is set in the Android hardware abstraction layer module, which is used to parse the operation instructions transmitted from the upper-layer application via the framework layer service module, and perform data conversion on the parsed content to connect with the upper-layer application.

[0015] According to one embodiment of the vehicle-mounted central control driving recorder system of the present invention, the Android hardware abstraction layer module encapsulates the socket communication interface through the communication encapsulation unit to ensure that the data format of the communication between the driving recorder and the vehicle computer complies with the specified protocol, and provides a message sending and receiving interface method in the encapsulation class to realize automatic management of message parsing and error handling mechanism.

[0016] According to one embodiment of the vehicle-mounted central control driving recorder system of the present invention, the Android hardware abstraction layer module reads data from the network buffer of the Linux kernel module, adopts a blocking I / O model, and uses a select mechanism for timeout judgment, wherein the size and management strategy of the network buffer are dynamically adjusted according to the real-time data flow.

[0017] According to one embodiment of the vehicle-mounted central control driving recorder system of the present invention, the socket layer in the Linux kernel module is the management point of the network IO, and uses the TCP / IP protocol stack to process the network data stream, including data segmentation, reassembly and error detection, wherein the received network data is temporarily stored in the network buffer by the Linux kernel module.

[0018] According to one embodiment of the vehicle-mounted central control driving recorder system of the present invention, the Android hardware abstraction layer module initializes the connection through the connection processing unit to realize heartbeat detection, and realizes automatic reconnection processing for different disconnection scenarios by judging various error codes in the connection. When receiving data, a timeout is set to prevent blocking for too long, and related resources and socket connections are automatically released when the connection is disconnected or in an abnormal situation.

[0019] According to one embodiment of the vehicle-mounted central control driving recorder system of the present invention, the vehicle computer performs identity authentication when connecting to the driving recorder, and the Android hardware abstraction layer module obtains the host name and network address of the driving recorder after receiving the reply from the driving recorder, and starts communication of control commands with the driving recorder after identity authentication, so as to ensure the security of data transmission, wherein the Android hardware abstraction layer module extracts the information of the driving recorder, identifies the device manufacturer, and enables the Android hardware abstraction layer module to uniformly encapsulate the unified basic functions of hardware devices of different manufacturers, and perform corresponding differentiated development of differentiated functions through the identified device fields.

[0020] According to an embodiment of the vehicle-mounted central control driving recorder system of the present invention, the framework layer service module is further configured to receive the operation instruction of the application layer, and after the operation command is converted into a format, interact with the Android hardware abstraction layer module through the inter-process communication unit, establish an automatic reconnection mechanism with the Android hardware abstraction layer module, and be responsible for the management of memory resources. At the same time, the framework layer service module receives the command callback from the Android hardware abstraction layer module, and these callbacks carry the status and related information of the execution of the application layer command, and send the message to the upper layer application through the format conversion unit, wherein the framework layer service module abstracts the functional interface class unit, and the interface class encapsulates the function of cross-process communication. When the framework layer service module is started, the registration service is used to enable the upper layer application to discover and bind the registration service, and the service connection status is processed through the callback function and the current binding status is recorded. After the upper layer application completes the operation, the binding is released and resources are cleaned up during the unbinding process to prevent memory leakage and resource waste. The upper layer application realizes automatic communication with the middleware of the driving recorder by integrating the interface provided by the framework layer service module, and the process of automatic communication is managed by the framework layer service module through the connection.

[0021] According to an embodiment of the vehicle-mounted central control driving recorder system of the present invention, the command scheduling unit in the framework layer service module dynamically processes control commands from different application layers according to the resource status of the current system and the priority of the application.

[0022] According to one embodiment of the vehicle-mounted central control driving recorder system of the present invention, the data parsing process of the Android hardware abstraction layer module in the message processing unit includes message reception, data format identification, message content decoding, and corresponding processing according to the data type. After determining whether the decoded message complies with the communication protocol of the driving recorder, the message is parsed. For data that complies with the communication protocol, the data is parsed, and for data that does not comply with the communication protocol, an error is recorded and discarded. The Android hardware abstraction layer module performs corresponding operations according to the parsed data content, automatically segments long messages, and when all segmented data are received, the segmented data are spliced ​​in sequence according to the sequence number to restore them to a complete JSON string. The JSON string is parsed into structured data using the JsonCpp library for subsequent processing. If all segments are not received within the specified time, the retransmission mechanism is triggered to re-request the missing segmented data.

[0023] Compared with the prior art, the present invention has the following beneficial effects:

[0024] 1. The present invention combines the HU (Head Unit, terminal information display unit also known as vehicle computer) Android HAL (Android hardware abstraction layer) communication mechanism with the socket communication mechanism of the Linux kernel;

[0025] 2. The architecture design of the present invention can adapt to multiple upper layer applications and automatically manage the connection between the application and the framework service layer;

[0026] 3. The architecture design of the present invention can identify and adapt to different devices and has good expansibility for new functions;

[0027] 4. The architecture design of the present invention can automatically manage the network connection of the DVR device, including exception capture and resource management;

[0028] 5. The architecture design of the present invention can dynamically process the request operations of applications to DVR devices and avoid resource competition. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above features and advantages of the present invention can be better understood after reading the detailed description of the embodiments of the present disclosure in conjunction with the following drawings. In the drawings, the components are not necessarily drawn to scale, and components with similar related properties or features may have the same or similar reference numerals.

[0030] Figure 1 A schematic diagram of an embodiment of a vehicle-mounted central control driving recorder system of the present invention is shown.

[0031] Figure 2 Shows Figure 1 The flowchart of data parsing by the Android hardware abstraction layer module in the message processing unit in the system embodiment shown. DETAILED DESCRIPTION

[0032] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. Note that the aspects described below in conjunction with the accompanying drawings and specific embodiments are only exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0033] Figure 1 The principle of an embodiment of the vehicle-mounted central control driving recorder system of the present invention is shown. Figure 1 The system of this embodiment includes: an Android hardware abstraction layer module 1, a Linux kernel module and a framework layer service module 7.

[0034] The Linux kernel module is provided with a socket communication interface (Socket API) 2. The framework layer service module 7 is used to interact with upper layer applications to improve data processing and transmission efficiency, optimize resource allocation and system stability. The framework layer service module 7 is provided with a format conversion unit 8, an interface class unit 9, a communication unit 10, and a command scheduling unit 11. The Android hardware abstraction layer module 1 is provided with a message processing unit 4, a connection processing unit 6, and a communication encapsulation unit.

[0035] The Android hardware abstraction layer module 1 is used to implement the control flow function of the DVR device and the data interaction related to the DVR device, which is specifically implemented through the socket communication interface 2 in the Linux kernel module, that is, the Android hardware abstraction layer module 1 uses the TCP type socket Socket and binds and listens on a specific port number to ensure a stable connection. The data sent by the DVR device (also known as the driving recorder) 3 to the Android hardware abstraction layer module 1 first arrives at the Linux kernel module, where the network subsystem of the Linux kernel module is responsible for processing these data. The Android hardware abstraction layer module 1 reads data from the network buffer of the Linux kernel module by calling a specific socket communication interface 2. The calling of the socket communication interface 2 involves the operation of the network socket, and extracts data from the network buffer specified by the Linux kernel module. The message processing unit 4 set in the Android hardware abstraction layer module 1 is used to parse the operation instructions transmitted by the upper-layer application via the framework layer service module 6, and perform data conversion on the parsed content to connect to the upper-layer application. The framework layer service module 6 manages messages for different upper-layer applications, and passes the request messages of the upper-layer applications to the Android hardware abstraction layer module 1 according to the priority. The Android hardware abstraction layer module 1 constructs a TCP / IP data packet according to the communication protocol. After the packet is successfully assembled, the command data stream is passed to the DVR device 3 through the socket communication interface 2 of the Linux kernel module. In this process, functions such as adjusting hardware settings, starting or stopping video capture, playing back videos, and file management processes are completed. This process allows third parties to develop applications for expansion to provide users with a richer in-vehicle experience.

[0036] The Android hardware abstraction layer module 1 encapsulates the socket communication interface 2 through the communication encapsulation unit 5, such as using the recv() or read() class to implement data transmission, ensuring that the data format of the communication between the DVR device 3 and the vehicle computer complies with the specified protocol, and providing a new message receiving and sending interface method in the encapsulation class to realize the automatic management of message parsing and the error handling mechanism. The Android hardware abstraction layer module 1 reads data from the network buffer of the Linux kernel module by calling a specific socket communication interface 2, adopts a blocking I / O model, and uses the select mechanism for timeout judgment (for example, setting more than 10 seconds as a timeout), while supporting stable data transmission and effectively handling the frame loss problem. The Socket layer in the Linux kernel module serves as the management point of the network IO, and uses the TCP / IP protocol stack to process the network data flow, including data segmentation, reassembly and error detection. The received data is temporarily stored in the network buffer by the Linux kernel module. This step uses the buffer mechanism of the Linux kernel module to manage the data flow, ensure the order and integrity of the data packets, and provide a stable data source for the upper layer. The size and management strategy of the network buffer are dynamically adjusted according to the real-time data flow to optimize resource utilization.

[0037] The Android hardware abstraction layer module 1 initializes the connection through the connection processing unit 6 and implements heartbeat detection. By judging various error codes in the connection, it realizes automatic reconnection processing for different disconnection scenarios, sets a timeout when receiving data to prevent blocking for too long, and automatically releases related resources and Socket connections when the connection is disconnected or abnormal. The vehicle computer performs identity authentication when connecting with the DVR device 3. After receiving the reply from the DVR device 3, the Android hardware abstraction layer module 1 obtains the "HostName" of the DVR device 3 and the network address of the DVR device 3. After identity authentication, it starts communication of control commands with the DVR device 3 to ensure the security of data transmission. In this process, the Android hardware abstraction layer module 1 extracts the information of the DVR device 3 and identifies the device manufacturer. This function enables the Android hardware abstraction layer module 1 to uniformly encapsulate the unified basic functions of hardware devices of different manufacturers, and perform corresponding differentiated development of differentiated functions through the identified device fields. Therefore, the system framework of this embodiment has stronger compatibility in realizing the function of adapting hardware devices of different manufacturers.

[0038] The data parsing process of the Android hardware abstraction layer module 1 in the message processing unit 4 refers to Figure 2As shown, the processing process includes message reception, data format identification, message content decoding, and appropriate processing according to the data type. After determining whether the decoded message conforms to the communication protocol of the DVR device 3, the message is parsed. For those that conform to the communication protocol, the data is parsed, and for those that do not conform to the communication protocol, the error is recorded and discarded. The processing determines the format of the message sent by the framework service layer module 7 and the DVR device 3 to ensure the security of the communication data. According to the parsed data content, the Android hardware abstraction layer module 1 performs the corresponding operation, that is, the hardware function execution information is processed by monitoring the callback. By automatically segmenting and splicing large messages and using containers for management, more customized functions based on the native protocol can be realized. At the same time, in the process of message segmentation and splicing, the screening mechanism is used to prevent omission and error. All communication data are encoded in JSON format, and the JsonCpp library is used to convert structured data into JSON strings to ensure the readability and easy parsability of the data. Since TCP is a byte stream-oriented protocol, in order to avoid the transmission efficiency being reduced due to the large data packet, the system automatically segments long messages (that is, the segmented data is received and the header information is added after the message length is greater than the set value). When all the segmented data are received, the system will concatenate the segmented data in sequence and restore it to a complete JSON string. The JsonCpp library is used to parse the JSON string into structured data for subsequent processing. If all the segments are not received within the specified time (10 seconds), the system will trigger the retransmission mechanism and re-request the missing segmented data. The timeout detection is implemented through the select mechanism to avoid long-term blocking due to packet loss. After detecting a verification failure or timeout, the system records an error log and tries to re-establish a connection or request retransmission to ensure data reliability and system stability.

[0039] The framework layer service module 7 is responsible for receiving the operation instructions of the application layer, converting the control commands into an appropriate format, interacting with the Android hardware abstraction layer module 1 through the inter-process communication unit 10, establishing an automatic reconnection mechanism with the Android hardware abstraction layer module 1, and being responsible for the management of memory resources. At the same time, the framework layer service module 7 receives command callbacks from the Android hardware abstraction layer module 1. These callbacks carry the status and related information of the execution of the application layer commands, and send the messages to the upper layer application through the format conversion unit 8. The framework layer service module 7 abstracts the functional interface class unit 9 based on AIDL (Android Interface Definition Language). The interface class provided by the framework layer service module 7 encapsulates the function of cross-process communication. When the framework layer service module 7 is started, the ServiceManager is used to register the service so that the upper layer application can discover and bind the registered service, process the status of the service connection through the callback function, and record the current binding status. After the upper layer application completes the operation, it unbinds by calling unbindService(), and performs necessary resource cleanup in the process to prevent memory leaks and resource waste. The upper layer application realizes automatic communication with the middleware of the DVR device 3 through the interface provided by the integrated framework layer service module 7. In this process, the framework layer service module 7 manages the connection to enhance the adaptation and expansion of the architecture to the upper layer application. This design enhances the adaptability and scalability of the upper layer application and ensures the stability and high availability of the system in various scenarios.

[0040] The command scheduling unit 11 in the framework layer service module 7 dynamically processes control commands from different application layers according to the resource status of the current system and the priority of the application. When multiple applications initiate operation requests to the DVR device 3 at the same time, the framework layer service module 7 allows the application to mark different commands as high, medium, and low priorities when sending control commands, and dynamically adjust according to the needs of the application. Emergency recording commands are marked as high priority, and ordinary query commands are marked as low priority. Among them, the command scheduling unit 11 adjusts the execution order of commands according to the resource usage of the current system. For example, when the system load is high, low-priority commands are delayed to ensure the timely execution of high-priority commands, thereby optimizing the upper-level user experience and reducing user waiting time. At the same time, the command scheduling unit 11 monitors the execution status and results of each command, and feeds back the execution status and error code of the current command to the upper-level application. The upper-level application can turn on or off the active notification through the switch to quickly troubleshoot and optimize.

[0041] Although the above methods are illustrated and described as a series of actions for simplicity of explanation, it should be understood and appreciated that these methods are not limited by the order of the actions, because according to one or more embodiments, some actions may occur in a different order and / or concurrently with other actions from those illustrated and described herein or not illustrated and described herein but understandable to those skilled in the art.

[0042] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. The technician may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as resulting in a departure from the scope of the present invention.

[0043] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in cooperation with a DSP core, or any other such configuration.

[0044] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read and write information from / to the storage medium. In an alternative, a storage medium may be integrated into a processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and the storage medium may reside in a user terminal as discrete components.

[0045] In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented as a computer program product in software, each function may be stored on or transmitted by a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one place to another. Storage media may be any available medium that can be accessed by a computer. As an example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Any connection is also properly referred to as a computer-readable medium. For example, if the software is transmitted from a website, a server, or other remote source using a coaxial cable, a fiber optic cable, a twisted pair, a digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of the medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, wherein disk often reproduces data magnetically, while disc reproduces data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0046] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but should be granted the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A vehicle-mounted central control driving recorder system, characterized in that: The system includes Android hardware abstraction layer module, Linux kernel module and framework layer service module, among which: The Linux kernel module sets a socket communication interface for receiving data sent by the driving recorder and storing it in a network buffer therein; Android hardware abstraction layer module, used to implement the control flow function of the dashcam and the data interaction related to the dashcam through the socket communication interface; The framework layer service module manages messages for different upper-layer applications and passes the request messages of the upper-layer applications to the Android hardware abstraction layer module according to the priority. The Android hardware abstraction layer module builds TCP / IP data packets according to the communication protocol. After the packet is successfully assembled, the command data stream is passed to the driving recorder through the socket communication interface of the Linux kernel module.

2. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: A message processing unit is set in the Android hardware abstraction layer module to parse the operation instructions transmitted by the upper-layer application via the framework layer service module, and perform data conversion on the parsed content to connect with the upper-layer application.

3. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The Android hardware abstraction layer module encapsulates the socket communication interface through the communication encapsulation unit to ensure that the data format of the communication between the driving recorder and the vehicle computer conforms to the specified protocol, and provides a message sending and receiving interface method in the encapsulation class to realize the automatic management of message parsing and the error handling mechanism.

4. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The Android hardware abstraction layer module reads data from the network buffer of the Linux kernel module, adopts a blocking I / O model, and uses the select mechanism for timeout judgment. The size and management strategy of the network buffer are dynamically adjusted according to the real-time data traffic.

5. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The socket layer in the Linux kernel module is the management point of network IO. It uses the TCP / IP protocol stack to process network data streams, including data segmentation, reassembly, and error detection. The received network data is temporarily stored in the network buffer by the Linux kernel module.

6. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The Android hardware abstraction layer module initializes the connection through the connection processing unit to implement heartbeat detection. It judges various error codes in the connection to realize automatic reconnection processing for different disconnection scenarios, sets a timeout when receiving data to prevent blocking for too long, and automatically releases related resources and socket connections when the connection is disconnected or abnormal.

7. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The vehicle computer performs identity authentication when connecting to the driving recorder. After receiving the reply from the driving recorder, the Android hardware abstraction layer module obtains the host name and network address of the driving recorder. After identity authentication, it starts communication of control commands with the driving recorder to ensure the security of data transmission. Among them, the Android hardware abstraction layer module extracts the information of the driving recorder and identifies the device manufacturer, so that the Android hardware abstraction layer module uniformly encapsulates the basic functions of the hardware devices of different manufacturers, and performs differentiated development of differentiated functions according to the identified device fields.

8. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The framework layer service module is further configured to receive operation instructions from the application layer, convert the operation commands into a format, interact with the Android hardware abstraction layer module through the inter-process communication unit, establish an automatic reconnection mechanism with the Android hardware abstraction layer module, and be responsible for the management of memory resources. At the same time, the framework layer service module receives command callbacks from the Android hardware abstraction layer module. These callbacks carry the status of the execution of application layer commands and related information, and send the messages to the upper-layer application through the format conversion unit. The framework layer service module abstracts a functional interface class unit, and the interface class encapsulates the function of cross-process communication. When the framework layer service module is started, the registration service is used to enable the upper-layer application to discover and bind the registration service. The status of the service connection is processed through the callback function and the current binding status is recorded. After the upper-layer application completes the operation, the binding is unbound and resources are cleaned up during the unbinding process to prevent memory leakage and resource waste. The upper-layer application realizes automatic communication with the middleware of the driving recorder by integrating the interface provided by the framework layer service module. The process of automatic communication is managed by the framework layer service module through the connection.

9. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The command scheduling unit in the framework layer service module dynamically processes control commands from different application layers according to the current system resource status and application priority.

10. The vehicle-mounted central control driving recorder system according to claim 1, characterized in that: The data parsing process of the Android hardware abstraction layer module in the message processing unit includes message reception, data format identification, message content decoding, and corresponding processing according to the data type. After determining whether the decoded message complies with the communication protocol of the driving recorder, it is parsed. For those that comply with the communication protocol, the data is parsed, and for those that do not comply with the communication protocol, the error is recorded and discarded. The Android hardware abstraction layer module performs corresponding operations according to the parsed data content, automatically segments long messages, and when all segmented data are received, the segmented data are concatenated in sequence according to the sequence number to restore them into a complete JSON string. The JsonCpp library is used to parse the JSON string into structured data for subsequent processing. If all segments are not received within the specified time, the retransmission mechanism is triggered and the missing segmented data is re-requested.

Images