Vehicle-mounted middleware, vehicle-mounted middleware data processing method and electronic equipment

Abstract

The invention provides vehicle-mounted middleware, a vehicle-mounted middleware data processing method and electronic equipment, and the vehicle-mounted middleware comprises a hardware abstraction module, a middleware module and a business module: the hardware abstraction module performs pre-classification processing on received hardware equipment data to determine a theme corresponding to the hardware equipment data; the hardware equipment data are classified and packaged based on themes, and the packaged data are published to a middleware module according to the themes; and the middleware module selects a target communication adapter based on a system environment, receives the encapsulated data by using a unified communication mechanism interface of the target communication adapter, and distributes the encapsulated data to a target service processing unit in the service module through a unified interface of the event management unit for processing. By adopting the vehicle-mounted middleware, the vehicle-mounted middleware data processing method and the electronic equipment, the problems of high coupling degree and poor expansibility between services caused by single communication mechanism of the vehicle-mounted middleware are solved.

Description

Technical Field

[0001] The present application relates to the technical field of Internet of Vehicles, and more specifically, to an in-vehicle middleware, an in-vehicle middleware data processing method and an electronic device. Background Art

[0002] With the continuous development of automotive electronic and electrical systems, the demand for communication between vehicle systems is also increasing. Vehicle middleware can provide core functions such as communication, data sharing, and remote procedure calls for upper-level applications, achieving seamless integration between vehicle systems and is an important infrastructure to support automotive intelligence. In order to better serve the communication needs between vehicle systems, higher requirements are placed on the scalability and weak coupling of vehicle middleware.

[0003] However, the communication mechanism adopted by the existing in-vehicle middleware is relatively simple, resulting in high coupling between services and poor scalability. Summary of the invention

[0004] In view of this, the purpose of the present application is to provide an in-vehicle middleware, an in-vehicle middleware data processing method and an electronic device to solve the problem of high coupling between services and poor scalability due to the single communication mechanism of the in-vehicle middleware.

[0005] In a first aspect, an embodiment of the present application provides an in-vehicle middleware, including a hardware abstraction module, a middleware module and a service module, wherein the middleware module includes an event management unit;

[0006] The hardware abstraction module performs pre-classification processing on the received hardware device data to determine the subject corresponding to the hardware device data;

[0007] Classify and encapsulate hardware device data based on topics, and publish the encapsulated data to the middleware module by topic;

[0008] The middleware module selects a target communication adapter based on the system environment, receives encapsulated data using the unified communication mechanism interface of the target communication adapter, and distributes the encapsulated data to the target business processing unit in the business module through the unified interface of the event management unit for processing.

[0009] Optionally, the topic includes a parent topic and a sub-topic, and the hardware abstraction module determines the topic corresponding to the hardware device data through the following processing: using the communication matrix table to determine the sub-topic corresponding to the hardware device data; based on the mapping relationship between the sub-topic and the parent topic, determine the parent topic corresponding to the hardware device data.

[0010] Optionally, the hardware abstraction module further performs the following processing: determining the device type corresponding to the hardware device data according to the identification range of the protocol identification in the hardware device data; determining the event processing priority corresponding to the hardware device data according to the size of the protocol identification.

[0011] Optionally, the middleware module includes a communication mechanism adaptation unit, and the communication mechanism adaptation unit receives the encapsulated data by the following process: using the unified communication mechanism interface of the target communication adapter, converting the received encapsulated data into storage data in a standard protocol format.

[0012] Optionally, the middleware module also includes an event storage unit, which is used to perform the following processing: receiving storage data in a standard protocol format sent by the communication mechanism adapter unit, parsing the storage data to determine the event processing priority; and sending the storage data to the corresponding priority queue for storage according to the event processing priority.

[0013] Optionally, the event management unit is used to perform the following processing: extracting the storage data from the priority queue and determining a target service that subscribes to the storage data; and sending the storage data to the target service processing unit.

[0014] Optionally, the hardware abstraction module classifies and encapsulates the hardware device data by the following processing: encapsulating the subject and hardware device data in a binary encoding manner to obtain encapsulated data.

[0015] Optionally, the hardware abstraction module encapsulates the subject and hardware device data by the following processing: encapsulating the subject, information for describing the data type, data status and data length into a data packet header.

[0016] In a second aspect, an embodiment of the present application further provides a vehicle-mounted middleware data processing method, which is applied to the vehicle-mounted middleware as described above, wherein the vehicle-mounted middleware includes a hardware abstraction module, a middleware module and a business module, and the middleware module includes an event management unit, and the method includes:

[0017] Pre-classify the received hardware device data to determine the subject to which the hardware device data corresponds;

[0018] Classify and encapsulate hardware device data based on the subject to obtain encapsulated data;

[0019] A target communication adapter is selected based on the system environment, the packaged data is received using the unified communication mechanism interface of the target communication adapter, and the packaged data is distributed to the target business processing unit for processing through the unified interface of the event management unit.

[0020] In the third aspect, an embodiment of the present application also provides an electronic device, comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate through the bus, and when the machine-readable instructions are executed by the processor, the steps of the above-mentioned in-vehicle middleware method are performed.

[0021] The embodiments of the present application bring the following beneficial effects:

[0022] The embodiments of the present application provide an in-vehicle middleware, an in-vehicle middleware data processing method and an electronic device, which can select a corresponding target communication adapter according to the system environment, and then use the unified communication mechanism interface of the target communication adapter to receive the encapsulated data sent by the hardware abstraction module, and distribute the encapsulated data to the business layer through the unified interface of the event management unit, thereby shielding different communication mechanisms within the system environment, improving business scalability, and reducing the coupling between businesses. Compared with the in-vehicle middleware in the prior art, it solves the problem of high coupling between businesses and poor scalability due to the single communication mechanism of the in-vehicle middleware.

[0023] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0025] Figure 1 A schematic diagram of the structure of the vehicle-mounted middleware provided in an embodiment of the present application is shown;

[0026] Figure 2 A flow chart showing a vehicle-mounted middleware data processing method provided in an embodiment of the present application is shown;

[0027] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0028] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application usually described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, each other embodiment obtained by those skilled in the art without making creative work belongs to the scope of protection of the present application.

[0029] It is worth noting that before the present application was filed, with the continuous development of automotive electronic and electrical systems, the demand for communication between vehicle systems has also increased day by day. Vehicle-mounted middleware can provide core functions such as communication, data sharing, and remote procedure calls for upper-level applications, realize seamless integration between vehicle-mounted systems, and is an important infrastructure to support automotive intelligence. Vehicle-mounted middleware can also greatly reduce the software and system development costs of intelligent networked vehicles, shorten the development cycle, and improve the reliability of software and systems. At present, the cockpit, instrument, vehicle-mounted terminal and other software in the vehicle-mounted system need to support a variety of vehicle-mounted services, and put forward higher requirements for the low coupling and scalability of vehicle-mounted middleware. For example: the cockpit, instrument and TBox software in the vehicle-mounted business face complex data communication mechanisms and event processing challenges. However, the traditional vehicle-mounted communication solutions have inconsistent communication mechanism standards, poor adaptability of inter-process communication methods, high business logic coupling, insufficient scalability, and lack of asynchronous mechanism in event processing, resulting in a single event processing mechanism and lack of flexibility, which cannot meet the needs of complex vehicle networking services.

[0030] Based on this, an embodiment of the present application provides an in-vehicle middleware method to improve the service scalability of the in-vehicle middleware and reduce the coupling degree between services.

[0031] See also Figure 1 , Figure 1 This is a schematic diagram of the structure of a vehicle-mounted middleware provided in an embodiment of the present application. Figure 1 As shown, the vehicle-mounted middleware 10 provided in the embodiment of the present application includes a hardware abstraction module 100, a middleware module 200 and a service module 300, and the middleware module 200 includes an event management unit.

[0032] The hardware abstraction module 100 performs pre-classification processing on the received hardware device data to determine the subject corresponding to the hardware device data;

[0033] Classify and encapsulate the hardware device data based on the topic, and publish the encapsulated data to the middleware module 200 according to the topic;

[0034] The middleware module 200 selects a target communication adapter based on the system environment, receives encapsulated data using the unified communication mechanism interface of the target communication adapter, and distributes the encapsulated data to the target business processing unit in the business module 300 for processing through the unified interface of the event management unit.

[0035] The vehicle-mounted middleware provided in the embodiment of the present application can select the corresponding target communication adapter according to the system environment, and then use the unified communication mechanism interface of the target communication adapter to receive the encapsulated data sent by the hardware abstraction module, and distribute the encapsulated data to the business layer through the unified interface of the event management unit, thereby shielding the different communication mechanisms within the system environment, improving business scalability, and reducing the coupling between businesses, thus solving the problem of high coupling between businesses and poor scalability due to the single communication mechanism of the vehicle-mounted middleware.

[0036] To facilitate understanding of this embodiment, the above-mentioned exemplary modules provided in the embodiment of the present application are described separately below by taking the application of the vehicle-mounted middleware to the vehicle-mounted terminal Tbox or the cockpit domain controller as an example.

[0037] Before the hardware abstraction module 100 performs pre-classification processing on the hardware device data, it is necessary to establish the hardware abstraction layer module 100 .

[0038] In one example, establishing the hardware abstraction layer module 100 includes defining a standardized device interface class ICommDevice, where the device interface class includes a device initialization interface initialize, a data receiving interface receiveData, and a data sending interface sendToMiddleware.

[0039] Among them, the device initialization interface initialize is used to read the local configuration, for example: read the communication mechanism configuration information in the local configuration file, and parse the communication parameters in the local configuration file, determine the type of communication mechanism used, and obtain communication-related parameter configuration. The parameter configuration includes: service name, connection parameters, and the communication mechanism types include: DBus, GDBus, FDBus, and DDS.

[0040] The device initialization interface initialize is also used to initialize the communication environment, for example: creating a corresponding communication adapter instance according to the communication mechanism configuration information, establishing a connection with the system bus, initializing communication resources, and registering services and interfaces.

[0041] The device initialization interface initialize is also used to initialize the communication mechanism. For example, for the DBus communication mechanism, it obtains the system bus connection, registers the DBus service name, and sets the message filtering rules; for the GDBus communication mechanism, it initializes the GDBus connection, registers objects and interfaces, and exports the service interface; for the FDBus communication mechanism, it creates an FDBus service instance, configures the service name and address, and establishes a service endpoint connection; for the DDS communication mechanism, it creates a DDS participant, configures the QoS policy, and creates publishers and subscribers.

[0042] The device initialization interface initialize is also used for initialization status check, for example: verifying the communication connection status, confirming whether the service registration is successful, checking resource allocation, and returning the initialization result.

[0043] The device initialization interface initialize is also used for exception handling, such as configuration file reading exception handling, communication resource allocation failure handling, service registration failure handling, connection establishment timeout handling, and providing a retry mechanism.

[0044] The data receiving interface receiveData is used to receive and parse CAN bus data, and pre-classify different hardware device data through CAN ID. When performing pre-classification, the classification process can be implemented by calling the data pre-classification function classifyData in the subclass. Among them, the pre-classification process includes priority classification, data type classification and device type classification.

[0045] The data sending interface sendToMiddleware is used to encapsulate the communication mechanism between the hardware abstraction module and the middleware module, and supports multiple local communication mechanisms (DBus, GDbus, FDbus, DDS). Each communication mechanism implements the same sendToMiddleware interface. For example: the data sending interface is implemented based on the communication adapter mode. Each communication mechanism corresponds to an adapter class, which inherits from the communication adapter base class ICommAdapter to implement a unified interface. In addition, the factory mode CommAdapterFactory can be used to dynamically create specific communication adapter instances, and select the appropriate communication mechanism according to the system environment configuration. For example: when the system environment is a stand-alone environment, select DBus or GDBus communication mechanism; when the system environment is a distributed environment, select FDBus communication mechanism; when the system environment is a real-time distributed environment, select DDS communication mechanism.

[0046] When the vehicle-mounted middleware is applied, the vehicle real-time status data is collected through various sensors (such as temperature sensors, pressure sensors, speed sensors), and the vehicle real-time status data is sent to the vehicle-mounted controller (Micro Controller Unit, MCU), and the MCU sends the vehicle real-time status data, that is, the CAN bus data frame, and the hardware abstraction module 100 receives the CAN bus data frame. The hardware abstraction module 100 uses the data receiving interface to extract the CAN ID information in the CAN bus data frame, and parses the meaning of each field in the CAN ID, and pre-classifies the CAN bus data frame according to the classification rules to determine the subject corresponding to the CAN bus data frame, and then encapsulates the data based on the classification result. Here, the CAN bus data frame is called hardware device data.

[0047] In one example, when the hardware abstraction module 100 performs pre-classification processing on the hardware device data, the data receiving interface can determine the device type corresponding to the hardware device data according to the identification range of the protocol identifier in the hardware device data, wherein the protocol identifier refers to the CAN ID, and the range refers to the range of the CAN ID, for example: the identification range corresponding to the battery status data is 0x100-0x1FF, the identification range corresponding to the drive motor data is 0x200-0x2FF, and the identification range corresponding to the diagnostic information is a specific CAN ID. After the pre-classification function obtains the CAN ID of the current CAN bus data frame, it determines within which identification range the CAN ID is, and determines which device the current CAN bus data frame comes from based on the determined target identification range, that is, the device type is determined.

[0048] At the same time, the data receiving interface of the hardware abstraction module 100 will also determine the message priority corresponding to the hardware device data according to the size of the protocol identifier. The message priority is also called the event processing priority. For example, the smaller the CAN ID value, the higher the event processing priority; the larger the CAN ID value, the lower the event processing priority.

[0049] In one example, a topic includes a parent topic for describing a business type and a subtopic for describing a data type. Parent topics include, but are not limited to: instrument panel (Topic_HMI), central control (Topic_IVI), remote control cloud platform (Topic_TSP), national standard cloud platform (Topic_GB), enterprise private cloud platform (Topic_PE). Subtopics under the parent topic of enterprise private cloud platform include, but are not limited to: vehicle parameters, hardware anomalies. Subtopics under the parent topic of central control include, but are not limited to: driving mode, gear information, charging information, tire pressure information. The parent topic and subtopics are combined to form the final topic. For example, the topic can be the vehicle parameters of the enterprise private cloud platform, or the hardware anomalies of the enterprise private cloud platform.

[0050] When determining the topic corresponding to the hardware device data, the communication matrix table can be used to determine the sub-topic corresponding to the hardware device data, and based on the mapping relationship between the sub-topic and the parent topic, the parent topic corresponding to the hardware device data can be determined. For example: the hardware device data includes the signal value PowerMode representing the vehicle state 0x0A1, and the signal value charge_state representing the charging state 0x0A2. The signal value can be extracted from the hardware device data, and the communication matrix table records the correspondence between the signal value and the sub-topic. The sub-topic matching the signal value can be found in the communication matrix table, and then the parent topic matching the sub-topic can be found according to the topic mapping relationship table, and the parent topic and the sub-topic are combined to obtain the topic corresponding to the hardware device data.

[0051] In one example, the hardware abstraction module provides a hardware exception monitoring mechanism through a defined hardware exception description model and an exception detection model to pass device error information as an event to the middleware module. The hardware exception description model is a structured data template used to describe and transmit hardware exception information in a standardized manner. The data structure of the hardware exception description model includes: exception level, abnormal behavior characteristics, and the exception level includes 3 levels. Level 1 exceptions are alarms, level 2 exceptions are errors, and level 3 exceptions are interruptions. Abnormal behavior characteristics include communication exceptions, value exceptions, and status exceptions. For example, communication exceptions can be communication timeouts or frame format errors, value exceptions can be value overruns or value too low, and status exceptions can be no response or initialization failure. The anomaly detection model is used to detect anomalies in hardware device data. During the data reception process, the anomaly detection model will parse the CAN bus data frame, detect the hardware device data according to the device type, and compare the real-time data with the threshold range to monitor whether the hardware device data is within the threshold range, so as to determine the anomaly level according to the monitoring results. At the same time, an event topic is constructed according to the monitoring results, encapsulated in the standard event format, and the encapsulated data is sent through the data sending interface. The encapsulated data includes the data type, error level and anomaly description.

[0052] In one example, after determining the subject corresponding to the hardware device data, the hardware device data can be classified and packaged based on the subject, and the packaged data can be published to the middleware module by subject. For example, the subject, hardware device data and message header can be packaged in binary encoding to obtain packaged data. At this time, the data interface function receiveData calls the data pre-classification function classifyData, and according to the standardized data transmission protocol, the subject, data ID, data status, data length, payload content and reserved bits are packaged as a data packet header.

[0053] Among them, data ID may refer to the identifier of the data packet, data status may refer to information used to describe the data type, validity, and error type. The data type includes but is not limited to: real-time data, historical data, event data, validity includes but is not limited to: valid, invalid, timeout, error, error type includes but is not limited to: no error, checksum error, format error, overflow error, data length may refer to the length of the payload content, and the payload content may refer to the actual transmitted data. Hardware device data is used to fill the payload content during encapsulation, and reserved bits are used for protocol extension. The type of message header is determined by the communication mechanism. The message header can be a DBus message header, an FDBus message header, or a DDs message header.

[0054] The protocol structure of the standardized data transmission protocol includes a 2-byte subject, a 2-byte data ID, a 1-byte data status, a 2-byte data length, and a 2-byte reserved bit. The high 8 bits in the subject represent the parent subject, and the low 8 bits represent the sub-subject. For example, 0x00 represents the instrument parent subject, 0x04 represents the enterprise private cloud platform parent subject, 0x00 represents the vehicle parameter sub-subject, 0x01 represents the hardware exception sub-subject, and 0x0400 represents the enterprise private cloud platform vehicle parameters.

[0055] In one example, when compressing the encapsulated data, the data compression strategy is determined according to the data type. For example: according to the CAN ID and the CAN signal value, the hardware status data is divided into status data, numerical data, time series data, and string data, wherein the CAN ID represents the identifier of the CAN message, that is, the ID number of a frame of CAN data in the CAN matrix of the whole vehicle; the CAN signal value represents the CAN data carried by a frame of CAN ID, and a frame of CAN data can carry multiple CAN signal values, which are divided by bits; the status data is used to represent the vehicle switch quantity status information, such as: door status, lock status, air conditioning switch status, parking brake status, seat belt status; numerical data is used to represent the vehicle analog measurement value, such as: battery voltage, vehicle speed, tire pressure value; time series data is used to represent continuous sampling data with a time series relationship, such as: battery charge and discharge curve; string data is used to represent text information such as fault codes, such as: diagnostic fault description text. Then, a data compression strategy corresponding to the data type is adopted, for example: for state data, bitmap compression is adopted; for numerical data, fixed-point compression is adopted; for time series data, difference compression is adopted; for string data, GZIP compression is adopted.

[0056] The hardware abstraction module supports the middleware layer to subscribe by topic. After encapsulating and obtaining the encapsulated data, the hardware abstraction module, as the server, broadcasts the encapsulated data according to the topic subscribed by the middleware module through the data sending interface sendToMiddleware.

[0057] The middleware module consists of a server and a client. The client subscribes to the data of the corresponding topic of the hardware abstract module, and the middleware layer server publishes and subscribes to the topic data of interest to the business layer client.

[0058] In one example, the middleware module includes a communication mechanism adapter unit, an event storage unit, and an event management unit. The middleware module selects a target communication adapter based on the system environment, receives encapsulated data using the unified communication mechanism interface of the target communication adapter, and distributes the encapsulated data to the target business processing unit in the business module through the unified interface of the event management unit for processing.

[0059] Among them, the communication mechanism adapter unit serves as the client of the middleware module, and is used to receive data sent by the hardware abstraction module and perform protocol conversion. The communication mechanism adapter unit supports dynamic switching between multiple communication mechanisms, including traditional message passing mechanisms and distributed communication mechanisms. Traditional message passing mechanisms may refer to DBus and GDBus, and distributed communication mechanisms may refer to cross-device communication transmission, which is mainly used to implement inter-process communication (IPC) or distributed system communication, such as: FDBus, DDS. FDBus and DDS are not communication transmission protocols in the traditional sense (such as TCP / IP, HTTP). The communication mechanism adapter unit adapts different communication mechanisms through a unified communication mechanism interface, and converts the received encapsulated data into storage data in a standard protocol format.

[0060] For example: the communication mechanism adaptation unit in the middleware module includes the communication adapter interface base class ICommAdapter and the adapter class that implements each communication mechanism. Among them, the communication adapter interface base class includes the initialization interface, the publishing interface, the subscription interface, and the unsubscription interface. The initialization interface is used to initialize the communication environment, the publishing interface is used to publish data of a specified topic, the subscription interface is used to subscribe to data of a specified topic, and the unsubscription interface is used to cancel the topic subscription. The adapter class inherits from the ICommAdapter base class. The adapter class includes the DBusAdapter class, the FDBusAdapter class, and the DDSAdapter class. The DBusAdapter class is used to implement the adaptation of local inter-process communication and encapsulate the signal mechanism of DBus; the FDBusAdapter class is used to implement distributed communication adaptation and encapsulate the publish-subscribe mechanism of FDBus; the DDSAdapter class is used to implement real-time distributed communication adaptation and encapsulate the publish-subscribe mechanism of DDS.

[0061] The DBusAdapter class corresponds to the DBus adapter, which is used to convert DBus method calls or signal mechanisms into a unified interface; the FDBusAdapter class corresponds to the FDBus adapter, which is used to encapsulate the publish-subscribe mechanism of FDBus; the DDSAdapter class corresponds to the DDS adapter, which is used to encapsulate the publish-subscribe mechanism of DDS.

[0062] Here, the adapter is defined by the communication adapter factory class CommAdapterFactory, for example: define the adapter type enumeration ADAPTER_DBUS, ADAPTER_FDBUS, ADAPTER_DDS, corresponding to the local communication adapter, distributed communication adapter, and real-time distributed communication adapter, respectively. At the same time, the communication mechanism adapter unit also provides a static method createAdapter for creating an adapter instance, so as to create a corresponding target communication adapter based on the system environment using the static method, for example: if the current system environment is Linux, then use the static method to create a target communication adapter corresponding to Linux, receive the encapsulated data through the subscribe interface of the target communication adapter, remove the message headers of different communication mechanisms in the encapsulated data, and obtain the standard protocol data sent by the hardware abstraction module, so as to convert the data of different communication mechanisms (protocols) into storage data in a unified standard protocol format.

[0063] The event storage unit serves as the receiving end of the middleware module. The event management unit includes the EventStorage class, which is responsible for event data storage management. The event storage unit receives the storage data in a unified standard protocol format sent by the communication mechanism adapter unit, and parses the storage data to determine the event processing priority. Then, according to the event processing priority, the storage data is sent to the corresponding priority queue for storage. For example, the priority queue includes three, namely, a high priority queue, a medium priority queue, and a low priority queue. The event processing priority is determined by the data status in the storage data. If the data status field is 11, it is event data, corresponding to a high priority. If the data status is 01 or 10, it is real-time data or historical data, corresponding to a medium priority. If the data status is 00, it is default data, corresponding to a low priority. If the event processing priority of the storage data is high, the storage data is cached in the high priority queue. Among them, the three priority queues are first-in-first-out queues.

[0064] As the server of the middleware module, the event management unit is used to add subscribers, remove subscribers, and notify subscribers. The event management unit provides a flexible event registration and deregistration mechanism, and supports dynamic addition or removal of subscribers. The event management unit includes the EventManager class, which is responsible for event subscription and distribution. The EventManager class includes the member subscribers that maintains the mapping relationship between topics and subscribers, and the member subscriberMutex that protects concurrent access to the subscription mapping table.

[0065] The event management unit extracts the stored data from the priority queue according to the first-in-first-out principle, determines the target business that subscribes to the stored data by looking up the table, and calls the subscriber's callback function to send the stored data to all subscribers through a unified interface by subject, that is, the target business processing unit. For example: EventManager obtains events by calling the getNextEvent method of EventStorage. The getNextEvent method first checks the high priority queue. If the high priority queue is empty, it checks the normal priority queue; if the normal priority queue is empty, it checks the low priority queue. In addition, the event management unit records the subscription relationship between the subscriber and the event, and also records the callback function used when the event is triggered, so that the callback function can be used to send data to the business processing unit when the event is triggered.

[0066] In one example, the EventManager class is also used to register and unregister events. When registering an event, the EventManager.subscribe method is called to create a mapping from topic to callback function in the subscribers mapping table, and subscriberMutex is used to protect concurrent access. When unregistering an event, the EventManager.unsubscribe method is called to remove the corresponding mapping relationship from the subscribers mapping table.

[0067] In one example, if the data needs to be decompressed, the encapsulated data is decompressed in the event management unit. When decompressing, the data decompression strategy is determined according to the data type. For example: for state data, the compressed byte array is converted into a bitmap, an 8-byte result array is created, and the 8 positions of the bitmap are traversed. When the corresponding position of the bitmap is 1, the corresponding position of the result array is written with 1, otherwise it is written with 0, and the restored state array is output; for numerical data, the compressed byte array is packaged into a byte buffer, and a floating-point result array is created. The array size is the length of the byte array divided by 2, and the byte buffer is traversed. Each time 2 bytes are read, they are converted into short integers, multiplied by the precision factor to restore them to floating points, written into the result array, and finally the restored numerical array is output; for time series data, the compressed byte array is packaged into a byte buffer, the number of data points is determined by dividing the array length by 6, and a timestamp array and a numerical array are created. Initialize the current timestamp to 0, traverse the byte buffer, read 4 bytes each time as the time difference, accumulate it to the current timestamp to get the actual timestamp, read 2 bytes, convert it to a short integer, and divide it by 100 to get the actual value, write it into the timestamp array and the value array respectively, and finally output the data structure containing the restored time series; for string data, first initialize the decompression environment, that is, create and initialize the z_stream data stream structure to manage the decompression process, configure the decompression window size to MAX_WBITS+16, which is consistent with the compression, set the initial state of the input and output buffers, and then perform the decompression operation, that is, write the compressed data to the input buffer of the decompression stream, call the inflate function to perform decompression, set the decompression mode to Z_FINISH, store the decompressed data in the output buffer, record the actual length of the decompressed data, and finally release the decompression resources, that is, call the inflateEnd function to clear the decompression stream, release the temporarily allocated memory space, and return the status code of the decompression operation.

[0068] The middleware layer server forwards the subscribed topic data to the business layer client.

[0069] The business module includes a business service interface unit, which is a unified communication mechanism interface in the business module. Here, a unified business interface can be implemented by setting the BusinessService class. The member variables in the BusinessService class include: business service type identifier serviceType, event callback processing function eventCallback, result feedback queue resultQueue, and service status identifier serviceStatus. The core methods include: processing received events processEvent, sending processing results sendResult, registering event callbacks registerCallback, and updating service status updateStatus. Among them, the business service interface unit implements standardized data reception and processing through the BusinessService class instead of relying on the physical interface. For example: for instruments, the BusinessService interface is implemented to process data such as vehicle speed and rotation speed; for remote control, the BusinessService interface is implemented to process remote commands; for cloud platform business, the BusinessService interface is implemented to process cloud data interaction.

[0070] The business module also includes a business mapping management unit, which implements the mapping of management events and businesses by setting the BusinessMapper class. The member variables of the BusinessMapper class include: event type to business processor mapping table eventMap, registered business service list businessRegistry, and mapping configuration information mappingConfig. The core methods include: registering business services registerBusiness, establishing event to business mapping mapEventToBusiness, getting business processors getBusinessHandler, and updating mapping relationships updateMapping. Among them, dynamic mapping management can be implemented through registerBusiness, mapEventToBusiness, and updateMapping.

[0071] The business module also includes a business processing unit, which is implemented by setting specific business processing classes InstrumentService and RemoteControlService. Member variables include: business identifier businessId, event processor eventProcessor, data buffer dataBuffer, and processing status processStatus. The core methods include: handling specific events handleEvent, processing business data processData, generating processing results-generateResult, and updating processing status updateStatus. Business processing units include: instruments, central control, remote control cloud platform, national standard cloud platform, and enterprise private cloud platform.

[0072] The business module also includes a result feedback unit, which manages result feedback by setting the ResultFeedback class. Member variables include: priority result queue resultQueue, feedback status feedbackStatus, result processor resultProcessor, and target channel targetChannel.

[0073] After the business processing unit completes the business processing, it returns the business results to the hardware abstraction module through the standard communication protocol. At this time, the business module generates a control command through sendCommand, sets the priority and timeout of the control command, and uses BusinessResult to encapsulate the result, and adds the control command to the queue through DataInteraction. The middleware module receives the control command sent by the business module, searches for the target device in the corresponding hardware abstraction module, converts the control command into EventData format, and agrees on a unified format with the hardware abstraction module, and forwards the converted control command to the hardware abstraction module through the communication adapter unit. The hardware abstraction module receives and parses the converted control command to obtain the hardware control instruction. The hardware abstraction module performs the corresponding hardware operation according to the hardware control instruction and collects the execution result. Finally, the hardware abstraction module encapsulates the execution result and sends it to the middleware module. The middleware module receives and forwards the execution result to the business module. The business module processes the execution response and updates the command execution status.

[0074] In addition, in the process of returning the business results to the hardware abstraction module, the standard communication protocol header includes the subject, status code, data length, result data, reserved field, and timestamp. The status code indicates the processing result. The status code includes the high 4 bits of processing status and the low 4 bits of error type. The processing status includes 0x00 for successful processing, 0x10 for processing failure, 0x20 for processing timeout, 0x30 for processing, and 0x40 for queue waiting. The error types include 0x01 parameter error, 0x02 insufficient authority, 0x03 insufficient resources, and 0x04 hardware abnormality. The structure data indicates the actual feedback content, and the timestamp is used to record the processing time.

[0075] In the interaction between the hardware abstraction module and the middleware module, the hardware device data is encapsulated through the standard communication protocol, and the two-way communication with the middleware module is realized with the help of the communication interface provided by the communication mechanism adapter unit. In the interaction between the middleware module and the business module, the event management unit is used to assign device events to the corresponding business processing unit according to priority and type, and an event response mechanism is provided. After the business processing is completed, the feedback event is encapsulated and returned to the request end through the middleware module.

[0076] Based on the same inventive concept, an on-board middleware device corresponding to the on-board middleware method is also provided in the embodiment of the present application. Since the principle of solving the problem by the device in the embodiment of the present application is similar to the above-mentioned on-board middleware method in the embodiment of the present application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated.

[0077] See also Figure 2 , Figure 2 This is a flow chart of a vehicle-mounted middleware data processing method provided in an embodiment of the present application. Figure 2 As shown in, the vehicle-mounted middleware data processing method is applied to the above Figure 1 The vehicle-mounted middleware shown includes a hardware abstraction module, a middleware module and a business module, the middleware module includes an event management unit, and the method includes:

[0078] Step S401, pre-classifying the received hardware device data to determine the subject corresponding to the hardware device data;

[0079] Step S402, classifying and packaging the hardware device data based on the theme to obtain packaged data;

[0080] Step S403, selecting a target communication adapter based on the system environment, receiving the encapsulated data using the unified communication mechanism interface of the target communication adapter, and distributing the encapsulated data to the target business processing unit for processing through the unified interface of the event management unit.

[0081] See also Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 3 As shown in , the electronic device 500 includes a processor 510 , a memory 520 and a bus 530 .

[0082] The memory 520 stores machine-readable instructions executable by the processor 510. When the electronic device 500 is running, the processor 510 communicates with the memory 520 via the bus 530. When the machine-readable instructions are executed by the processor 510, the above-mentioned Figure 2 The specific implementation of the steps of the vehicle-mounted middleware data processing method in the method embodiment shown can be found in the method embodiment, and will not be repeated here.

[0083] The present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the computer program can execute the above-mentioned Figure 2 The specific implementation of the steps of the vehicle-mounted middleware data processing method in the method embodiment shown can be found in the method embodiment, and will not be repeated here.

[0084] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0085] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0086] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0087] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0088] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of a software product, or in other words, the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0089] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-mentioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A vehicle-mounted middleware, characterized in that: It includes hardware abstraction module, middleware module and business module. The middleware module includes event management unit: The hardware abstraction module performs pre-classification processing on the received hardware device data to determine the subject corresponding to the hardware device data; Classify and package the hardware device data based on the subject, and publish the packaged data to the middleware module according to the subject; The middleware module selects a target communication adapter based on the system environment, receives the encapsulated data using the unified communication mechanism interface of the target communication adapter, and distributes the encapsulated data to the target business processing unit in the business module through the unified interface of the event management unit for processing.

2. The vehicle-mounted middleware according to claim 1, characterized in that: The topic includes a parent topic and a sub-topic. The hardware abstraction module determines the topic corresponding to the hardware device data by the following processing: Using the communication matrix table, determining the subtopic corresponding to the hardware device data; Based on the mapping relationship between the sub-topic and the parent topic, the parent topic corresponding to the hardware device data is determined.

3. The vehicle-mounted middleware according to claim 1, characterized in that: The hardware abstraction module also performs the following processing: Determining the device type corresponding to the hardware device data according to the identification range of the protocol identification in the hardware device data; The event processing priority corresponding to the hardware device data is determined according to the size of the protocol identifier.

4. The vehicle-mounted middleware according to claim 3, characterized in that: The middleware module includes a communication mechanism adaptation unit, and the communication mechanism adaptation unit receives the encapsulated data by the following processing: The received encapsulated data is converted into storage data in a standard protocol format using the unified communication mechanism interface of the target communication adapter.

5. The vehicle-mounted middleware according to claim 4, characterized in that: The middleware module further includes an event storage unit, which is used to perform the following processing: receiving the stored data in the standard protocol format sent by the communication mechanism adaptation unit, and parsing the stored data to determine the event processing priority; According to the event processing priority, the stored data is sent to the corresponding priority queue for storage.

6. The vehicle-mounted middleware according to claim 5, characterized in that: The event management unit is used to perform the following processing: Extracting the stored data from the priority queue and determining a target service to subscribe to the stored data; The stored data is sent to a target service processing unit.

7. The vehicle-mounted middleware according to claim 1, characterized in that: The hardware abstraction module classifies and encapsulates the hardware device data through the following processing: The subject and the hardware device data are encapsulated in a binary encoding manner to obtain encapsulated data.

8. The vehicle-mounted middleware according to claim 7, characterized in that: The hardware abstraction module encapsulates the subject and the hardware device data by the following processing: The subject, information for describing the data type, data status and data length are encapsulated as a data packet header.

9. A vehicle-mounted middleware data processing method, characterized in that: Applied to the in-vehicle middleware according to any one of claims 1 to 8, the in-vehicle middleware comprises a hardware abstraction module, a middleware module and a business module, the middleware module comprises an event management unit, and the method comprises: Pre-classifying the received hardware device data to determine the subject to which the hardware device data corresponds; Classify and package the hardware device data based on the subject to obtain packaged data; A target communication adapter is selected based on the system environment, the encapsulated data is received using the unified communication mechanism interface of the target communication adapter, and the encapsulated data is distributed to the target business processing unit for processing through the unified interface of the event management unit.

10. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the in-vehicle middleware data processing method as described in claim 9.

Images