CN117082102A

CN117082102A - Service-oriented architecture-based vehicle data processing method, device and equipment

Info

Publication number: CN117082102A
Application number: CN202311168752.4A
Authority: CN
Inventors: 刘凯
Original assignee: Lantu Automobile Technology Co Ltd
Current assignee: Lantu Automobile Technology Co Ltd
Priority date: 2023-09-11
Filing date: 2023-09-11
Publication date: 2023-11-17

Abstract

The application discloses a vehicle data processing method, a device and equipment based on a service-oriented architecture, which are applied to a vehicle, wherein the vehicle comprises a central computing platform and a communication area controller, the central computing platform comprises a vehicle body area controller and a plurality of other area controllers, the vehicle body area controller comprises a first core and a second core, the computing power of the first core is larger than that of the second core, and a first data acquisition software module is deployed in the first core, and the method comprises the following steps: the first data acquisition software module acquires the original data of the second core; acquiring SOMEIP communication data of a vehicle body domain controller and other domain controllers; collecting communication data of a communication area controller; analyzing the acquired data to obtain target data. According to the technical scheme provided by the application, the vehicle data can be collected and analyzed in full quantity on the basis of not increasing hardware equipment, and the processing cost of the vehicle data is reduced.

Description

Service-oriented architecture-based vehicle data processing method, device and equipment

Technical Field

The application belongs to the technical field of Internet of vehicles, and particularly relates to a vehicle data processing method, device and equipment based on a service-oriented architecture.

Background

Intelligent networked automobiles, as a highly complex, mobile computing and storage platform, generate large amounts of data in real-time that are extremely important for troubleshooting vehicles, responsibility-determining, and whether vehicles meet the national latest automotive event data logging system (Vehicle Event Data Recorder System, EDR) regulatory requirements.

The traditional fault positioning adopts a diagnostic instrument or a remote diagnosis mode, and has the defect of lacking historical data when in fault; if the mode of the external hanging data acquisition instrument is adopted, the cost is greatly increased for each vehicle. Therefore, how to collect the communication data of the vehicle based on the Service-Oriented Architecture (SOA) architecture comprehensively and at low cost is a technical problem to be solved.

Disclosure of Invention

The embodiment of the application provides a vehicle data processing method, device and equipment based on a service oriented architecture, and further realizes comprehensive and low-cost acquisition of communication data of vehicles based on an SOA architecture.

Other features and advantages of the application will be apparent from the following detailed description, or may be learned by the practice of the application.

According to a first aspect of an embodiment of the present application, there is provided a vehicle data processing method based on a service oriented architecture, applied to a vehicle, the vehicle including a central computing platform and a communication area controller, the central computing platform including a vehicle body domain controller and a plurality of other domain controllers, the vehicle body domain controller including a first core and a second core, the first core having a greater computational power than the second core, the first core having disposed therein a first data acquisition software module, the method comprising:

The first data acquisition software module acquires the original data of the second core to obtain first acquisition data;

acquiring SOMEIP communication data of the vehicle body domain controller and the other domain controllers to obtain second acquired data;

collecting communication data of the communication area controller to obtain third collected data;

and analyzing the first acquired data, the second acquired data and the third acquired data to obtain target data.

In some embodiments of the present application, based on the foregoing solution, the collecting the raw data of the second core includes:

packaging the operation of inter-core communication between the first core and the second core into an application programming interface;

the raw data is received from the second core by invoking the application programming interface.

In some embodiments of the application, based on the foregoing, the application programming interface includes an application software component interface and an inter-core communication proxy interface, the receiving the raw data from the second core by invoking the application programming interface includes:

the original data is received from the second core by calling the inter-core communication proxy interface, wherein the original data is data output by each application of the second core by calling the application software component interface.

In some embodiments of the present application, based on the foregoing solution, a second data acquisition software module is disposed in each of the other domain controllers, where the somei communication data includes a first somei communication data and a second somei communication data, and the acquiring the somei communication data of the vehicle body domain controller and the other domain controllers includes:

collecting the first SOMEIP communication data of the vehicle body domain controller in a calling service state;

and receiving the second SOMEIP communication data of the other domain controllers in the call service state, which is sent by the second data acquisition software module.

In some embodiments of the present application, based on the foregoing solution, the collecting the communication data of the communication area controller includes:

and receiving an Ethernet data packet from an Ethernet bus corresponding to the communication area controller, wherein the Ethernet data packet is obtained by screening, mirroring and packaging the communication data of the communication area controller.

In some embodiments of the present application, based on the foregoing solution, the analyzing the first collected data, the second collected data, and the third collected data to obtain target data includes:

Determining a first signal definition configuration file according to a preset data protocol, and analyzing the first acquired data according to the first signal definition configuration file to obtain triplet data corresponding to each signal in the first acquired data, wherein the triplet data comprises a time stamp, a signal name and a signal value;

determining a second signal definition configuration file according to a preset SOMEIP communication matrix, and analyzing the second acquired data according to the second signal definition configuration file to obtain triplet data corresponding to each signal in the second acquired data;

determining a third signal definition configuration file according to a preset data encapsulation protocol and a preset database management file, and analyzing the third acquired data according to the third signal definition configuration file to obtain triplet data corresponding to each signal in the third acquired data;

and determining all the obtained triplet data as the target data.

In some embodiments of the present application, based on the foregoing solution, a data storage module is further disposed in the first core, and the method further includes:

receiving a query instruction sent by a cloud server;

Sending the query instruction to the data storage module so that the data storage module searches target data corresponding to the query instruction;

and acquiring the target data corresponding to the query instruction from the data storage module and uploading the target data to the cloud server.

According to a second aspect of an embodiment of the present application, there is provided a vehicle data acquisition device based on a service oriented architecture, applied to a vehicle, the vehicle including a central computing platform and a communication area controller, the central computing platform including a vehicle body domain controller and a plurality of other domain controllers, the vehicle body domain controller including a first core and a second core, the first core having a greater computational power than the second core, the first core having disposed therein the vehicle data acquisition device based on the service oriented architecture, the device comprising:

the first acquisition unit is used for acquiring the original data of the second core to obtain first acquisition data;

the second acquisition unit is used for acquiring SOMEIP communication data of the vehicle body domain controller and the other domain controllers to obtain second acquisition data;

the third acquisition unit is used for acquiring communication data of the communication area controller to obtain third acquisition data;

The data analysis unit is used for analyzing the first acquired data, the second acquired data and the third acquired data to obtain target data.

In some embodiments of the present application, based on the foregoing solution, the first collecting unit is further configured to encapsulate an operation of performing inter-core communication between the first core and the second core into an application programming interface; the raw data is received from the second core by invoking the application programming interface.

In some embodiments of the present application, based on the foregoing, the application programming interface includes an application software component interface and an inter-core communication proxy interface, and the first collecting unit is further configured to receive the raw data from the second core by calling the inter-core communication proxy interface, where the raw data is data output by each application of the second core by calling the application software component interface.

In some embodiments of the present application, based on the foregoing solutions, a second collecting software module is disposed in each of the other domain controllers, and the second collecting unit is further configured to collect the first sometip communication data of the vehicle body domain controller in a call service state; and receiving the second SOMEIP communication data of the other domain controllers in the call service state, which is sent by the second data acquisition software module.

In some embodiments of the present application, based on the foregoing solution, the third collecting unit is further configured to receive an ethernet packet from an ethernet bus corresponding to the communication area controller, where the ethernet packet is obtained after screening, mirroring, and encapsulating the communication data of the communication area controller.

In some embodiments of the present application, based on the foregoing solutions, the data parsing unit is further configured to determine a first signal definition configuration file according to a preset data protocol, and parse the first collected data according to the first signal definition configuration file to obtain triplet data corresponding to each signal in the first collected data, where the triplet data includes a timestamp, a signal name, and a signal value; determining a second signal definition configuration file according to a preset SOMEIP communication matrix, and analyzing the second acquired data according to the second signal definition configuration file to obtain triplet data corresponding to each signal in the second acquired data; determining a third signal definition configuration file according to a preset data encapsulation protocol and a preset database management file, and analyzing the third acquired data according to the third signal definition configuration file to obtain triplet data corresponding to each signal in the third acquired data; and determining all the obtained triplet data as the target data.

In some embodiments of the present application, based on the foregoing solution, the first core is further configured with a data storage module, and the vehicle data acquisition device based on a service-oriented architecture further includes a data uploading unit, configured to receive a query instruction sent by the cloud server; sending the query instruction to the data storage module so that the data storage module searches target data corresponding to the query instruction; and acquiring the target data corresponding to the query instruction from the data storage module and uploading the target data to the cloud server.

According to a third aspect of embodiments of the present application, there is provided a vehicle data acquisition device based on a service oriented architecture, comprising a processor and a memory, the memory storing computer program instructions executable by the processor, the processor executing the computer program instructions to implement the instructions of the method according to any one of the first aspects above.

According to a fourth aspect of embodiments of the present application, there is provided a computer readable storage medium having stored therein computer program instructions that are loaded and executed by a processor to carry out the operations performed by the method according to any of the first aspects above.

In the application, a vehicle comprises a central computing platform and a communication area controller, wherein the central computing platform comprises a vehicle body domain controller and a plurality of other domain controllers, the vehicle body domain controller comprises a first core and a second core, the computational power of the first core is larger than that of the second core, a first data acquisition software module is deployed in the first core, and the first data acquisition software module is used for acquiring the original data of the second core; acquiring SOMEIP communication data of a vehicle body domain controller and other domain controllers; collecting communication data of a communication area controller; analyzing the acquired data to obtain target data. Therefore, the vehicle data can be collected and analyzed in full quantity on the basis of not increasing hardware equipment, and the processing cost of the vehicle data is reduced.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is evident that the drawings in the following description are only some embodiments of the present application and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art. In the drawings:

FIG. 1 illustrates an application environment diagram of a vehicle data processing method based on a service oriented architecture in one embodiment;

FIG. 2 illustrates a flow diagram of a vehicle data processing method based on a service-oriented architecture in one embodiment;

FIG. 3 shows a data flow diagram of step 201 in one embodiment;

FIG. 4 shows a data flow diagram of step 202 in one embodiment;

FIG. 5 shows a data flow diagram of step 203 in one embodiment;

FIG. 6 shows a detailed flow diagram of 204 in one embodiment;

FIG. 7 illustrates a data flow diagram of a vehicle data processing method based on a service oriented architecture in another embodiment;

FIG. 8 illustrates a block diagram of a vehicle data processing device based on a service oriented architecture in one embodiment;

FIG. 9 illustrates a schematic diagram of a vehicle data processing device based on a service-oriented architecture in one embodiment.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the application may be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the application.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

It should also be noted that the terms "first," "second," and the like in the description and claims of the present application and in the above-described figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the objects so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented in other sequences than those illustrated or otherwise described.

In order to enable those skilled in the art to better understand the present application, first, an application scenario related to the present application will be briefly described with reference to fig. 1.

Referring to fig. 1, a schematic view of a scenario in which a service-oriented architecture-based vehicle data processing method according to an embodiment of the present application may be applied is shown.

As shown in fig. 1, the vehicle includes a central computing platform and a communication area controller, the central computing platform includes a vehicle body domain controller and a plurality of other domain controllers, the vehicle body domain controller includes a first core and a second core, the computing power of the first core is greater than that of the second core, a first data acquisition software module is deployed in the first core, and a second data acquisition software module is deployed in the other domain controllers. In a specific implementation, the first core refers to a core with greater computational power in the body domain controller, such as the a core, and the second core has less computational power relative to the first core, such as the M core. Where computing power refers to the ability to complete a certain number of computing tasks.

The first data acquisition software module can acquire the original data of the second core to obtain first acquisition data; acquiring SOMEIP communication data of the vehicle body domain controller and other domain controllers to obtain second acquired data; collecting communication data of the communication area controller to obtain third collected data; and analyzing the first acquired data, the second acquired data and the third acquired data to obtain target data. Therefore, comprehensive acquisition of observed quantity data of each application in an M core of a vehicle body domain controller in a central computing platform, SOMEIP communication data among domain controls in the central computing platform, communication data among communication area controllers and the central computing platform, communication data of CAN/CANFD/LIN nodes in the communication area controllers CAN be realized, low-cost acquisition of key data of fault positioning is realized through a pure software scheme on the basis of not increasing hardware equipment, and the processing cost of vehicle data is reduced.

In one embodiment, as shown in fig. 2, a vehicle data processing method based on a service-oriented architecture is provided, and the method is applied to the first data acquisition software module in fig. 1 for illustration, and the method may include the following steps:

Step 201, collecting the original data of the second core, so as to obtain first collected data.

It will be appreciated that software related to the overall vehicle control is mainly run in the vehicle body domain controller, such as: underlying software (including vehicle mode management, power management, sleep wake management, etc.), body controller (Body Control Module, BCM), whole vehicle controller (Vehicle Control Unit, VCU), air-conditioning-on-Air (AC), over-the-Air Technology (OTA) components, diagnostic components, etc. According to different functional positioning and characteristics of various software, the performance requirements of the software on the chip and the system are different, for example, the requirements of underlying software and BCM, VCU, AC on the stability, the reliability, the instantaneity and the safety of the system are high, and the software needs to run on an AUTOSAR system of an M core; applications such as OTA and remote diagnosis have requirements on the computational power of the chip, and generally run on the QNX system of the a core. The A-core file system is perfect, and the application of the A-core file system generally stores logs for analyzing and positioning problems; the application of the M core cannot store the log file of the application, but the application of the M core is an important basis for the normal operation of the whole vehicle, and key parameters or specific observables in the operation process are critical for the rapid analysis and positioning of the problems, so that the key parameters or specific observables in the operation of the application of the M core are data objects required to be acquired by a vehicle body domain. By deploying the first data acquisition software module in the core A, the observed data of the application of the core M can be efficiently acquired through the inter-core communication technology.

In some embodiments, the operation of inter-core communication between the first core and the second core may be packaged as an application programming interface; raw data is received from the second core by invoking an application programming interface.

For convenience of distinction and description, the following description will take an example in which the first core is an a core and the second core is an M core. The principle of inter-core communication is mainly based on a register and interrupt transfer information, and based on shared memory transmission data, in order to improve the efficiency of synchronizing information between an application of an A core and an application of an M core, reduce the complexity of processing inter-core communication of each application, reduce repeated development actions of each application in the inter-core communication process, and package basic operations of inter-core communication in the process, such as operations of reading shared memory data, cleaning interrupt and the like, into a set of unified application programming (Application Programming Interface, API) interface for each application to call so as to greatly reduce repeated actions of each application in the inter-core communication process and improve efficiency.

In some embodiments, the application programming interface includes an application software component interface and an inter-core communication proxy interface, receiving raw data from the second core by invoking the application programming interface, comprising: raw data is received from the second core by invoking the inter-core communication proxy interface, wherein the raw data is data output by applications of the second core by invoking the application software component interface.

It can be understood that the API interface is an application software component interface IPCF SWC on the M core side, and is used for calling the Data Proxy module data_proxy corresponding to each application (bottom software, BCM, VCU, AC) of the M core, and sending the Data which is defined in advance and needs to be collected; the API interface is an inter-core communication Proxy interface IPCF Proxy on the A core side, and is used for subscribing the A core data acquisition software module to receive data.

In a specific implementation, the application software component interface and the data proxy module corresponding to each application of the second core may be deployed in the same core of the second core.

It will be appreciated that the M Core is typically composed of Core0, core1, … CoreN, and that the Data agent data_proxy and the IPCF SWC need to be deployed at the same Core in order to avoid cross-Core operation efficiency in the process of invoking the IPCF SWC by the Data agent data_proxy.

In a specific implementation, a transmission protocol and a data protocol which are needed to be used for M-core data acquisition can be defined in advance, and the data acquisition is realized through an API interface based on a preset transmission protocol and a preset data protocol. For example, the package header and the data part content are defined in a preset transmission protocol, the package header mainly includes a timestamp, a packet data length, a channel ID, and the like, and the data mainly includes a software module ID, an index ID, a data length, specific data, and the like. The information of the software module ID, index ID, signal name, signal width, data type and the like is preset in the preset data protocol.

Fig. 3 shows a Data flow diagram of step S201 in an embodiment, as shown in fig. 3, an application needing to collect Data in an M core encapsulates the Data needing to be collected according to the above protocol requirements, and invokes an encapsulated application software component interface IPCF SWC to send Data to an a core through a Data Proxy module data_proxy corresponding to the application software component interface IPCF SWC at a fixed frequency or a real frequency generated by the Data. And the first data acquisition software module adapter_M in the core A calls the packaged inter-core communication Proxy interface IPCF Proxy, and receives data from the core M by using a preset transmission protocol. After the first data acquisition software module receives the data, the data are analyzed and stored according to a preset data protocol.

Step 202, acquiring SOMEIP communication data of the vehicle body domain controller and other domain controllers to obtain second acquired data.

It will be appreciated that there are typically three major domains within the central computing platform of an SOA-based automobile: a car body domain controller, an entertainment domain controller and an intelligent driving domain controller. The normal communication among the domain controllers is the basis for normal use of the whole car entertainment function and the intelligent driving function. The main instruction interaction and data synchronization among the domain controllers are all transmitted by adopting an extensible service-oriented middleware (SOMEIP) protocol based on IP, and the acquisition of SOMEIP communication data among the domain controllers is critical to the rapid analysis and positioning of the problems. Because each domain controller is a service provider (service) and a service caller (client) on different service types, if all SOMEIP communication data on the Ethernet are collected, a large amount of data repetition and resource waste can be caused, so that only SOMEIP communication data of the domain controller in a calling service state can be collected, namely, the domain controller is used as data for receiving and transmitting at the client end, the requirement of problem positioning can be met, and the efficiency is improved.

Specifically, the first data acquisition software module can acquire first SOMEIP communication data of the vehicle body domain controller in a call service state; and receiving second SOMEIP communication data sent by the second data acquisition software module under the calling service state by other domain controllers.

In some embodiments, the first core is further provided with a bottom layer communication component for performing SOMEIP communication with other domain controllers, and the operation of performing inter-process communication between the first data acquisition software module and the bottom layer communication component can be packaged into an application programming interface; the first SOMEIP communication data of the body domain controller in the call service state is received from the underlying communication component by calling the application programming interface.

It should be noted that, each client in SOMEIP communication interacts information with a service end through a bottom communication component, in this process, a data acquisition software module disposed in a domain controller may directly monitor a network message from a network, and then filter information to be acquired according to a required service ID, but this method is inefficient and causes additional performance consumption in network monitoring and filtering. The data acquisition software module can be registered as a SOMEIP client end, and data is directly acquired through subscribing the required service, but the method can generate larger pressure on the whole SOMEIP protocol stack and possibly influence on the whole SOMEIP communication. Therefore, the method of interprocess communication can be adopted to realize the acquisition of SOMEIP communication data when the domain controller is used as the client.

In a specific implementation, the operation of inter-process communication on the domain controller can be packaged into a set of unified IPC API interfaces for each application to be efficiently called, so that the complexity of the inter-process communication of each application is reduced, repeated development actions in the communication process are reduced, and the efficiency is improved.

In some embodiments, a release theme corresponding to the first somei communication data of the vehicle body domain controller in the call service state may be determined according to a preset somei communication matrix; subscribing to the release topic and invoking an application programming interface to receive first SOMEIP communication data corresponding to the release topic from the underlying communication component.

It may be understood that the SOMEIP communication matrix may be predefined in the first data acquisition software module, and the naming rule of the release topic corresponding to the first SOMEIP communication data in the calling service state of the vehicle body domain controller may be in a form of a combination of a service name ServiceName and a Method/event name Method/EventName in the preset SOMEIP communication matrix, for example, in the following form: the ServiceName/method_or_eventname, message content MessageData part directly fills the content of data type Field Property Data Type in the preset SOMEIP communication matrix.

The calling mode of the API interface is publish-subscribe (namely PUB-SUB), and the data acquisition software module on the domain controller can subscribe to receive the required data. When the domain controller is used as a client to receive SOMEIP communication data, the data is transmitted to a corresponding release theme through an IPC API interface PUB, and the data acquisition software module receives the SOMEIP communication data by subscribing the corresponding release theme.

It will be appreciated that the second data collecting software module may implement the second SOMEIP communication data of the corresponding other domain controller in the call service state according to a similar method.

Taking other domain controllers as entertainment domain controllers and intelligent driving domain controllers as examples, a bottom communication component which is used for SOMEIP communication with the intelligent driving domain controllers and the vehicle body domain controllers can be further deployed in the entertainment domain controllers, and the operation of interprocess communication between a second data acquisition software module deployed in the entertainment domain controllers and the bottom communication component is packaged into an application programming interface; the second SOMEIP communication data of the entertainment domain controller in the call service state is received from the underlying communication component by calling the application programming interface.

In some embodiments, the second SOMEIP communication data sent by the second data collection software module in the call service state by the other domain controller may be received based on the transmission control protocol.

It CAN be understood that the data acquisition software modules on different domain controllers belong to different processors and different operating systems, so that buses such as CAN or Ethernet are required to be used for communication in the vehicle, the transmission efficiency of the CAN bus is low, the design is also inflexible, and the Ethernet mode is selected for carrying out. Because the first data acquisition software module acquires the first SOMEIP communication data and the second SOMEIP communication data, the data needs to be analyzed to obtain target data, the target data is sent to the data calculation module, the data calculation module needs to input relatively real-time signal data, and frame loss cannot occur as far as possible, and the data frames need to be cached at the opposite end once frame loss occurs, but the data frames are continuously generated, namely, the data exists in a streaming form, the processing delay of one link can cause the delay of the subsequent link and the subsequent data processing, and further cause data blocking, and therefore, transmission control protocol (Transmission Control Protocol, TCP) can be considered to be adopted to transmit the SOMEIP communication data during network transmission.

FIG. 4 is a data flow diagram of step 202 in one embodiment, as shown in FIG. 4, where a first data acquisition software module adapter_M on the vehicle body domain controller A core receives first SOMEIP communication data of the vehicle body domain controller in a call service state from an underlying communication component on the vehicle body domain controller by calling an IPC API interface; the second data acquisition software module adapter_S on the other domain controllers receives second SOMEIP communication data of the other domain controllers in a calling service state from the bottom communication component on the corresponding other domain controllers by calling the IPC API interface, and sends the second SOMEIP communication data to the first data acquisition software module adapter_M.

The first data acquisition software module adapter_m is used as a data unified summarizer and a place for data analysis, so that the adapter_m can be designed as a TCP server, and the second data acquisition software module adapter_S on other domain controllers can be designed as a TCP client. After receiving the second SOMEIP communication data, the adapter_S uniformly packages and sends the data to the adapter_M for analyzing and storing the data.

And 203, collecting communication data of the communication area controller to obtain third collected data.

It CAN be appreciated that in an automobile based on the SOA architecture, there are typically 4 front, rear, left and right communication area controllers besides the central computing platform, where the communication area controllers are used for controller area network (Controller Area Network, CAN) communication between each controller node on the automobile and between each controller and the central brain, variable rate CAN communication and serial communication network (Local interconnect Network, LIN) communication, and these communication data are the most basic data for ensuring the normal operation of the whole automobile function, and are also the main data for troubleshooting problems when the corresponding function fails or fails.

The communication data of the communication area controller includes communication data between the communication area controller and the central computing platform, communication data between the communication area controllers, and communication data inside the communication area controller. Because the communication area controller is used for CAN/CANFD/LIN communication between each controller and the central computing platform, the data of the CAN/CANFD/LIN communication between each controller and the central computing platform CAN be obtained by collecting the communication data between the communication area controller and the central computing platform; and the CAN/CANFD/LIN communication data between the controller nodes on the vehicle CAN be obtained by collecting the communication data between the controllers in the communication area and the communication data in the controllers in the communication area.

If the data of CAN/CANFD/LIN communication is collected in full amount, the excessive amount of data may cause excessive CPU load on each of the communication area controller and the vehicle body domain controller, so that appropriate amount of filtering is required for the communication data.

In some embodiments, the first data acquisition software module may receive an ethernet packet from an ethernet bus corresponding to the communication area controller, where the ethernet packet is obtained by screening, mirroring, and encapsulating communication data of the communication area controller.

Wherein the steps of screening, mirroring and packaging the communication data may comprise: screening out target controllers from controllers in communication with the communication area controller; determining a data acquisition message routing table according to the target controller; screening data corresponding to the data acquisition message routing table from the communication data to obtain data to be processed; and mirroring the data to be processed and then packaging to obtain the Ethernet data packet.

Specifically, the target controller may be a controller that is more problematic during testing of the vehicle, as well as some important controllers, such as chassis controllers, appliance controllers, power controllers, and the like.

In the implementation process, the data acquisition message routing table can include information such as a target controller, a message to be acquired aiming at the target controller, a message receiving party, a message sending party and the like.

Taking the chassis controller as the target controller as an example, the CAN/CANFD/LIN data between the chassis controller and the central computing platform needs to be collected is recorded in the data acquisition message routing table, and then the CAN/CANFD/LIN data between the chassis controller and the central computing platform CAN be screened out from the communication data of the communication area controller, and the screened data is used as the data to be processed.

It should be noted that, if the first data acquisition software module directly monitors a message from the CAN bus, excessive performance consumption will be caused, so that the bus minor function of each communication area controller CAN be considered to mirror the data to be processed into one part, and the selected CAN/CANFD/LIN data will be forwarded as it is by the bus minor function.

In one example, the data to be processed may be mirrored, and the mirrored data may be encapsulated according to a preset data encapsulation protocol, where the preset data encapsulation protocol includes an ethernet frame format and a payload, to obtain an ethernet packet.

The communication area controller needs to encapsulate and forward the mirrored Data according to a agreed protocol, in a specific implementation, the format of an ethernet frame in a preset Data encapsulation protocol may be an ethernet V2 frame, and payload Data may be composed of a Header and Data. The Header portion may include parameters such as a cycle count, a time stamp, a data length, etc., where the cycle count is used to determine whether the received data is continuous; the Header timestamp indicates that the time of collection has started; the data length indicates the data length after the Header, which is the sum of the lengths of all the data items in the target frame. The Data part can contain a plurality of pieces of Data, each piece of Data is independent Data, and the Data can contain parameters such as a time stamp, a network type, a network ID, a network state, a message ID, payloadLength, payload and the like, wherein the time stamp is the time offset between the receiving of a source Data frame and the time stamp of a Header, and indicates the time elapsed since the Data item starts to be collected to a target frame; the network type represents the type of the source network segment, and CAN and LIN are distinguished; the network ID indicates the division of each CAN network segment and LIN network segment under the SOA architecture; the network status indicates the status of the corresponding network segment, such as bus online, bus off, frames lost, etc.; the message ID is the ID of the source data frame; the Payload length indicates the source data frame data field length, and the Payload is the source data frame data.

The first data acquisition software module can receive the Ethernet data packets from each communication area controller through an Ethernet socket, and then analyze and store the received Ethernet data packets according to a preset data encapsulation protocol and a preset database management (DataBase Commander, DBC) file.

Fig. 5 shows a data flow diagram of step 203 in an embodiment, as shown in fig. 5, each communication area controller uses a bus minor function to mirror and package data to be processed of the corresponding communication area controller, obtain an ethernet packet, and sends the ethernet packet to a data acquisition software module adapter_m on a core of the vehicle body domain controller a.

In one example, the ethernet packet may be sent to the user datagram protocol server of the data acquisition software module through an ethernet bus corresponding to the communication area controller, so that the user datagram protocol server adds a data source tag to the ethernet packet; and sending the Ethernet data packet added with the data source mark to a first data acquisition software module so that the first data software module analyzes the Ethernet data packet added with the data source mark.

It will be appreciated that the user datagram protocol (User Datagram Protocol, UDP) server provides a way for applications to send encapsulated IP packets without establishing a connection. The Ethernet data packet is sent to the UDP server of the data acquisition software module, and the UDP server adds a data source mark to the data packet forwarded by the different communication area controllers after receiving the Ethernet data packet, so that the data corresponding to the different communication area controllers can be specifically analyzed in the subsequent analysis, and the situation that the same message ID appears in different network segments is solved.

And 204, analyzing the first acquired data, the second acquired data and the third acquired data to obtain target data.

It can be appreciated that, because the data sources of the first collected data, the second collected data and the third collected data are different, the method adopted by the first data collection software module when analyzing the data is also different.

FIG. 6 shows a detailed flow diagram of 204 in one embodiment, as shown in FIG. 6, step 204 may include the steps of:

step 601, a first signal definition configuration file may be determined according to a preset data protocol, and the first collected data is parsed according to the first signal definition configuration file to obtain triplet data corresponding to each signal in the first collected data, where the triplet data includes a timestamp, a signal name and a signal value;

step 602, determining a second signal definition configuration file according to a preset SOMEIP communication matrix, and analyzing the second acquired data according to the second signal definition configuration file to obtain triplet data corresponding to each signal in the second acquired data;

step 603, determining a third signal definition configuration file according to a preset data encapsulation protocol and a preset database management file, and analyzing the third collected data according to the third signal definition configuration file to obtain triplet data corresponding to each signal in the third collected data;

And step 604, determining all the obtained triplet data as target data.

It can be understood that the preset data protocol is to be used as an analysis basis of the first collected data, and is firstly converted into a first signal definition configuration file which can be loaded and analyzed at the vehicle end, and then the first signal definition configuration file is loaded to analyze the first collected data, so as to obtain the triplet data corresponding to each signal in the first collected data.

In a specific implementation, a signal definition configuration analyzer may be designed, which is used for loading and analyzing the M-core signal definition configuration file, and is used as a basis for subsequent data analysis. And designing a data analysis unit for the first acquired data of the M core, wherein the data analysis unit is used for analyzing the received first acquired data according to the first signal definition configuration file and the signal definition configuration analyzer, the analyzed signal names comprise data sources, categories and specific signal names, the signal values are converted according to the physical value conversion range in the first signal definition configuration file, and the time stamp adopts the time stamp information in the package header. Analyzing to obtain the content of a single signal in the first collected data as triplet data containing < Timestamp Name Data >, and forwarding the data according to the requirement of subsequent data processing.

It can be understood that when the bottom layer communication component issues the sometip communication data through the IPC API interface, the issue theme name Topic and the message content MessageData part of the contents are both from the preset sometip communication matrix, so that the ServiceName, method _or_eventname, field Property Data Type and other information in the sometip communication matrix are the analysis basis of the sometip communication data, and the preset sometip communication matrix needs to be converted into a second signal definition configuration file that can be loaded and analyzed at the vehicle end, and then the second signal definition configuration file is loaded to complete data analysis.

In a specific implementation, a signal definition configuration analyzer (if there are multiple operating systems on a domain controller, an independent analyzer is designed for data of each operating system) may be designed for each domain controller according to the second signal definition configuration file, and the signal definition configuration file is used for loading and analyzing the signal definition configuration file of the corresponding domain controller, so as to be used as a basis for subsequent data analysis. Meanwhile, a data analysis unit corresponding to each domain controller can be designed in the first data acquisition software module and is used for analyzing the received second acquisition data according to the second signal definition configuration file and the signal definition configuration analyzer, the analyzed signal names comprise data sources, categories and specific signal names, the signal values are converted according to the physical value conversion range in the second signal definition configuration file, and the time stamp adopts the time stamp information of the data received by the adapter_S. Analyzing to obtain the single signal content in the second collected data as triplet data containing < Timestamp Name Data >, and forwarding the data according to the requirement of subsequent data processing.

It will be appreciated that each communication area controller encapsulates mirrored data (i.e. source packets) according to a preset data encapsulation protocol, which includes various types of main information related to the source packets, such as a timestamp, a packet ID, a network type, and a specific source data frame, etc., so that the first data acquisition software module resolves the third acquired data according to the preset data encapsulation protocol and a preset database management (DataBase Commander, DBC) file.

In a specific implementation, the preset data encapsulation protocol and the preset DBC file may be first converted into a third signal definition configuration file that may be loaded and analyzed at the vehicle end, and then a signal definition configuration analyzer is designed for the CAN/CANFD/LIN data according to the third signal definition configuration file, so as to load and analyze the signal definition configuration file as a basis for subsequent data analysis. And then designing a specific data analysis unit, and analyzing the received third acquired data according to the third signal definition configuration file and the signal definition configuration analyzer, wherein the analyzed signal name comprises a data source (namely which communication area controller the Ethernet data packet comes from), a CANID, a message name and a specific signal name. The signal value can be converted according to a physical value conversion parameter defined in a preset DBC file; the time stamp is calculated by adopting header time in the message and the offset of each frame of message. Analyzing to obtain the content of a single signal in the third acquired data as triplet data containing < Timestamp Name Data >, and forwarding the triplet data according to the requirement of subsequent data processing.

It should be noted that, the triplet data is the data that can identify the minimum dimension of the signal in each collected data, and by converting the signal in each collected data into the triplet data, the processing efficiency of the data can be effectively improved.

According to the scheme, the vehicle data can be collected and analyzed in full quantity on the basis of not increasing hardware equipment, and the processing cost of the vehicle data is reduced.

In a specific implementation, the first core may further be provided with a data storage module and a data calculation module, and it is to be understood that the data storage module is configured to receive target data from the first data acquisition software module, compress and store the target data, and simultaneously receive a query instruction sent from the first data acquisition software module and the data calculation module, search for required target data, and upload the target data to the cloud server. The data calculation module is used for receiving the target data from the first data acquisition software module in real time, and sending a query instruction to the data storage module when the received target data meets specific event triggering logic so as to enable the data storage module to search the required target data and upload the target data to the cloud server.

After receiving the target data, the data storage module firstly compresses and stores the target data in a full local mode. Compression to increase data storage utilization, storing more data in the same space; the full local storage is to ensure availability of historical data and that the data can be uploaded as needed.

FIG. 7 is a schematic data flow diagram of a vehicle data processing method based on a service oriented architecture according to another embodiment, as shown in FIG. 7, a first data acquisition software module adapter_M acquires original data of an M core through an inter-core communication IPCF technology to obtain first acquired data; the first data acquisition software module adapter_M acquires SOMEIP communication data of the vehicle body domain controller, and receives SOMEIP communication data from the second data acquisition software module adapter_S of the other domain controllers to obtain second acquisition data; the first data acquisition software module adapter_M receives the Ethernet data packet packaged by each communication area controller after being mirrored through the bus mirror function, and third acquisition data is obtained; and the first data acquisition software module adapter_M sends the acquired first acquired data, second acquired data and third acquired data to the data calculation module and the data storage module.

In some embodiments, the service-oriented architecture-based vehicle data processing method may further include the steps of: receiving a query instruction sent by a cloud server; sending the query instruction to the data storage module so that the data storage module searches target data corresponding to the query instruction; and acquiring target data corresponding to the query instruction from the data storage module and uploading the target data to the cloud server.

It will be appreciated that when a vehicle fails and a problem needs to be located, the problem can only be located by the historical data at the time of the failure, since most of the problems are not easily reproduced and the problem is more difficult to require reproduction after the vehicle is delivered to the user.

The cloud server can send a query instruction for querying historical data to the fault vehicle, a first data acquisition software module deployed in a vehicle body domain controller A core of the vehicle end receives the query instruction and sends time period information in the query instruction and content to be queried to a data storage module, the data storage module searches target data in a corresponding time period and sends the target data to the first data acquisition software module, and the first data acquisition software module sends the searched target data back to the cloud server.

In some embodiments, the data processing method of the vehicle body domain controller may further include: and sending the target data to the data calculation module and the data storage module, so that the data calculation module sends a query instruction to the data storage module under the condition that the target data meets the preset trigger condition, and the data storage module uploads historical data corresponding to the query instruction to the cloud server.

It will be appreciated that when some major faults occur in the vehicle, it is generally required to send the fault information and the data related to the fault time point to the after-sales personnel and development engineers at the first time, and at this time, the vehicle end is required to calculate and detect whether the corresponding triggering event occurs in real time.

And creating preset trigger conditions of the event trigger algorithm at the cloud server, issuing the algorithm to a data calculation module at the vehicle end to perform real-time calculation of the algorithm, and loading the data into the preset trigger conditions to perform real-time calculation after receiving the target data by the data calculation module. When the event is calculated and detected in real time, the data calculation module sends a corresponding query instruction to the data storage module, the data storage module searches the required data content from t0 before the fault moment to t1 after the fault moment according to the query instruction, the searched data is sent to the first data acquisition software module, and the first data acquisition software module sends the searched event data back to the cloud server. And after receiving the data uploaded by the event trigger, the cloud server reminds corresponding after-sales personnel and development engineers through mails.

According to the scheme, the method and the system for acquiring the vehicle-mounted data comprise the steps of acquiring the most main data (observed quantity data, CAN/CANFD/LIN data and SOMEIP communication data) of the whole vehicle, storing the whole historical data at the vehicle end, uploading the historical data according to the query requirement and uploading the data in a specific time period according to the event triggering rule, so that the whole acquisition of various key communication data in the vehicle based on the SOA architecture CAN be ensured, the data CAN be flexibly uploaded to the cloud as required, the situation of data loss CAN not occur, and the cost of vehicle research and development, test, manufacturing and after-sale troubleshooting CAN be reduced.

The following describes an embodiment of an apparatus of the present application that may be used to perform the vehicle data processing method based on the service-oriented architecture in the above embodiment of the present application. For details not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the vehicle data processing method based on the service oriented architecture.

Referring to FIG. 8, a block diagram of a service-oriented architecture-based vehicle data processing device in an embodiment of the present application is shown.

As shown in fig. 8, a vehicle data processing device based on a service oriented architecture according to an embodiment of the present application is applied to a vehicle, the vehicle includes a central computing platform and a communication area controller, the central computing platform includes a vehicle body domain controller and a plurality of other domain controllers, the vehicle body domain controller includes a first core and a second core, a computing power of the first core is greater than a computing power of the second core, a vehicle data collecting device based on the service oriented architecture is disposed in the first core, and the device includes: a first acquisition unit 801, configured to acquire original data of the second core, to obtain first acquired data; the second acquisition unit 802 is configured to acquire sometip communication data of the vehicle body domain controller and other domain controllers, so as to obtain second acquired data; a third collection unit 803, configured to collect communication data of the communication area controller, to obtain third collected data; the data parsing unit 804 is configured to parse the first collected data, the second collected data, and the third collected data to obtain target data.

In some embodiments of the present application, based on the foregoing solution, the first collecting unit 801 is further configured to encapsulate an operation of performing inter-core communication between the first core and the second core into an application programming interface; the raw data is received from the second core by invoking the application programming interface.

In some embodiments of the present application, based on the foregoing solution, the application programming interface includes an application software component interface and an inter-core communication proxy interface, and the first acquisition unit 801 is further configured to receive, by calling the inter-core communication proxy interface, raw data from the second core, where the raw data is data output by each application of the second core by calling the application software component interface.

In some embodiments of the present application, based on the foregoing solution, the second data acquisition software module is disposed in each of the other domain controllers, and the second acquisition unit 802 is further configured to acquire the first sometip communication data of the vehicle body domain controller in the call service state; and receiving second SOMEIP communication data sent by the second data acquisition software module under the calling service state by other domain controllers.

In some embodiments of the present application, based on the foregoing solution, the third collecting unit 803 is further configured to receive an ethernet packet from an ethernet bus corresponding to the communication area controller, where the ethernet packet is obtained by screening, mirroring, and encapsulating the communication data of the communication area controller.

In some embodiments of the present application, based on the foregoing scheme, the data parsing unit 804 is further configured to determine a first signal definition configuration file according to a preset data protocol, and parse the first collected data according to the first signal definition configuration file to obtain triplet data corresponding to each signal in the first collected data, where the triplet data includes a timestamp, a signal name and a signal value; determining a second signal definition configuration file according to a preset SOMEIP communication matrix, and analyzing the second acquired data according to the second signal definition configuration file to obtain triplet data corresponding to each signal in the second acquired data; determining a third signal definition configuration file according to a preset data encapsulation protocol and a preset database management file, and analyzing the third acquired data according to the third signal definition configuration file to obtain triplet data corresponding to each signal in the third acquired data; and determining all the obtained triplet data as target data.

In some embodiments of the present application, based on the foregoing solution, the first core is further configured with a data storage module, and the vehicle data acquisition device based on the service-oriented architecture further includes a data uploading unit (not shown) configured to receive a query instruction sent by the cloud server; sending the query instruction to the data storage module so that the data storage module searches target data corresponding to the query instruction; and acquiring target data corresponding to the query instruction from the data storage module and uploading the target data to the cloud server.

Based on the same inventive concept, the embodiment of the present application further provides a service-oriented architecture-based vehicle data acquisition device, referring to fig. 9, which shows a schematic structural diagram of the service-oriented architecture-based vehicle data acquisition device in the embodiment of the present application, where the service-oriented architecture-based vehicle data acquisition device includes one or more memories 904, one or more processors 902 and at least one computer program (computer program instructions) stored on the memories 904 and executable on the processors 902, and when the processors 902 execute the computer program implement the method as described above.

Where in FIG. 9 a bus architecture (represented by bus 900), bus 900 may include any number of interconnected buses and bridges, with bus 900 linking together various circuits, including one or more processors, represented by processor 902, and memory, represented by memory 904. Bus 900 may also link together various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., as are well known in the art and, therefore, will not be described further herein. The bus interface 905 provides an interface between the bus 900 and the receiver 901 and the transmitter 903. The receiver 901 and the transmitter 903 may be the same element, i.e. a transceiver, providing a unit for communicating with various other apparatus over a transmission medium. The processor 902 is responsible for managing the bus 900 and general processing, while the memory 904 may be used to store data used by the processor 902 in performing operations.

Based on the same inventive concept, embodiments of the present application provide a computer-readable storage medium having stored therein at least one computer program instruction that is loaded and executed by a processor to implement operations performed by the method as described above.

The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software that is executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope and spirit of the application and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired, or a combination of any of these. In addition, each functional unit may be integrated in one processing unit, each unit may exist alone physically, or two or more units may be integrated in one unit.

In the several embodiments provided in the present application, it should be understood that the disclosed technology may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, for example, may be a logic function division, and may be implemented in another manner, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described as separate components may or may not be physically separate, and components as control devices may or may not be physical units, may be located in one place, or may be distributed over a plurality of units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a usb disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a removable hard disk, a magnetic disk, or an optical disk, or other various media capable of storing computer program instructions.

The above description is only an example of the present application and is not intended to limit the present application, but various modifications and variations can be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A vehicle data processing method based on a service oriented architecture, applied to a vehicle, the vehicle comprising a central computing platform and a communication area controller, the central computing platform comprising a body area controller and a plurality of other area controllers, the body area controller comprising a first core and a second core, the first core having a greater computational power than the second core, a first data acquisition software module disposed in the first core, the method comprising:

2. The service-oriented architecture-based vehicle data processing method of claim 1, wherein the collecting the raw data of the second core comprises:

3. The service-oriented architecture-based vehicle data processing method of claim 2, wherein the application programming interface includes an application software component interface and an inter-core communication proxy interface, the receiving the raw data from the second core by invoking the application programming interface comprising:

4. The service-oriented architecture-based vehicle data processing method according to claim 1, wherein a second data acquisition software module is deployed in each of the other domain controllers, the somei communication data includes first somei communication data and second somei communication data, and the acquiring the somei communication data of the vehicle body domain controller and the other domain controllers includes:

5. The service-oriented architecture-based vehicle data processing method according to claim 1, wherein the collecting the communication data of the communication area controller includes:

6. The service-oriented architecture-based vehicle data processing method according to claim 1, wherein the parsing the first collected data, the second collected data, and the third collected data to obtain target data includes:

and determining all the obtained triplet data as the target data.

7. The service-oriented architecture-based vehicle data processing method of claim 1, wherein the first core further has a data storage module disposed therein, the method further comprising:

receiving a query instruction sent by a cloud server;

8. A service-oriented architecture-based vehicle data acquisition device, characterized by being applied to a vehicle, the vehicle comprising a central computing platform and a communication area controller, the central computing platform comprising a body area controller and a plurality of other area controllers, the body area controller comprising a first core and a second core, the first core having a greater computational power than the second core, the first core having disposed therein a service-oriented architecture-based vehicle data acquisition device, the device comprising:

9. A service-oriented architecture-based vehicle data acquisition device comprising a processor and a memory, characterized in that the memory stores computer program instructions executable by the processor, which processor, when executing the computer program instructions, implements the instructions of the method according to any one of claims 1 to 7.

10. A computer readable storage medium having stored therein computer program instructions that are loaded and executed by a processor to implement operations performed by the method of any one of claims 1 to 7.