CN112015157A

CN112015157A - Linux-based vehicle-mounted device interaction method and device, computer equipment and storage medium

Info

Publication number: CN112015157A
Application number: CN201910454839.5A
Authority: CN
Inventors: 辛超; 成蕾
Original assignee: BYD Co Ltd
Current assignee: BYD Co Ltd
Priority date: 2019-05-29
Filing date: 2019-05-29
Publication date: 2020-12-01
Anticipated expiration: 2039-05-29
Also published as: CN112015157B

Abstract

The invention discloses a vehicle-mounted interaction method and device based on Linux, computer equipment and a storage medium. The Linux-based vehicle-mounted interaction method comprises the following steps executed by a Linux-based server: acquiring target vehicle machine data from a vehicle controller; and sending the target vehicle machine data to a target client constructed based on the Linux through a Binder communication channel. The method can send the target vehicle machine data acquired from the vehicle controller to the target client through the Binder communication channel, so that the target vehicle machine data has the advantages of good safety, high transmission performance, simplicity, easiness in use and the like in the data transmission process.

Description

Linux-based vehicle-mounted device interaction method and device, computer equipment and storage medium

Technical Field

The invention relates to the technical field of communication, in particular to a vehicle-mounted interaction method and device based on Linux, computer equipment and a storage medium.

Background

The current vehicle-machine interaction system mainly relates to a client, a server and a communication mechanism, and the interaction process is as follows: the client side performs data interaction with the server side through a communication mechanism, namely, sends a control instruction and acquires corresponding vehicle-mounted machine data; the server is responsible for receiving the vehicle-mounted machine data from the vehicle and sending the vehicle-mounted machine data to the client through a communication mechanism. The current vehicle-machine interactive system mainly adopts a Linux system to build a client and a server, and a communication mechanism between the client and the server mainly adopts a socket, a pipeline, a semaphore, a shared memory, a message queue and the like, and the communication mechanisms have defects. For example, Socket is a general-purpose interface, which has low transmission efficiency and high overhead. The pipeline mechanism is half-duplex, and vehicle machine interaction requires full-duplex, so that the design of the two-way communication is complex for the pipeline mechanism. The semaphore is used for synchronization between processes, bidirectional synchronization can be completely realized only by sharing the shared memory, and the shared memory has no message boundary and more control objects in one-time communication. The message queue adopts a store-and-forward mode, data needs to be copied at least 2 times, and the efficiency is low. The shared memory control mechanism is complex and requires multiple mechanisms to operate cooperatively. Namely, the problems of low transmission performance and complex communication mechanism exist in the current Linux-based vehicle-machine interaction system.

Disclosure of Invention

The embodiment of the invention provides a Linux-based vehicle-mounted device interaction method, a Linux-based vehicle-mounted device interaction device, computer equipment and a storage medium, and aims to solve the problems that a communication mechanism adopted in the current vehicle-mounted device interaction process is low in transmission performance or complex in communication mechanism.

A vehicle-mounted interaction method based on Linux comprises the following steps executed by a service side constructed based on Linux:

acquiring target vehicle machine data from a vehicle controller;

and sending the target vehicle machine data to a target client constructed based on the Linux through a Binder communication channel.

The utility model provides a car machine interaction device based on Linux, specifically is including the server that constructs based on Linux, includes:

the vehicle machine data acquisition module is used for acquiring target vehicle machine data from the vehicle controller;

and the vehicle-machine data transmission module is used for sending the target vehicle-machine data to a target client constructed based on the Linux through a Binder communication channel.

A computer device comprises a memory, a processor and a computer program which is stored in the memory and can run on the processor, wherein the processor executes the computer program to realize the Linux-based vehicle-machine interaction method.

A computer-readable storage medium storing a computer program, which when executed by a processor implements the Linux-based car-machine interaction method described above.

According to the Linux-based vehicle-mounted device interaction method, the Linux-based vehicle-mounted device interaction device, the computer equipment and the storage medium, the target vehicle-mounted device data acquired from the vehicle controller is sent to the target client through the Binder communication channel, so that the target vehicle-mounted device data is guaranteed to have the advantages of being good in safety, high in transmission performance, simple and easy to use and the like in the data transmission process.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.

FIG. 1 is a schematic diagram of an application environment of a Linux vehicle-mounted device interaction method according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating a vehicle-machine interaction method of Linux according to an embodiment of the present invention;

FIG. 3 is another flowchart of a vehicle-mounted device interaction method of Linux according to an embodiment of the present invention;

FIG. 4 is another flowchart illustrating a vehicle-mounted device interaction method of Linux according to an embodiment of the present invention;

FIG. 5 is another flowchart illustrating a vehicle-mounted device interaction method of Linux according to an embodiment of the present invention;

FIG. 6 is another flowchart illustrating a vehicle-mounted device interaction method of Linux according to an embodiment of the present invention;

FIG. 7 is a diagram of a vehicle-mounted interactive device of Linux according to an embodiment of the present invention;

FIG. 8 is a schematic diagram of a computer device according to an embodiment of the invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The Linux-based vehicle-mounted device interaction method provided by the embodiment of the invention can be applied to the application environment shown in fig. 1. Specifically, the Linux-based vehicle-machine interaction method is applied to a Linux-based vehicle-machine interaction system, the Linux-based vehicle-machine interaction system comprises a client and a server which are constructed based on Linux as shown in fig. 1, the client and the server communicate through a Binder communication channel constructed by a Binder mechanism, the communication mechanism is simple and easy, and the data transmission efficiency and the data transmission performance can be improved; the server is in communication connection with the vehicle controller and used for acquiring vehicle-machine data of the vehicle or controlling the vehicle through the vehicle controller so that the server can obtain the corresponding vehicle-machine data. The client is also called a client, and refers to a program corresponding to the server and providing local services to the client. The client may be installed on, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented by an independent server or a server cluster composed of a plurality of servers.

Because the original Linux does not support the Binder mechanism, the Binder mechanism on the Android needs to be transplanted to a Linux-based vehicle-machine interaction system, so that the Linux-based client and the Linux-based server can communicate with each other through the Binder communication channel constructed based on the Binder mechanism, the communication mechanism is simple and convenient, and the data transmission efficiency and the data transmission performance can be improved. The method comprises the steps of transplanting a Binder mechanism on Android to a Linux-based vehicle-machine interactive system, and specifically comprises Binder drive transplanting, Servicemanager (namely, service manager) transplanting and Binder library transplanting.

The method specifically comprises the step of transplanting the Binder drive to a Linux-based vehicle-mounted interaction system, the Android system and the Kernel part of the Linux system are basically consistent, so that the transplanting process is feasible, and the transplanted Binder drive can be ensured to run on the Linux-based vehicle-mounted interaction system only by controlling the matching of the number (64 bits or 32 bits) of the upper layer of the Binder mechanism and the number of the system bits.

The ServiceManager transplantation refers to the transplantation of the ServiceManager to a Linux-based vehicle-machine interactive system, and the ServiceManager is a very important part of the upper layer of a Binder mechanism and provides the registration and query of services, and the part runs in the Android system in a bin program form, and the transplanted ServiceManager can be applied to the Linux-based vehicle-machine interactive system only by solving the problems of dependence on a library and compiling and running in the transplantation process.

The Binder library transplantation refers to the transplantation of a Binder library to a Linux-based vehicle-machine interactive system, wherein the Binder library mainly serves for service and exists in a shared library form in an Android system, and other dependent libraries need to be transplanted together in the transplantation process and compiled into the shared library of the Linux system. Generally, the Binder library in the migration process includes Binder function interfaces (e.g., AutoServer interfaces) corresponding to various functions involved in the car machine interaction process, and each Binder function interface can implement a specific function.

Because the Linux-based vehicle-machine interaction system provides vehicle-machine interaction services, if corresponding vehicle-machine data (such as voltage data and current data) CAN be inquired and obtained and vehicle control (such as control of operations of starting, closing and adjusting temperature of an air conditioner in a vehicle) CAN be carried out, a service end needs to be communicated with a vehicle controller arranged in the vehicle, and the vehicle controller is communicated with at least one module control unit in the vehicle through a Controller Area Network (CAN) so that the vehicle controller CAN obtain the vehicle-machine data collected by the corresponding module control unit and control the module control unit to carry out corresponding operations.

The vehicle controller is specifically a Micro Control Unit (MCU) in the vehicle, also called a Single Chip Microcomputer (Single Chip Microcomputer) or a Single Chip Microcomputer, and is configured to appropriately reduce the frequency and specification of a Central Processing Unit (CPU), and integrate peripheral interfaces such as a memory (memory), a counter (Timer), a USB, an a/D conversion, a UART, a PLC, a DMA, and even an LCD driving circuit on a Single Chip, so as to form a Chip-level computer, thereby performing different combination control for different application occasions. CAN (Controller Area Network) is applied to an important communication Network of an automobile. The module Control Unit is specifically an Electronic Control Unit (Electronic Control Unit) of each module in the vehicle, is a Control Unit applied to each module of the vehicle, and is also called a traveling computer, a vehicle-mounted computer and the like, and is a special microcomputer controller for the vehicle in terms of application, and consists of a microprocessor (CPU), a memory (ROM and RAM), an input/output interface (I/O), an analog-to-digital converter (a/D), a large-scale integrated circuit for shaping, driving and the like. For example, modular control units in hybrid vehicles include, but are not limited to, a vehicle control unit, an engine controller, a transmission controller, an ABS controller, a driving display, a motor controller, a battery management system, a super capacitor, and an ISG controller.

Because the Binder mechanism is transplanted to the Linux-based vehicle-machine interactive system in advance, the Client and the Server in the vehicle-machine interactive system can perform data transmission through the Binder communication channel constructed by the Binder mechanism, the Client constructed based on Linux is a Binder Client, and the Server constructed based on Linux is a Binder Server.

In an embodiment, as shown in fig. 2, a Linux-based car-machine interaction method is provided, where the method includes the following steps performed by a service side constructed based on Linux:

s201: and acquiring target vehicle machine data from the vehicle controller.

The vehicle controller is a Micro Control Unit (MCU) arranged in the vehicle, and CAN communicate with at least one module control unit through the CAN to acquire vehicle machine data corresponding to each module control unit. The target vehicle machine data is the vehicle machine data which needs to be sent to the client. It can be understood that the target vehicle machine data may be vehicle machine data that is autonomously monitored by the server and needs to be sent to the client, or vehicle machine data that is acquired by the server in real time in response to a request of the client and needs to be sent to the client. The vehicle data includes, but is not limited to, vehicle speed, vehicle voltage, vehicle current, battery level, current fuel quantity, current location, and the like.

S202: and sending the target vehicle machine data to a target client constructed based on Linux through a Binder communication channel.

The Binder communication channel is a channel which is established between a Binder server and a Binder client and is used for realizing the communication between the two parties by adopting a Binder mechanism. Because the Binder communication channel is built based on a Binder mechanism, compared with the traditional interprocess communication mode (such as socket, pipeline, semaphore, shared memory, message queue and the like), the Binder communication channel has the following functions: (1) and propelling inter-process communication by using a Binder driver. The Binder driver works in a kernel mode of Linux and is responsible for establishing Binder communication between processes so that data can be transmitted between the processes. (2) The transmission performance and the transmission efficiency are improved by sharing the memory, and reference counting and cross-process object reference mapping are introduced for the system object. The method comprises the steps of creating a data receiving cache space through a Binder driver, managing the data receiving cache, and realizing mmap () system call in the Binder driver, wherein the return value of mmap () is the address of a memory mapping in a user space, namely, a return object reference mapping. Because the memory allocated by mmap () is mapped in the user space of the receiver, all the overall effects are equivalent to that the effective load data is directly copied from the user space of the sender to the user space of the receiver once, the step of temporary storage in a kernel is omitted, and the transmission performance is doubled. (3) Allocating a thread pool of each process for the process request, and helping to manage the thread pools by introducing special commands or messages so as to ensure the processing efficiency among the processes (4) to realize synchronous calling among the processes. In the Binder drive, each process has a global receiving queue, also called to-do queue, and stores data packets which are not sent to a specific thread; accordingly, there is a global wait queue in which all threads waiting to receive data from the global receive queue are queued. Each thread has a private to-do queue and stores data packets sent to the thread; each corresponding thread has a respective private waiting queue, and the private waiting queues are specially used for the thread to wait for receiving the data in the self to-do queue, so that the corresponding thread is ensured to be synchronously called among the processes.

The target client is a client which is constructed by adopting Linux and needs to acquire target vehicle machine data, understandably, at least one client is arranged on the client which is in communication connection with the server, only part of the clients need to acquire the target vehicle machine data, the client which needs to acquire the target vehicle machine data is determined as the target client, so that a special private Binder communication channel between the server and the target client is constructed, the server can send the target vehicle machine data to the target client through the Binder communication channel, and the safety and the transmission efficiency of the target vehicle machine data in the transmission process are guaranteed.

In the Linux-based vehicle-machine interaction method provided by this embodiment, the target vehicle-machine data acquired from the vehicle controller is sent to the target client through the Binder communication channel, so as to ensure that the target vehicle-machine data has the advantages of good security, high transmission performance, simplicity, easiness in use and the like in the data transmission process. The concrete points are as follows: in the Binder communication channel, by establishing a private communication channel and adding an identity (such as UID/PID) in a kernel space in the data transmission process of a target vehicle, compared with the traditional interprocess communication mode (such as socket, pipeline, message queue and the like) which depends on an upper layer protocol, the safety is better. In the Binder communication channel, the transmission performance is improved by sharing the memory, so that the memory is copied only once in the communication process; and moreover, the progress communication is promoted through the Binder driver, so that the control mechanism is simple and convenient, and the data transmission performance of the target car machine is improved. When the data of the target vehicle machine is transmitted through the Binder communication channel, the Binder shields a communication gap between the client and the server, so that the client calls an interface function of the server, such as local function call, and the process of acquiring the data of the target vehicle machine sent by the server by the target client is simple and easy to operate.

In an embodiment, as shown in step S201, the target car machine data includes monitored car machine data, where the monitored car machine data refers to car machine data monitored by the server through the Binder data monitoring interface, and is one of the car machine data that needs to be sent to the client in the foregoing embodiments. As shown in fig. 3, the Linux-based vehicle-mounted device interaction method specifically includes the following steps:

s301: and acquiring the monitored vehicle machine data corresponding to the Binder data monitoring interface from the vehicle controller by adopting the Binder data monitoring interface.

The Binder data monitoring interface is an interface which is arranged on the service end and used for realizing a data monitoring function, and the Binder data monitoring interface is a Binder function interface which is stored in a Binder library and used for realizing the data monitoring function. It can be understood that, when the Binder mechanism is transplanted to the Linux-based car-machine interactive system, a service end needs to register a car-machine interactive service (AddService) to a Servicemanager (i.e., a service manager), so that the car-machine interactive system can realize the car-machine interactive service; correspondingly, developers of the vehicle-machine interaction system also correspondingly develop a Binder data monitoring interface capable of realizing a data monitoring function so as to monitor vehicle-machine data in vehicles.

In this embodiment, the server may set at least one Binder data monitoring interface, where each Binder data monitoring interface is used to monitor data of a specific type, that is, each Binder data monitoring interface corresponds to a monitoring data identifier, and the monitoring data identifier is an identifier used to uniquely identify data that needs to be monitored. The monitored data identifier may be represented by an english name of data to be monitored or a preset identifier corresponding to the english name, such as vehicle speed, vehicle voltage, vehicle current, battery level, current fuel amount, and current location. Namely, the server can set but not limited to a Binder data monitoring interface corresponding to the monitoring data identifications for collecting vehicle speed, vehicle voltage, vehicle current, battery power, current oil quantity, current position and the like, so as to collect the monitoring vehicle machine data corresponding to the monitoring data identifications for collecting vehicle speed, vehicle voltage, vehicle current, battery power, current oil quantity, current position and the like, and feed back the monitoring vehicle machine data to the corresponding client.

In this embodiment, a Binder data monitoring interface is adopted, and monitored car machine data corresponding to the Binder data monitoring interface is obtained from a car controller, specifically: (1) the server side triggers a monitoring instruction through a Binder data monitoring interface and sends the monitoring instruction to a vehicle controller; (2) the vehicle controller receives the monitoring instruction and sends the monitoring instruction to the corresponding module control unit through the CAN; (3) the module control unit acquires the monitored vehicle machine data in real time according to the monitoring instruction and sends the monitored vehicle machine data to the vehicle controller through the CAN; (4) the vehicle controller receives the monitored vehicle machine data and sends the monitored vehicle machine data to the server. The service end communicates with the vehicle controller, and the vehicle controller communicates with the module control unit through the CAN, so that the service end CAN acquire monitoring vehicle machine data corresponding to different monitoring data identifiers in real time.

Further, since the vehicle controller and the module control unit communicate via the CAN, and the vehicle controller and the server may communicate via HTTP or other protocols, in order to ensure feasibility of the communication process, during the data transmission process, corresponding data conversion processing needs to be performed, that is, in the above (2), after the vehicle controller receives the monitoring instruction, the vehicle controller needs to process the monitoring instruction using the message generation template to generate a corresponding monitoring CAN message, and send the monitoring CAN message to the corresponding module control unit via the CAN, so that the module control unit obtains an identifiable and executable instruction (i.e., an instruction corresponding to the monitoring CAN message) to ensure operability of the operation. The message generation template is a preset template for generating the CAN message. Correspondingly, in the above (4), the vehicle controller receives the result CAN message, and analyzes the result CAN message by using the message analysis template, so as to obtain the monitored vehicle machine data which CAN be identified by the server. The message analysis template is a preset template for analyzing the CAN message, and corresponds to the message generation template.

S302: and if the monitored vehicle machine data is different from the cached vehicle machine data in the Binder shared cache, updating the cached vehicle machine data by adopting the monitored vehicle machine data, and sending the monitored vehicle machine data to a target client side which is constructed based on Linux and is registered with a Binder data monitoring interface through a Binder communication channel.

The Binder shared cache is a user space shared between the Binder server and the Binder client, so that the transmission performance of data transmission between the Binder server and the Binder client is improved through the Binder shared memory. The cached car machine data is the car machine data which is collected last time and stored in the Binder shared cache and corresponds to the monitoring data identification.

The target client registering the Binder data monitoring interface specifically means that the target client registers the Binder data monitoring interface at the server in advance, and the server sends the vehicle-machine data monitored by the Binder data monitoring interface to the target client in real time, so that the target client can acquire recently updated monitored vehicle-machine data in real time.

Specifically, after acquiring the monitored car machine data from the vehicle controller, the server side firstly acquires the cached car machine data which is acquired and stored last time by the Binder data monitoring interface from the Binder shared cache, and judges whether the monitored car machine data is the same as the cached car machine data; when the monitored car machine data is the same as the cached car machine data, the real-time performance of the cached car machine data in the Binder shared cache can be guaranteed without processing the cached car machine data in the Binder shared cache; and when the monitored car machine data is different from the cached car machine data, updating the cached car machine data by adopting the monitored car machine data so as to enable the cached car machine data in the Binder shared cache to be the car machine data which is recently acquired by the corresponding Binder data monitoring interface. In this embodiment, when the monitored car machine data is different from the cached car machine data, the cached car machine data is updated by using the monitored car machine data to ensure the real-time performance of the cached car machine data in the Binder shared cache, so that the recently updated car machine data can be quickly acquired when the Binder shared cache is subsequently accessed, and the acquisition efficiency of the monitored car machine data is improved.

It can be understood that when the monitored car machine data is different from the cached car machine data in the Binder shared cache, it indicates that the car machine data corresponding to the same monitored data identifier monitored by the Binder data monitoring interface twice is different, that is, the vehicle state corresponding to the module control unit corresponding to the monitored data identifier changes, and therefore, the monitored car machine data needs to be sent to the target client registered with the Binder data monitoring interface, so that the user can know the corresponding vehicle state change situation through the target client in time. In the embodiment, the server side sends the data of the monitor car machine to the target client side which is constructed based on Linux and is registered with the Binder data monitoring interface through the Binder communication channel, so that the monitor car machine has the advantages of good safety, high transmission performance, simplicity, easiness in use and the like in the data transmission process.

It should be understood that step S301 is a specific implementation of step S201 in the foregoing embodiment, and step S302 is a specific implementation of step S202 in the foregoing embodiment, that is, in steps S301 and S302, the server autonomously listens to the car monitor data in the vehicle, and sends the car monitor data to the corresponding target client.

In the Linux-based vehicle-machine interaction method provided by the embodiment, a Binder data monitoring interface is adopted to acquire corresponding monitored vehicle-machine data from a vehicle controller so as to monitor the vehicle-machine data in the vehicle; when the monitored car machine data is different from the cached car machine data, the cached car machine data is updated by the monitored car machine data to ensure the real-time performance of the cached car machine data in the Binder shared cache, and the monitored car machine data is sent to the target client through the Binder communication channel, so that the monitored car machine data has the advantages of good safety, high transmission performance, simplicity, easiness and the like in the data transmission process, and the target client registered with the Binder data monitoring interface can acquire the recently updated monitored car machine data in real time.

In an embodiment, the Binder data monitoring interface inherits the Binder function interface transplanted from the Binder library, specifically, an interface formed by a callback function (i.e., autocalback) of a package Binder structure is used for monitoring whether the vehicle state changes. Because the service runs in a single process, when the target client registers the Binder data monitoring interface, a Binder data monitoring interface formed by a callback function (namely, autocalBack) for packaging a Binder structure is respectively established at the service end and the target client, and a special Binder communication channel is established between the two Binder data monitoring interfaces; when the Binder data monitoring interface of the server side acquires the monitored car machine data and the monitored car machine data is different from the cached car machine data, the parameter value of the callback function (namely, AutoCallBack) is changed, and the callback function (namely, AutoCallBack) of the Binder data monitoring interface of the target client side receives the changed parameter value through the special Binder communication channel, so that the monitored car machine data is sent to the target client side; the folder can shield the gap of the folder client for calling the folder server, so that the function name, the parameter name and the parameter value in the target client are the same as those of the folder server, the folder client calls the data corresponding to the folder server like a local function call, and the operation is simpler and easier to use.

In an embodiment, before step S301, that is, before obtaining the monitored car machine data corresponding to the Binder data monitoring interface from the vehicle controller by using the Binder data monitoring interface, the Linux-based car machine interaction method further includes:

s301-1: the method comprises the steps of obtaining an interface registration request sent by a target client, wherein the interface registration request comprises an interface identifier and a terminal identifier.

S301-2: and storing the interface identification and the terminal identification in a registered interface information table in an associated manner.

The interface registration request is a request sent by a target client to a server and used for monitoring interface registration. The interface identifier is an identifier for uniquely identifying the Binder data listening interface to be registered. The terminal identification is an identification for uniquely identifying a target client to be registered. The registered interface information table is an information table for storing the association relationship between the interface identifier and the terminal identifier in all the interface registration requests.

In this embodiment, a user may input a corresponding interface identifier through an interface registration interface of a target client (i.e., a client used by the user), form an interface registration request according to a terminal identifier carried by the user and the interface identifier, and send the interface registration request to a server, so that the server may obtain the interface registration request of the target client. After the server side obtains the interface registration request, the server side analyzes the interface registration request to obtain an interface identifier and a terminal identifier in the interface registration request, and the interface identifier and the terminal identifier are stored in a registration interface information table in an associated mode to achieve unified management of the interface identifier and the terminal identifier which have an associated relation.

In step S302, sending the monitored car machine data to the target client registered with the Binder data monitoring interface, which is constructed based on Linux, through the Binder communication channel includes:

s302-1: and inquiring a registration interface information table according to the interface identifier of the Binder data monitoring interface to obtain the corresponding target terminal identifier.

S302-2: and sending the data of the monitor car machine to a target client which is constructed based on Linux and corresponds to the target terminal identification through a Binder communication channel.

Specifically, the server side can query a pre-stored registration interface information table of the server side according to an interface identifier corresponding to each Binder data monitoring interface, and can quickly determine a target terminal identifier associated with the interface identifier of the Binder data monitoring interface, so as to determine that a target client side corresponding to the target terminal identifier registers the Binder data monitoring interface in advance; after the target terminal identification is determined, the data of the monitor car machine is sent to a target client which is constructed based on Linux and corresponds to the target terminal identification through a Binder communication channel, so that the target client which registers a Binder data monitoring interface in advance can timely acquire the data of the monitor car machine which is different from the data of the cache car machine, and the safety and the transmission performance (namely the transmission efficiency) of the monitor car machine in the data transmission process are ensured.

In the Linux-based vehicle-machine interaction method provided by the embodiment, the server stores the interface identifier and the terminal identifier in the interface registration request in the registration interface information table in an associated manner, so that the interface identifier and the terminal identifier in the interface registration request can be uniformly managed; when the Binder data monitoring interface acquires the monitored car machine data different from the cached car machine data, the corresponding target terminal identification can be quickly acquired through the registration interface information table, so that the monitored car machine data can be sent to the target client corresponding to the target terminal identification through the Binder communication channel, the monitored car machine data different from the cached car machine data can be timely acquired, and the safety and the transmission performance in the data transmission process of the monitored car machine are guaranteed.

In an embodiment, before step S301, before obtaining, by using the Binder data monitor interface, monitored car machine data corresponding to the Binder data monitor interface from the vehicle controller, the Linux-based car machine interaction method further includes:

s301-1': and acquiring a monitoring task creating request, wherein the monitoring task creating request comprises a monitoring data identifier.

The listening task creating request is a request for triggering the server to create the listening task. The monitored data identifier refers to a data identifier corresponding to data to be monitored by the monitoring task creation request, and may specifically be, but not limited to, a monitored data identifier such as a vehicle speed, a vehicle voltage, a vehicle current, a battery level, a current oil amount, and a current position. It can be understood that a user (e.g., a developer) may trigger the monitor task creation request through a monitor task configuration interface reserved by the vehicle-machine interactive system according to an actual requirement (i.e., according to a monitor data identifier corresponding to data to be monitored), so that the server may obtain the corresponding monitor task creation request. For example, on the car machine interactive system, a user can enter a monitoring task configuration interface by clicking a monitoring task configuration interface on a client, and the user can input a corresponding monitoring data identifier on the task configuration interface and trigger a monitoring task creation request after confirming submission.

S301-2': and processing the monitoring data identifier by adopting a data monitoring class constructed based on a Binder mechanism to obtain a Binder data monitoring interface.

The data monitoring class constructed based on the Binder mechanism is a Binder function interface for realizing a data monitoring function, and the data monitoring class is constructed based on the Binder mechanism, so that the data monitoring class can be applied to a Binder client and a Binder server, and the calling of the data monitoring class is more convenient and easier in the communication process of the Binder client and the Binder server.

Specifically, the data monitoring class constructed based on the Binder mechanism may be a Binder functional interface transplanted from a Binder library and used for implementing data monitoring, and the data monitoring class constructed based on the Binder mechanism may be used to process the monitored data identifier, so as to create a Binder data monitoring interface dedicated to monitoring data corresponding to the monitored data identifier. That is, in this embodiment, the Binder data monitoring interface inherits the data monitoring class constructed based on the Binder mechanism, so that the creation process is simple and convenient.

S301-3': and acquiring the data updating frequency corresponding to the monitoring data identification from the vehicle controller.

The data updating frequency corresponding to the monitoring data identification is the frequency corresponding to the monitoring data identification acquired by each module control unit acquired by the vehicle controller. It can be understood that the data update frequency corresponding to each monitored data identifier matches the update speed of the corresponding data in the vehicle, and the data update frequencies corresponding to any two monitored data identifiers may be the same or different. For example, if the monitored data is identified as the battery level, the server may send a corresponding update frequency acquisition request to the vehicle controller, so that the server may acquire the data update frequency of the battery level from the vehicle controller.

S301-4': and generating a data monitoring task corresponding to the monitoring data identifier based on the data updating frequency and the Binder data monitoring interface.

The data monitoring task is used for realizing data monitoring, and is applied to the server side, so that the server side can acquire the monitored vehicle machine data of the vehicle in real time according to the data monitoring task. Specifically, after acquiring the data updating frequency and the Binder data monitoring interface, the server can adopt a default starting time of a system or a starting time set by a user independently, and quickly generate a data monitoring task corresponding to the monitored data identifier according to the starting time, the data updating frequency and the Binder data monitoring interface, so that the server starts at the starting time and monitors the monitored vehicle machine data corresponding to the monitored data identifier in real time by adopting the Binder data monitoring interface according to the data updating frequency.

Correspondingly, step S301, namely, obtaining the monitor car machine data corresponding to the Binder data monitor interface from the car controller by using the Binder data monitor interface, specifically includes: and executing a data monitoring task, and acquiring the monitored vehicle machine data corresponding to the Binder data monitoring interface from the vehicle controller by adopting the Binder data monitoring interface according to the data acquisition frequency.

In this embodiment, the server executes the pre-created data monitoring tasks in real time, and acquires the monitored car machine data corresponding to the Binder data monitoring interface from the car controller by using the Binder data monitoring interface in each data monitoring task according to the data acquisition frequency corresponding to each data monitoring task, so as to implement autonomous monitoring of the car machine data of the car. Specifically, after the initial time set by the data monitoring task, the server acquires corresponding monitored vehicle machine data according to the data acquisition frequency, so that the vehicle machine data corresponding to the monitored data identifier is monitored in real time, and the real-time performance of the data is ensured.

In the Linux-based vehicle-machine interaction method provided by the embodiment, the monitoring data identifier in the monitoring task creation request is processed by using the transplanted data monitoring class constructed based on the Binder mechanism, so that the Binder data monitoring interface corresponding to the monitoring data identifier can be quickly obtained, and the creation process is simple and convenient; the data updating frequency corresponding to the monitoring data identification is obtained from the vehicle controller, and the corresponding data monitoring task is generated by combining with the Binder data monitoring interface, so that the corresponding monitoring vehicle machine data can be obtained from the vehicle controller by adopting the Binder data monitoring interface according to the data acquisition frequency when the data monitoring task is executed, and thus, the real-time monitoring of the monitoring vehicle machine data corresponding to different monitoring data identifications is realized according to the data updating frequency, and the real-time performance of monitoring the monitoring vehicle machine data corresponding to the monitoring data identification is ensured.

In an embodiment, as shown in step S201, the target car machine data may be car machine data that is acquired by the server according to the request of the client and needs to be sent to the client. In this case, as shown in fig. 4, the Linux-based vehicle-mounted device interaction method specifically includes the following steps:

s401: and receiving a vehicle-machine interaction request sent by a target client constructed based on Linux through a Binder communication channel.

The vehicle-machine interaction request is a request triggered by a client and used for requesting the interaction of vehicle-machine data with a server. The target client can be understood as the client triggering the vehicle-machine interaction request. The user can trigger the vehicle-machine interaction request through an interaction interface provided by a target client constructed based on Linux according to actual requirements, and the vehicle-machine interaction request is sent to the server through the Binder communication channel, so that the server can receive the vehicle-machine interaction request sent by the target client through the Binder communication channel, and subsequent steps are carried out.

In this embodiment, the server receives the car machine interaction request triggered by the target client through the Binder communication channel, which indicates that the car machine interaction request is transmitted under the Binder communication channel, and can ensure the security and transmission performance in the transmission process of the car machine interaction request. Specifically, a bpauttoverver interface that inherits a Binder function interface (such as an AutoServer interface) is set in the target client, and a user can obtain an agent (i.e., an agent for the class) of the server through a Servicemanager, thereby using the Servicemanager interface corresponding to the car machine interaction service. The process of obtaining the agent is realized in the AutoManager, that is, the AutoManager encapsulates various interfaces for realizing the AutoServer and the autocalback, provides an equivalent interface for a developer, provides a registered AutoObserver interface, and receives the message of the autocalback. The server sets a BnAuutoServer interface which inherits a Binder functional interface (such as an AutoServer interface), services corresponding to the BnAuutoServer interface adopt a Binder structure, run on an independent process, and can be registered in a Servicemanager. It can be understood that the vehicle-machine interaction request triggered by the target client is sent to the bnauttoverer interface of the server through the bpauttoverer interface, that is, a Binder communication channel for data transmission is constructed through the bpauttoverer interface and the bnauttoverer interface, so that the vehicle-machine interaction request is transmitted through the Binder communication channel.

In the current vehicle-machine interactive system, in order to enable a user to control a vehicle through a client, the following functions need to be realized through the client: one of the functions is a data query function, that is, a user may query vehicle data corresponding to a current state of a vehicle through a client, where the vehicle data includes but is not limited to vehicle speed, vehicle voltage, vehicle current, battery level, current oil amount, current position, and the like, so that the user may perform subsequent operations according to the queried vehicle data, such as performing a charging operation when the battery level is low. The other is a vehicle control function, that is, a user can control a corresponding module control unit in a vehicle to perform an operation through a client, such as controlling operations of opening, closing or locking a vehicle door or a vehicle window, or controlling operations of opening, closing or adjusting temperature of an air conditioner. It can be understood that the target client and the server can perform vehicle-machine interaction only if the target client has a data query function and a vehicle control function, so as to realize corresponding control of the vehicle. In this embodiment, the vehicle-machine interaction request triggered by the target client and capable of implementing the data query function is specifically a Get request triggered through a Get interface; the vehicle-machine interaction request which is triggered by the target client and can realize the vehicle control function is specifically a Set request triggered by a Set interface.

S402: and sending the vehicle-machine interaction request to a vehicle controller, and receiving target vehicle-machine data corresponding to the vehicle-machine interaction request returned by the vehicle controller.

Specifically, the server sends a vehicle-machine interaction request to a vehicle controller; after receiving the vehicle-machine interaction request, the vehicle controller sends the vehicle-machine interaction request to a corresponding module control unit through the CAN; the module control unit acquires corresponding target vehicle machine data according to the vehicle machine interaction request and sends the target vehicle machine data to the vehicle controller; and after receiving the corresponding target vehicle machine data, the vehicle controller sends the target vehicle machine data to the server, so that the server can receive the target vehicle machine data corresponding to the vehicle machine interaction request returned by the vehicle controller. It is understood that the communication process between the server and the vehicle controller (and the module control unit connected via the CAN) is similar to the communication process in step S301, and therefore, for avoiding repetition, the detailed description is omitted here.

Accordingly, the target vehicle machine data acquired in this embodiment may be queried vehicle machine data related to the data query function (i.e., data acquired by a corresponding module control unit in the vehicle in real time, such as battery level), or vehicle machine data related to the vehicle control function and used for reflecting vehicle state changes (e.g., vehicle machine data formed by two state change processes of turning on and turning off an air conditioner).

S403: and sending the target vehicle machine data to a target client constructed based on Linux through a Binder communication channel.

It is understood that steps S401 and S402 are another specific example of step S201 in the above embodiment, and step S403 is the same as step S202 in the above embodiment, and therefore, for avoiding repetition, the description is omitted here.

In the Linux-based vehicle-machine interaction method provided by the embodiment, the target client triggers the vehicle-machine interaction request to enable the server to return corresponding target vehicle-machine data, so that a user can control a vehicle through the target client, and the vehicle can meet the requirement of intelligent control; the vehicle-machine interaction request and the corresponding target vehicle-machine data are transmitted through the Binder communication channel, and the safety and the transmission performance of the vehicle-machine interaction request and the corresponding target vehicle-machine data in the data transmission process can be effectively guaranteed.

In an embodiment, as shown in step S401 above, the car machine interaction request triggered by the target client may be a car machine interaction request that can implement a data query function, that is, a Get request, and for the Get request, as shown in fig. 5, the Linux-based car machine interaction method specifically includes the following steps:

s501: and receiving a vehicle machine query request sent by a target client constructed based on Linux through a Binder communication channel, wherein the vehicle machine query request comprises a target data identifier.

The vehicle machine query request is a request triggered by a client and used for querying vehicle machine data, and the request is a Get request. The target data identification is an identification used for uniquely identifying data required to be inquired by the target data identification, and can be an identification used for uniquely pointing to vehicle-machine data such as vehicle speed, vehicle voltage, vehicle current, battery level, current oil quantity and current position. For example, if the system defaults to adopt Q1 to represent the battery power, a target client constructed based on Linux may trigger a vehicle inquiry request carrying Q1, and send the vehicle inquiry request to a server through a Binder communication channel, so that the server can quickly obtain the corresponding vehicle inquiry request. The vehicle machine query request is transmitted through the Binder communication channel, so that the security and the transmission performance in the transmission process are guaranteed, and the operation simplicity is realized.

S502: and sending the vehicle machine query request to a vehicle controller, and receiving target vehicle machine data which is returned by the vehicle controller and is collected in real time by a module control unit corresponding to the target data identifier.

Specifically, after receiving a vehicle machine query request, the server sends the vehicle machine query request to a vehicle controller; the vehicle controller determines a module control unit for acquiring vehicle machine data corresponding to a target data identifier according to the target data identifier in the vehicle machine query request, sends a data acquisition instruction to the module control unit to receive the target vehicle machine data corresponding to the target data identifier acquired by the module control unit in real time, and then sends the target vehicle machine data to the server so that the server receives the corresponding target vehicle machine data, thereby achieving the purpose of querying the corresponding target vehicle machine data in real time.

S503: and sending the target vehicle machine data to a target client constructed based on Linux through a Binder communication channel.

It should be understood that step S501 is a specific implementation of step S401 in the foregoing embodiment, step S502 is another specific implementation of step S402 in the foregoing embodiment, and step S503 is the same as step S403 in the foregoing embodiment, and is not repeated herein to avoid repetition.

In the Linux-based vehicle-machine interaction method provided by this embodiment, the target client triggers the vehicle-machine query request to enable the server to return target vehicle-machine data corresponding to the target data identifier in the vehicle-machine query request, so that the current target vehicle-machine data of the vehicle is obtained in real time through the target client, and subsequent vehicle control is performed according to the queried target vehicle-machine data; the vehicle inquiry request and the corresponding target vehicle machine data are transmitted through the Binder communication channel, so that the safety and the transmission performance of the vehicle inquiry request and the corresponding target vehicle machine data in the data transmission process can be effectively guaranteed.

In an embodiment, as shown in step S401 above, the car machine interaction request triggered by the target client may be a car machine interaction request that can implement a vehicle control function, that is, a Set request, and for the Set request, as shown in fig. 6, the Linux-based car machine interaction method specifically includes the following steps:

s601: and receiving a vehicle control request sent by a target client constructed based on Linux through a Binder communication channel, wherein the vehicle control request comprises a target module identifier and an operation identifier.

The vehicle control request is a request triggered by a client and used for vehicle control, and the request is a Set request. The target module identification is an identification for uniquely identifying the module control unit corresponding to the vehicle control of this time. The operation identifier is an identifier for uniquely identifying a specific operation corresponding to the current vehicle control. For example, if the user can control the air conditioner in the vehicle to be opened through the target client, in the vehicle control request triggered by the user, the target module identifier is specifically an identifier corresponding to the air conditioner, and the operation identifier is specifically an identifier corresponding to the opening. The vehicle control request is transmitted through the Binder communication channel, so that the safety and the transmission performance in the transmission process are guaranteed, and the operation simplicity is realized.

S602: and sending the vehicle control request to the vehicle-mounted machine controller so as to enable the vehicle controller to control the module control unit corresponding to the target module identifier to execute the target operation corresponding to the operation identifier.

Specifically, after receiving the vehicle control request, the service end sends the vehicle control request to the vehicle controller; the vehicle controller sends the vehicle control request to the module control unit corresponding to the target module identification so as to enable the module control unit to execute the target operation corresponding to the operation identification. In the above embodiment, after the server sends the vehicle control request to the vehicle controller, the vehicle controller determines that the corresponding module control unit is the air-conditioning control unit according to the target module identifier, and then sends the vehicle control request to the air-conditioning control unit, so that the air-conditioning control unit performs an opening operation to realize intelligent control of the vehicle.

S603: and monitoring the current car machine data to be different from the cached car machine data in the Binder shared cache through a Binder data monitoring interface corresponding to the target module identifier to generate target car machine data.

The Binder data monitoring interface corresponding to the target module identifier can be understood as a monitoring interface specially used for monitoring the vehicle state change of the module control unit corresponding to the target module identifier. The cached car machine data in this embodiment is car machine data acquired by the module control unit corresponding to the target module identifier that was acquired last time and stored in the Binder shared cache.

Specifically, after sending a vehicle control request to a vehicle controller, a server monitors current car machine data capable of reflecting vehicle state changes corresponding to a module control unit corresponding to a target module identifier in real time through a Binder data monitoring interface corresponding to the target module identifier, generates target car machine data when the current car machine data is different from cached car machine data in a Binder shared cache, and updates the cached car machine data by using the current car machine data, so that the cached car machine data in the Binder shared cache is car machine data recently acquired by the corresponding Binder data monitoring interface. The Binder data monitoring interface in this embodiment is the same as the Binder data monitoring interface in the above embodiments in working process, and is not described herein again to avoid repetition.

It can be understood that the target vehicle machine data is vehicle machine data reflecting vehicle state changes, that is, vehicle machine data different from the last acquired cached vehicle machine data. For example, Y is used for opening, N is used for closing, and before the server sends the vehicle control request to the vehicle controller, the buffer vehicle machine data monitored by the Binder data monitoring interface is N; after the vehicle control request is sent to the vehicle controller, if the module control unit corresponding to the vehicle controller control target module identifier executes the target operation corresponding to the operation identifier, at this time, the current vehicle-mounted device data monitored by the Binder data monitoring interface is Y.

S604: and sending the target vehicle machine data to a target client constructed based on Linux through a Binder communication channel.

It is to be understood that step S601 is a specific implementation of step S401 in the foregoing embodiment, S602 and S603 are another specific implementation of step S402 in the foregoing embodiment, and step S604 is the same as step S403 in the foregoing embodiment, and is not repeated herein to avoid repetition.

In the Linux-based vehicle-machine interaction method provided by the embodiment, a target client triggers a vehicle control request, a vehicle controller controls a corresponding module control unit to execute target operation through a server, and a Binder data monitoring interface is adopted to monitor target vehicle-machine data in real time to determine whether vehicle control is finished or not, so that the vehicle is controlled, and the purpose of intelligently controlling the vehicle is achieved; the vehicle control request and the corresponding target vehicle machine data are transmitted through the Binder communication channel, and the safety and the transmission performance of the vehicle control request and the corresponding target vehicle machine data in the data transmission process can be effectively guaranteed.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

In an embodiment, a Linux-based vehicle-mounted device interaction apparatus is provided, and the Linux-based vehicle-mounted device interaction apparatus corresponds to the Linux-based vehicle-mounted device interaction method in the above embodiments one to one. As shown in fig. 7, the Linux-based vehicle-mounted device interaction apparatus includes a vehicle-mounted data obtaining module 701 and a vehicle-mounted data transmission module 702. The functional modules are explained in detail as follows:

and the vehicle-machine data acquisition module 701 is used for acquiring target vehicle-machine data from the vehicle controller.

And the vehicle-machine data transmission module 702 is used for sending the target vehicle-machine data to a target client constructed based on Linux through the Binder communication channel.

Preferably, the target car machine data comprises listener car machine data.

The car machine data acquisition module 701 comprises a car machine monitoring data acquisition unit, and is used for acquiring car machine monitoring data corresponding to the Binder data monitoring interface from the car controller by using the Binder data monitoring interface.

The car machine data transmission module 702 comprises a monitor car machine data transmission unit, and is configured to update the cached car machine data with the monitor car machine data if the monitored car machine data is different from the cached car machine data in the Binder shared cache, and send the monitored car machine data to a target client registered with the Binder data monitoring interface, which is constructed based on Linux, through the Binder communication channel.

Preferably, before the monitoring vehicle-mounted device data obtaining unit, the Linux-based vehicle-mounted device interaction device further comprises a registration request obtaining unit and a registration information storage unit.

And the registration request acquisition unit is used for acquiring an interface registration request sent by the target client, wherein the interface registration request comprises an interface identifier and a terminal identifier.

And the registration information storage unit is used for storing the interface identifier and the terminal identifier in a registration interface information table in an associated manner.

And the monitor vehicle machine data transmission unit comprises a terminal identification inquiry subunit and a vehicle machine data sending subunit.

And the terminal identifier inquiry subunit is used for inquiring the registration interface information table according to the interface identifier of the Binder data monitoring interface and acquiring the corresponding target terminal identifier.

And the vehicle-machine data sending subunit is used for sending the monitored vehicle-machine data to a target client which is constructed based on Linux and corresponds to the target terminal identifier through the Binder communication channel.

Preferably, before the monitor car machine data obtaining unit, the Linux-based car machine interaction device further includes a creation request obtaining unit, a monitor interface obtaining unit, an update frequency obtaining unit, and a monitor task generating unit.

And the creation request acquisition unit is used for acquiring the interception task creation request, and the interception task creation request comprises an interception data identifier.

And the monitoring interface acquisition unit is used for processing the monitoring data identifier by adopting a data monitoring class constructed based on the Binder mechanism to acquire a Binder data monitoring interface.

And the updating frequency acquiring unit is used for acquiring the data updating frequency corresponding to the monitoring data identification from the vehicle controller.

And the monitoring task generating unit is used for generating a data monitoring task corresponding to the monitoring data identifier based on the data updating frequency and the Binder data monitoring interface.

And the monitor vehicle machine data acquisition unit is used for executing a data monitoring task and acquiring monitor vehicle machine data corresponding to the Binder data monitoring interface from the vehicle controller by adopting the Binder data monitoring interface according to the data acquisition frequency.

Preferably, the car machine data obtaining module 701 includes a car machine interaction request receiving unit and a target car machine data obtaining unit.

And the vehicle-machine interaction request receiving unit is used for receiving a vehicle-machine interaction request sent by a target client side constructed based on Linux through a Binder communication channel.

And the target vehicle machine data acquisition unit is used for sending the vehicle machine interaction request to the vehicle controller and receiving target vehicle machine data corresponding to the vehicle machine interaction request returned by the vehicle controller.

Preferably, the car machine interaction request receiving unit includes a car machine query request receiving subunit, configured to receive a car machine query request sent by a target client constructed based on Linux through a Binder communication channel, where the car machine query request includes a target data identifier.

And the target vehicle machine data acquisition unit comprises a vehicle machine data query subunit and is used for sending the vehicle machine query request to the vehicle controller and receiving the target vehicle machine data which is returned by the vehicle controller and is acquired in real time by the module control unit corresponding to the target data identifier.

Preferably, the vehicle-machine interaction request receiving unit includes a vehicle control request receiving subunit, configured to receive a vehicle control request sent by a target client constructed based on Linux through a Binder communication channel, where the vehicle control request includes a target module identifier and an operation identifier.

And the target vehicle machine data acquisition unit comprises a vehicle control processing subunit and a vehicle machine data generation subunit.

And the vehicle control processing subunit is used for sending the vehicle control request to the vehicle-mounted machine controller so as to enable the module control unit corresponding to the vehicle controller control target module identifier to execute the target operation corresponding to the operation identifier.

And the vehicle machine data generating subunit is used for generating target vehicle machine data when the current vehicle machine data is monitored to be different from the cached vehicle machine data in the Binder shared cache through the Binder data monitoring interface corresponding to the target module identifier.

For specific limitations of the Linux-based vehicle-mounted device interaction apparatus, reference may be made to the above limitations of the Linux-based vehicle-mounted device interaction method, which is not described herein again. All or part of each module in the Linux-based vehicle-mounted interaction device can be realized through software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in fig. 8. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing data adopted or formed in the process of executing the Linux-based vehicle-machine interaction method. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to realize the Linux-based vehicle-mounted device interaction method.

In an embodiment, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and when the processor executes the computer program, the Linux-based car-machine interaction method in the foregoing embodiments is implemented, for example, as shown in S201-S202 in fig. 2, or as shown in fig. 3 to 6, which is not described herein again to avoid repetition. Alternatively, when executing the computer program, the processor implements the functions of each module/unit in the Linux-based vehicle-mounted device in this embodiment, for example, the functions of the vehicle-mounted device data acquisition module 701 and the vehicle-mounted device data transmission module 702 shown in fig. 7, and for avoiding repetition, details are not described here again.

In an embodiment, a computer-readable storage medium is provided, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the Linux-based vehicle-machine interaction method in the foregoing embodiments is implemented, for example, as shown in S201-S202 in fig. 2, or as shown in fig. 3 to fig. 6, which is not described herein again to avoid repetition. Alternatively, when being executed by a processor, the computer program implements the functions of each module/unit in the above Linux-based vehicle-mounted device, for example, the functions of the vehicle-mounted data acquisition module 701 and the vehicle-mounted data transmission module 702 shown in fig. 7, and are not described herein again to avoid repetition.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present invention, and are intended to be included within the scope of the present invention.

Claims

1. A vehicle-mounted interaction method based on Linux is characterized by comprising the following steps executed by a service side constructed based on Linux:

acquiring target vehicle machine data from a vehicle controller;

2. The Linux-based car machine interaction method of claim 1, wherein the target car machine data comprises listener car machine data;

the target vehicle machine data is obtained from the vehicle controller, and the method comprises the following steps:

adopting a Binder data monitoring interface to acquire monitored vehicle machine data corresponding to the Binder data monitoring interface from a vehicle controller;

the sending the target vehicle machine data to a target client constructed based on the Linux through a Binder communication channel comprises the following steps:

and if the monitored vehicle machine data is different from the cached vehicle machine data in the Binder shared cache, updating the cached vehicle machine data by adopting the monitored vehicle machine data, and sending the monitored vehicle machine data to a target client which is constructed based on the Linux and is registered with the Binder data monitoring interface through a Binder communication channel.

3. The Linux-based car machine interaction method of claim 2, wherein before the obtaining of the monitored car machine data corresponding to the Binder data monitor interface from the car controller using the Binder data monitor interface, the Linux-based car machine interaction method further comprises:

acquiring an interface registration request sent by a target client, wherein the interface registration request comprises an interface identifier and a terminal identifier;

storing the interface identification and the terminal identification in a registered interface information table in an associated manner;

the sending the data of the monitor car machine to a target client which is constructed based on the Linux and is registered with the Binder data monitoring interface through a Binder communication channel comprises the following steps:

inquiring the registration interface information table according to the interface identifier of the Binder data monitoring interface to obtain a corresponding target terminal identifier;

and sending the data of the monitor car machine to a target client which is constructed based on the Linux and corresponds to the target terminal identification through a Binder communication channel.

4. The Linux-based car machine interaction method of claim 2, wherein before the obtaining of the monitored car machine data corresponding to the Binder data monitor interface from the car controller using the Binder data monitor interface, the Linux-based car machine interaction method further comprises:

acquiring a monitoring task creating request, wherein the monitoring task creating request comprises a monitoring data identifier;

processing the monitoring data identification by adopting a data monitoring class constructed based on a Binder mechanism to obtain a Binder data monitoring interface;

acquiring data updating frequency corresponding to the monitoring data identification from a vehicle controller;

generating a data monitoring task corresponding to the monitoring data identifier based on the data updating frequency and the Binder data monitoring interface;

adopt Binder data monitoring interface, obtain from vehicle controller with the corresponding monitor car machine data of Binder data monitoring interface includes:

and executing the data monitoring task, and acquiring the monitored vehicle machine data corresponding to the Binder data monitoring interface from a vehicle controller by adopting the Binder data monitoring interface according to the data acquisition frequency.

5. The Linux-based vehicle-machine interaction method of claim 1, wherein the obtaining target vehicle-machine data from a vehicle controller comprises:

receiving a vehicle-machine interaction request sent by a target client constructed based on Linux through a Binder communication channel;

and sending the vehicle-machine interaction request to a vehicle controller, and receiving target vehicle-machine data corresponding to the vehicle-machine interaction request returned by the vehicle controller.

6. The Linux-based car-machine interaction method of claim 5, wherein the receiving of the car-machine interaction request sent by the target client built based on Linux through the Binder communication channel comprises:

receiving a vehicle machine query request sent by a target client side constructed based on Linux through a Binder communication channel, wherein the vehicle machine query request comprises a target data identifier;

the sending the vehicle-machine interaction request to a vehicle controller, and receiving target vehicle-machine data returned by the vehicle controller and corresponding to the vehicle-machine interaction request, includes:

and sending the vehicle machine query request to a vehicle controller, and receiving target vehicle machine data which is returned by the vehicle controller and is collected in real time by a module control unit corresponding to the target data identification.

7. The Linux-based car-machine interaction method of claim 5, wherein the receiving of the car-machine interaction request sent by the target client built based on Linux through the Binder communication channel comprises:

receiving a vehicle control request sent by a target client side constructed based on Linux through a Binder communication channel, wherein the vehicle control request comprises a target module identifier and an operation identifier;

sending the vehicle control request to a vehicle-mounted machine controller so that the vehicle controller controls a module control unit corresponding to the target module identifier to execute a target operation corresponding to the operation identifier;

and monitoring the current car machine data to be different from the cached car machine data in the Binder shared cache through the Binder data monitoring interface corresponding to the target module identifier to generate target car machine data.

8. The utility model provides a car machine interaction device based on Linux which specifically is based on the service end that Linux built includes:

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the Linux-based car machine interaction method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the Linux-based car machine interaction method of any one of claims 1 to 7.