Data observation method, device, equipment and system based on service-oriented architecture

Abstract

The application discloses a kind of based on service-oriented architecture data observation method, device, equipment and system, involve vehicle-mounted communication technical field, the based on service-oriented architecture data observation method includes: after being connected with host computer, receiving and analyzing observation request sent by the host computer, obtains target interface name, observation parameter and service identification number;According to the target interface name, the observation parameter and the service identification number, the observation request is sent to the application to be observed by extensible service middleware protocol, to make the application to be observed feedback observation data;Receive the observation data, and the observation data is sent to the host computer, to make the host computer complete data observation according to the observation data.The application effectively supports the real-time and accuracy requirement of data observation in vehicle-mounted system, can carry out data observation in real time, so as to improve the performance monitoring, fault diagnosis and optimization ability of system.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to data observation methods, apparatus, devices and systems based on service-oriented architecture. Background Technology

[0002] With the continuous development of automotive electronics technology, modern vehicles are equipped with a large number of Electronic Control Units (ECUs) to control and monitor the operating status of various onboard systems. To ensure vehicle safety and reliability, real-time monitoring of data from these ECUs has become particularly important.

[0003] Currently, data observation of automotive ECUs is primarily achieved through online monitoring of the microcontroller unit (MCU) software using an in-vehicle network emulator (CAN open environment, CANoe). If system-level data (such as system-on-chip (SOC) data needs to be observed, a signal-to-service (S2S) module is typically used to transmit data from the SOC to the MCU, which is then observed via CANoe. This method requires multiple steps and intermediate stages, relying on traditional CAN bus communication to gradually collect and process data.

[0004] Existing methods involve multiple intermediate steps in data transmission, resulting in a long data transmission chain and compromising real-time performance. Furthermore, encapsulating and processing raw data through the MCU consumes significant resources, impacting the MCU's computing power and overall performance. This approach is not only inefficient but also increases the complexity of vehicle development and maintenance. Therefore, real-time data observation is a pressing issue that needs to be addressed.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The purpose of this application is to provide a data observation method, apparatus, device and system based on a service-oriented architecture, which aims to solve the technical problem of how to perform data observation in real time.

[0007] To achieve the above objectives, this application proposes a data observation method based on a service-oriented architecture, which is applied to an in-vehicle system. The method includes:

[0008] After connecting to the host computer, the system receives and parses the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier.

[0009] Based on the target interface name, the observation parameters, and the service identifier, the observation request is sent to the application to be observed through the extensible service middleware protocol, so that the application to be observed can provide feedback on the observation data.

[0010] The system receives the observation data and sends it to the host computer so that the host computer can complete the data observation based on the observation data.

[0011] In one embodiment, the step of receiving and parsing the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier includes:

[0012] The observation request sent by the host computer is received using a blocking reception method;

[0013] The checksum is obtained based on the observation request;

[0014] The integrity and validity of the observation request are verified based on the checksum, and the verification result is obtained;

[0015] When the verification result is incorrect, a request error message is sent to the host computer so that the host computer resends the observation request;

[0016] When the verification result is correct, the observation request is parsed to obtain the target interface name, observation parameters, and service identifier.

[0017] In one embodiment, the step of sending the observation request to the application to be observed via an extensible service middleware protocol based on the target interface name, the observation parameters, and the service identifier includes:

[0018] Generate a message identifier based on the target interface name and the service identifier;

[0019] Generate header information based on the message identifier;

[0020] Load data is generated based on the observed parameters;

[0021] An observation request message is created based on the header information and the payload data;

[0022] Load and initialize the extensible service middleware protocol stack;

[0023] The observation request message is encapsulated into a data packet using an extensible service middleware protocol;

[0024] The data packets are sent to the application to be observed through the extensible service middleware protocol stack.

[0025] In one embodiment, after the step of sending the observation request to the application to be observed via the extensible service middleware protocol, the method further includes:

[0026] When the observation request is sent to the application to be observed, the sending time is recorded;

[0027] Get the current time;

[0028] When the time difference between the current time and the sending time is greater than the preset maximum time difference, the observation request is resent to the application to be observed.

[0029] In one embodiment, the step of connecting to the host computer includes:

[0030] Configure network interface parameters and network stack, and broadcast service information using the service discovery protocol to enable the host computer to provide feedback information.

[0031] Parse the response information to obtain the IP address and port number of the host computer;

[0032] Based on the IP address and the port number, a test message is sent to the host computer to enable the host computer to send a response message. The test message includes a first timestamp and a first sequence number.

[0033] Receive and parse the response message to obtain the second timestamp and the second sequence number;

[0034] When the first serial number and the second serial number are the same and the time difference between the first timestamp and the second timestamp is less than or equal to a preset time difference value, a connection is established with the host computer through a preset protocol.

[0035] Furthermore, to achieve the above objectives, this application also proposes a data observation method based on a service-oriented architecture, which is applied to a host computer and includes:

[0036] After connecting to the vehicle system, an observation request is sent to the vehicle system so that the vehicle system can provide feedback on the observation data.

[0037] Obtain observation parameters;

[0038] The system receives the observation data, maps the observation data to the observation parameters, and displays the data on the user interface to complete the data observation.

[0039] In one embodiment, the step of mapping the observation data to the observation parameters includes:

[0040] Load a preset mapping table, which includes the field names of the observation data and the corresponding observation parameter names;

[0041] The observation data is parsed into key-value pairs to obtain the target observation data;

[0042] According to the preset mapping table, the field names of the target observation data and the observation parameter names of the observation parameters are matched to complete the mapping.

[0043] Furthermore, to achieve the above objectives, this application also proposes a data observation device based on a service-oriented architecture, the device comprising:

[0044] The request receiving module is used to receive and parse the observation request sent by the host computer after connecting to the host computer, and obtain the target interface name, observation parameters and service identifier number;

[0045] The data acquisition module is used to send the observation request to the application to be observed through the extensible service middleware protocol according to the target interface name, the observation parameters and the service identifier, so that the application to be observed can feed back the observation data.

[0046] The data transmission module is used to receive the observation data and send the observation data to the host computer so that the host computer can complete the data observation based on the observation data.

[0047] Furthermore, to achieve the above objectives, this application also proposes a data observation device based on a service-oriented architecture, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data observation method based on a service-oriented architecture as described above.

[0048] In addition, to achieve the above objectives, this application also proposes a data observation system based on a service-oriented architecture, the system including the vehicle-mounted system and host computer described above.

[0049] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the data observation method based on service-oriented architecture as described above.

[0050] One or more technical solutions proposed in this application have at least the following technical effects:

[0051] After connecting to the host computer, the system receives and parses the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier. Based on the target interface name, the observation parameters, and the service identifier, the system sends the observation request to the application to be observed through an extensible service middleware protocol, so that the application to be observed can provide feedback on the observation data. The system receives the observation data and sends it to the host computer, so that the host computer can complete the data observation based on the observation data. In this application, after establishing a connection with the host computer, the system receives and parses the observation request from the host computer, extracting the target interface name, observation parameters, and service identifier. This information is obtained to accurately locate the data source and parameters to be observed. Next, based on the obtained target interface name, observation parameters, and service identifier, the system uses an extensible service middleware protocol to transmit the observation request to the application to be observed. This process ensures that the required data can be accurately delivered to the target application for subsequent data observation and processing. After the data is processed by the observation application and observation data is generated, the system receives this data sent by the application and sends it to the host computer, enabling the host computer to use this observation data to complete further data observation and analysis. The entire process forms a closed-loop system, which effectively supports the real-time and accuracy requirements of data observation in the vehicle system. It enables real-time data observation, thereby improving the system's performance monitoring, fault diagnosis, and optimization capabilities. Attached Figure Description

[0052] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0053] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a flowchart illustrating an embodiment of the service-oriented architecture-based data observation method for in-vehicle systems applied in this application.

[0055] Figure 2 This is a flowchart illustrating Embodiment 2 of the data observation method based on a service-oriented architecture applied to a host computer, as described in this application.

[0056] Figure 3 This is a schematic diagram of the module structure of the data observation device based on a service-oriented architecture according to an embodiment of this application;

[0057] Figure 4This is a schematic diagram of the data observation system based on a service-oriented architecture, as described in this application.

[0058] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the data observation method based on service-oriented architecture in the embodiments of this application.

[0059] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0060] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0061] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0062] Currently, data observation of automotive ECUs primarily relies on CANoe tools for online monitoring of the MCU-side software. If system-level data (such as System-on-Chips (SoCs)) needs to be observed, an S2S module is typically used to transmit data from the SoC to the MCU, which is then observed via CANoe. This method involves numerous steps and complex intermediate stages, relying on traditional CAN bus communication to gradually collect and process data. Existing methods involve multiple intermediate stages in data transmission, resulting in a long data transmission chain and compromising real-time performance. Furthermore, the MCU consumes significant resources when packaging and processing raw data, impacting its computing power and overall performance. This approach is not only inefficient but also increases the complexity of data processing, thereby increasing the difficulty of vehicle development and maintenance.

[0063] The main solution of this application embodiment is as follows: After establishing a connection with the host computer, the system receives and parses the observation request from the host computer, extracts the target interface name, observation parameters, and service identifier, ensuring accurate location of the data source and parameters to be observed; subsequently, the system uses an extensible service middleware protocol to transmit the observation request to the application to be observed, ensuring that the data can be accurately delivered to the target application for subsequent data observation and processing; after the data is processed by the observation application and observation data is generated, the system receives and sends this data to the host computer, enabling the host computer to use this observation data to complete further data observation and analysis. The entire process constitutes a closed-loop system, effectively supporting the real-time and accuracy requirements of data observation in the vehicle system, enabling real-time data observation.

[0064] It should be noted that the executing entity of this application embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, vehicle system, or host computer capable of realizing the above functions. The following uses a vehicle system as an example to describe this embodiment and the subsequent embodiments.

[0065] Based on this, the embodiments of this application provide a data observation method based on a service-oriented architecture, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the service-oriented architecture-based data observation method applied to vehicle systems according to this application.

[0066] In this embodiment, the data observation method based on service-oriented architecture applied to the vehicle system includes steps S10 to S30:

[0067] Step S10: After connecting to the host computer, receive and parse the observation request sent by the host computer to obtain the target interface name, observation parameters and service identifier.

[0068] It should be noted that the host computer refers to the computer or device used to send observation requests and receive observation data. It is typically a tool used by testers to communicate with the vehicle system and observe data. An observation request is a message or instruction sent by the host computer to the vehicle system (usually the System-on-Chief Vehicle, SOC), requesting the acquisition of specific data or the performance of specific operations. These requests contain detailed information about the required data and request parameters. For example, an observation request from the host computer to obtain engine temperature data from the vehicle's SOC includes:

[0069] Request type: Read data;

[0070] Target interface name: EngineTemperatureInterface (the interface name responsible for providing engine temperature data);

[0071] Observation parameters: Data type: Temperature (The data type to be obtained is temperature);

[0072] Data unit: Celsius (temperature data is required in degrees Celsius);

[0073] Sampling rate: 1Hz (the data sampling rate is 1Hz, that is, data is collected once per second); Service identifier (service ID): 0x1234 (a unique identifier for the engine temperature data reading service).

[0074] The target interface name refers to the name of the specific interface in the vehicle system responsible for providing data or performing operations. This name identifies the specific interface to be accessed, ensuring that the data request is sent to the correct location. Observation parameters refer to the specific data items or settings specified in the observation request. These parameters determine the type and format of the required data; for example, observation parameters may include data sampling rate, time range, data type, etc. The service identifier (service ID) is an identifier used to uniquely identify a service or function. In the Scalable Service-Oriented Middleware over IP (SOME / IP) protocol, each service has a unique service ID to distinguish different services and functions.

[0075] Understandably, after establishing a connection with the host computer, the system begins receiving observation requests from it. First, it obtains the complete data packet of the request via the network communication interface. Next, the system parses the received request, extracting key information including the target interface name, observation parameters, and service identifier. The target interface name indicates the specific data interface to be accessed, the observation parameters contain details such as the specific data type, unit, and sampling rate, and the service identifier is used to uniquely identify the requested service. This information guides the system on how to process the request and obtain the required data.

[0076] As an example, the steps for connecting to the host computer include: configuring network interface parameters and network stack; broadcasting service information using a service discovery protocol to enable the host computer to respond; parsing the response information to obtain the IP address and port number of the host computer; sending a test message to the host computer based on the IP address and port number to enable the host computer to respond with a response message, the test message containing a first timestamp and a first sequence number; receiving and parsing the response message to obtain a second timestamp and a second sequence number; and establishing a connection with the host computer through a preset protocol when the first sequence number and the second sequence number are the same and the time difference between the first timestamp and the second timestamp is less than or equal to a preset time difference value.

[0077] Network interface parameters refer to the specific settings used to configure a network interface, such as IP address, subnet mask, gateway, and Domain Name System (DNS) server. These parameters ensure that the device can correctly connect to the network. For example, IP address: 192.168.1.2, subnet mask: 255.255.255.0, gateway: 192.168.1.1. A network stack refers to a set of software modules that implement network communication protocols, typically including various layers of the protocol stack, such as the TCP / IP protocol stack, which handles the sending and receiving of network data. Service discovery protocols refer to protocols used to automatically discover services on the network, such as mDNS (multicast DNS) or DNS-SD (DNS service discovery). These protocols allow devices to broadcast information about their available services on the network and receive service information from other devices. Service information refers to descriptive information about the services a device provides, broadcast on the network, including service type, service name, and port number. This information enables other devices to discover and connect to the service. The response message refers to the acknowledgment information sent back by the host computer after receiving the service discovery broadcast from the device. This includes the host computer's IP address and port number. The IP address is a unique identifier for a device on the network, used for communication between devices; for example, an IPv4 address in the form of xxx.xxx.xxx.xxx. The port number is the network port for a specific service on the device, used to distinguish different network services and applications. The test message is a test message sent by the device to the host computer to verify the validity of the connection. This message typically includes a timestamp and sequence number. The response message is the acknowledgment message sent back by the host computer after receiving the test message, also including a timestamp and sequence number. The first timestamp is the timestamp used to record the time the device sent the test message, such as 2024-07-15 10:00:01. The first sequence number is a unique identifier appended by the device when sending the test message, used to ensure the uniqueness and order of the message, such as 12345. The second timestamp is the timestamp used by the host computer to record the response time when sending the response message. The second sequence number refers to the unique identifier attached by the host computer in the response message, and it should be consistent with the first sequence number. The preset time difference value refers to the maximum allowed time difference, used to verify the real-time nature of message transmission. If the time difference is less than or equal to this value, the connection is considered valid, such as 1 second. The preset protocol refers to the specific network protocol used to establish and maintain the connection between the device and the host computer, such as TCP or UDP.

[0078] First, configure the device's network interface parameters (such as IP address, subnet mask, gateway, etc.) and initialize the network stack (such as TCP / IP stack) to ensure the device can communicate normally over the network. Then, use a service discovery protocol (such as mDNS) to broadcast the device's service information (such as service type, name, and port number) on the network, waiting for a response from the host computer. Upon receiving the response from the host computer, parse the IP address and port number. Next, send a test message containing a first timestamp and a first sequence number to the host computer. The host computer, upon receiving this, will send back a response message containing a second timestamp and a second sequence number. The device, upon receiving the response message, parses the timestamp and sequence number. If the two sequence numbers are the same and the time difference between the timestamps is less than or equal to a preset time difference value (e.g., 1 second), the verification is successful, and a formal connection is established with the host computer using a preset protocol (such as TCP).

[0079] As an example, the steps of receiving and parsing the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier include: receiving the observation request sent by the host computer through a blocking reception method; obtaining a checksum based on the observation request; verifying the integrity and validity of the observation request based on the checksum to obtain a verification result; when the verification result is incorrect, sending a request error message to the host computer to cause the host computer to resend the observation request; and when the verification result is correct, parsing the observation request to obtain the target interface name, observation parameters, and service identifier.

[0080] Blocking reception refers to a method where the program waits for data to arrive before continuing execution, ensuring synchronous and sequential data reception. A checksum is a numerical value obtained by performing an algorithmic operation on the data. It's used to verify whether errors occurred during transmission. It's part of the data, calculated by the sender and appended to it. The receiver recalculates using the same algorithm and compares the checksums to verify data integrity. Integrity means the data hasn't been tampered with or corrupted during transmission. By comparing checksums, the receiver can confirm that the received data matches the sent data, without loss or modification. Validity means the data conforms to the expected format and content requirements. Besides integrity verification, checksums also check data legality, such as whether fields conform to predetermined formats and whether numerical ranges are reasonable. The verification result is the conclusion drawn from methods like checksums, indicating whether the data is complete and valid. If verification passes, the data is considered reliable; otherwise, errors or tampering may have occurred during transmission. Error message is a message sent to the host computer when data verification fails, notifying it that there is a problem with the sent observation request and requesting it to be resent. This message usually contains an error code or description to help the host computer identify and correct the problem.

[0081] First, the system waits for observation request data from the host computer using a blocking reception method to ensure complete data reception. Next, a checksum is extracted from the received data to verify the integrity and validity of the request. The verification process includes calculating the checksum and comparing it with the checksum in the received data; if they do not match, the data is considered erroneous. When the verification result indicates an error, the system sends an error message to the host computer, requesting a resend of the observation request. Conversely, if the verification passes, the system parses the data to extract key information such as the target interface name, observation parameters, and service identifier. These steps ensure that the data received from the host computer can be correctly understood and processed within the system, thereby guaranteeing the accuracy and reliability of subsequent operations.

[0082] Step S20: Based on the target interface name, the observation parameters, and the service identifier, the observation request is sent to the application to be observed through the extensible service middleware protocol, so that the application to be observed can provide feedback on the observation data.

[0083] It's important to note that Scalable Service-Oriented Middleware over IP (SOME / IP) refers to a protocol that supports flexible service architectures. It's a communication protocol used in automotive and other embedded systems, enabling communication between different ECUs (Electronic Control Units) in in-vehicle networks. It supports complex applications and services, including remote diagnostics, software updates, and autonomous driving functions. The application to be observed refers to the target application or service that receives and processes observation requests and returns observation data. The observation data refers to the data returned by the application to be observed after executing the received request. This typically includes the requested parameters or other data to be observed, which is usually used to monitor, analyze, and diagnose the system's status and performance. For example, in an automotive system, multiple engine parameters need to be monitored: Target interface name: Engine Control Unit (ECU); Observation parameters: Engine speed, temperature, fuel consumption; Service ID: Service ID specific to the engine data. When the host computer sends an observation request, it requests the data for the above parameters. After the observation application (engine control unit) receives the request, it reads the current sensor data and returns the observation data: Engine speed: 3000 RPM (Revolutions Per Minute); Engine temperature: 90 degrees Celsius; Fuel consumption: 7.5L / 100km. This returned data is the observation data. The host computer can perform further analysis based on this data, such as checking whether the engine is within its normal operating range and whether there are any potential faults.

[0084] Understandably, the process begins by parsing the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier. Next, using an extensible service middleware protocol (such as SOME / IP), this information is packaged into an observation request message. This message includes the specific interface to be monitored (e.g., a specific ECU), the specific parameters (e.g., temperature, pressure), and a unique service ID. Then, this request is sent over the network to the application to be observed (e.g., the engine control unit). Upon receiving the request, the application reads relevant sensor or system data and feeds the observation data back to the host computer using the same protocol. This process ensures that the host computer can obtain the required system status data in real time.

[0085] As an example, the steps of sending the observation request to the application to be observed via the extensible service middleware protocol, based on the target interface name, the observation parameters, and the service identifier, include: generating a message identifier based on the target interface name and the service identifier; generating header information based on the message identifier; generating payload data based on the observation parameters; creating an observation request message based on the header information and the payload data; loading and initializing the extensible service middleware protocol stack; encapsulating the observation request message into a data packet via the extensible service middleware protocol; and sending the data packet to the application to be observed via the extensible service middleware protocol stack.

[0086] The message identifier is a number used to uniquely identify an observation request, which can help the target application identify and process the request. The header information is the beginning part of the data message, which contains necessary metadata, such as message identifier, protocol version, message length, sender and receiver address information, so that the receiver can correctly parse and process the message. The payload data is the actual observation request content, including specific observation parameters, which indicate the specific data type and range that the application to be observed needs to provide. The observation request message is a complete observation request message, which contains header information and payload data, and is encapsulated according to the message encapsulation format defined by the protocol stack. It is used to send the request to the target application for observation data. Taking the SOME / IP (Scalable service-Oriented Middleware over IP) protocol as an example, the message encapsulation format includes the following main parts: (1) Message header: Message ID: The identifier used to identify the service and method. The message ID is usually a 32-bit integer, with the first 16 bits representing the service ID and the last 16 bits representing the method ID. Length: The total length of the message, including the header and payload, which is usually a 32-bit integer. Request ID: An identifier used to uniquely identify a request-response interaction, usually consisting of client ID and session ID, totaling 32 bits. Protocol Version: Represents the version of the SOME / IP protocol, usually an 8-bit integer. Interface Version: Represents the version of the service interface, usually an 8-bit integer. Message Type: Represents the type of message, such as request, response, notification, etc., usually an 8-bit integer. Return Code: Represents the return status of the response message, usually an 8-bit integer. (2) Payload: Service method parameters: Specific observation parameters and request data content. This part is variable-length, and the specific format depends on the definition of the service and method. The extensible service middleware protocol stack refers to the collection of software components that implement the extensible service middleware protocol (such as SOME / IP). It is responsible for handling various functions of the protocol, such as message packing, unpacking, sending, receiving, and routing. A data packet is a data unit transmitted over a network. It is encapsulated from an observation request message and transmitted according to network protocols so that the application to be observed can receive and process it.

[0087] First, a unique message identifier is generated based on the target interface name and service identifier. This identifier is used to determine the specific service and method. Next, header information is created based on the generated message identifier. The header information includes important fields such as message ID, message length, request ID, protocol version, interface version, message type, and return code. Then, payload data is generated based on the observation parameters. This payload data specifically contains the parameter values ​​to be observed. The header information and payload data are combined to form a complete observation request message. Afterward, the extensible service middleware protocol stack is loaded and initialized, ensuring the protocol stack is ready. Next, the observation request message is encapsulated into a data packet using the extensible service middleware protocol. During the encapsulation process, necessary network layer information, such as Ethernet headers, IP headers, and UDP headers, is added. Finally, the encapsulated data packet is sent to the network address of the application to be observed using the extensible service middleware protocol stack, ensuring that the request message reaches the target application and triggers corresponding processing and data feedback.

[0088] As an example, after sending the observation request to the application to be observed via the extensible service middleware protocol, the method further includes: recording the sending time when the observation request is sent to the application to be observed; obtaining the current time; and resending the observation request to the application to be observed when the time difference between the current time and the sending time is greater than a preset maximum time difference.

[0089] The sending time refers to the specific timestamp record of the observation request being sent to the application being observed, usually in milliseconds or microseconds, used to track the sending time of the request. The current time refers to the current system time when the observation request needs to be resent, also in milliseconds or microseconds. The preset maximum time difference is a set time threshold used to determine if the response time of the observation request exceeds expectations. If it does, the observation request is resent to ensure the timeliness and accuracy of data observation. First, the sending time is recorded, meaning the current system time is recorded as the timestamp of the observation request, used for subsequent time difference calculation and monitoring. Next, the current time is obtained, i.e., the current system timestamp is obtained. Then, the time difference is calculated to determine if the difference between the current time and the sending time exceeds the preset maximum time difference. If the time difference between the current time and the sending time is greater than the preset maximum time difference, it indicates that the response time of the observation request exceeds the expected threshold, and the observation request needs to be resent to the application being observed to ensure timely acquisition of observation data and maintain the real-time and accuracy of data collection.

[0090] Step S30: Receive the observation data and send the observation data to the host computer so that the host computer can complete the data observation based on the observation data.

[0091] It should be noted that data observation refers to real-time data or monitoring data obtained from the application or system being observed. Specifically, this data includes system performance indicators, operating status, sensor data, log information, etc. This data is collected, processed, and transmitted through the observation application, and finally supplied to the host computer for further analysis, display, or recording.

[0092] Understandably, the process begins by receiving observation data streams from the application being observed via a pre-defined communication protocol or interface. Once received, these streams need to be parsed and processed, typically including data decoding, verification, and possible format conversion to ensure accuracy and integrity. After processing, following a series of data preprocessing and possible analysis steps, the processed data is sent back to the host computer. This data is then used on the host computer for further observation and analysis, enabling system performance monitoring, problem diagnosis, or other related data-driven activities.

[0093] This embodiment provides a data observation method based on a service-oriented architecture. After connecting to a host computer, the method receives and parses the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier. Based on the target interface name, the observation parameters, and the service identifier, the method sends the observation request to the application to be observed through an extensible service middleware protocol, so that the application to be observed can provide feedback on the observation data. The method receives the observation data and sends it to the host computer, so that the host computer can complete the data observation based on the observation data. In this embodiment, after establishing a connection with the host computer, the system receives and parses the observation request from the host computer, extracting the target interface name, observation parameters, and service identifier. This information is used to accurately locate the data source and parameters to be observed. Next, based on the obtained target interface name, observation parameters, and service identifier, the system uses an extensible service middleware protocol to transmit the observation request to the application to be observed. This process ensures that the required data is accurately delivered to the target application for subsequent data observation and processing. After the data is processed by the observation application and observation data is generated, the system receives this data from the application and sends it to the host computer, enabling the host computer to use this observation data for further data observation and analysis. The entire process constitutes a closed-loop system, effectively supporting the real-time and accuracy requirements of data observation in the vehicle system, enabling real-time data observation, thereby improving the system's performance monitoring, fault diagnosis, and optimization capabilities.

[0094] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2This is a flowchart illustrating the second embodiment of the service-oriented architecture-based data observation method applied to a host computer, which includes steps S40 to S60:

[0095] Step S40: After connecting to the vehicle system, send an observation request to the vehicle system so that the vehicle system can feed back observation data;

[0096] Understandably, after successfully establishing a connection with the vehicle-mounted system, the host computer sends specific observation requests to the system. These requests typically specify the data types, parameters, or specific system status information to be observed. The vehicle-mounted system receives and processes these requests, performing corresponding operations and data acquisition based on their content. Subsequently, the vehicle-mounted system feeds the observed data back to the host computer, enabling it to acquire and analyze this data for further system monitoring, analysis, and optimization. This process ensures that the host computer can obtain critical data from the vehicle-mounted system in real time to support remote monitoring and management needs.

[0097] Step S50: Obtain observation parameters;

[0098] It should be noted that observation parameters refer to the parameters specified by the host computer when sending an observation request. These parameters are the parameters of the data that the host computer wants to observe, and they are used to determine which specific data the vehicle system needs to feed back. For example, observation parameters may include readings from various sensors (such as temperature, pressure, speed, etc.), system operating status (such as CPU utilization, memory usage, etc.), vehicle location information, battery status, etc. These parameters are crucial for real-time monitoring and remote management of the system.

[0099] Understandably, firstly, the user selects or inputs the specific items to be monitored on the host computer interface, such as temperature sensor data, engine status, speed information, etc.; then, the host computer converts these selections or inputs into specific observation parameters, which may include information such as data type, measurement frequency, and data format; these observation parameters are used not only when sending observation requests, but also when the host computer performs data observations to ensure that the vehicle system can provide feedback and process the corresponding observation data, and finally display or record this data on the host computer.

[0100] Step S60: Receive the observation data, map the observation data onto the observation parameters, and display it on the user interface to complete the data observation.

[0101] It should be noted that the user interface refers to the interface used for display and interaction in the host computer software. Through this interface, users can see real-time data observation results. Specifically, the user interface includes visual elements such as dashboards, charts, and numerical display areas, which can intuitively present the observation data received from the vehicle system. For example, temperature sensor data can be displayed on a thermometer icon, and speed information can be displayed in numerical form or as a line graph. These visual elements enable users to easily monitor and analyze the status and performance of the vehicle system.

[0102] Understandably, the host computer first receives the observation data from the vehicle system, then matches and maps this data with the predefined observation parameters, that is, converts the raw data into corresponding meaningful parameter values. Next, these mapped parameter values ​​are transmitted to the user interface and visualized in different display areas of the user interface, such as the dashboard, charts, and numerical display areas. In this way, users can intuitively view and analyze real-time data, understand the current status and performance of the vehicle system, and finally complete the entire data observation process.

[0103] As an example, the step of mapping the observation data to the observation parameters includes: loading a preset mapping table, which includes the field names of the observation data and the corresponding observation parameter names; parsing the observation data into key-value pairs to obtain the target observation data; and matching the field names of the target observation data with the observation parameter names of the observation parameters according to the preset mapping table to complete the mapping.

[0104] A predefined mapping table is a predefined table or data structure used to associate field names of observed data with their corresponding observation parameter names. It contains each field in the observed data and its corresponding parameter name, enabling accurate mapping after data reception. Field names are identifiers or labels for each data item in the observed data, used to identify the meaning of each data item. For example, in a JSON object, "temperature" or "speed" could be field names. Observation parameter names are parameter names defined in the host computer, used to represent the meaning of the observed data. They are user-defined variable names that correspond to field names. For example, the observation parameter name corresponding to the field name "temp" might be "Temperature". Key-value pairs are a way of representing data where each data item contains a unique key (field name) and a corresponding value (data). For example, {"temperature":25,"speed":60} is a key-value pair of observed data. Target observed data is the data portion parsed from the observation request that needs to be mapped and displayed. It contains specific observed values, such as temperature and speed. First, the system loads a preset mapping table containing the field names of the observed data and their corresponding observation parameter names. Next, the received observation data is parsed into key-value pairs, converting data items into "field name: value" format to obtain the target observation data. Then, according to the definitions in the preset mapping table, the field names in the target observation data are matched with the preset observation parameter names to complete the data mapping. This is done to ensure that the received raw data accurately corresponds to the parameters displayed on the user interface, allowing users to intuitively understand and use this data.

[0105] In this embodiment, after connecting to the vehicle-mounted system, an observation request is sent to the vehicle-mounted system to enable the system to provide observation data. Observation parameters are then acquired. The observation data is received, mapped to the observation parameters, and displayed on the user interface to complete the data observation. In this embodiment, the host computer first establishes a connection with the vehicle-mounted system, typically via a network protocol such as TCP / IP. After the connection is established, the host computer sends an observation request containing detailed information about the data it wishes to acquire (e.g., data from specific sensors). This ensures that the host computer can actively acquire the required data, rather than passively waiting for it to arrive, thereby improving the timeliness and flexibility of data acquisition. After sending the observation request, the host computer needs to prepare or confirm the required observation parameters. These parameters define the data type and range (e.g., temperature, speed) that the host computer wishes to observe. These parameters may be read from a preset configuration file or dynamically generated based on user input. When measuring parameters, the host computer can accurately inform the vehicle system of the specific data it needs, thereby avoiding unnecessary data transmission and improving the efficiency and effectiveness of data transmission. After receiving the observation data from the vehicle system, the host computer needs to process this data. First, it converts the field names of the observation data into the observation parameter names displayed on the user interface through a preset mapping table. Then, it displays the processed data on the user interface for users to view and analyze. This processing and display method ensures the readability and user-friendliness of the data. Users can intuitively see the observation data and make corresponding judgments and decisions based on this data. It also improves the real-time monitoring capability of the system and ensures that users can understand the vehicle's operating status in a timely manner.

[0106] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data observation method based on service-oriented architecture of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0107] This application also provides a data observation device based on a service-oriented architecture; please refer to [reference needed]. Figure 3 The data observation device based on service-oriented architecture includes:

[0108] The request receiving module 10 is used to receive and parse the observation request sent by the host computer after connecting with the host computer, and obtain the target interface name, observation parameters and service identifier number;

[0109] The data acquisition module 20 is used to send the observation request to the application to be observed through the extensible service middleware protocol according to the target interface name, the observation parameters and the service identifier, so that the application to be observed can feed back the observation data.

[0110] The data transmission module 30 is used to receive the observation data and send the observation data to the host computer so that the host computer can complete the data observation based on the observation data.

[0111] The data observation device based on service-oriented architecture provided in this application, employing the data observation method based on service-oriented architecture in the above embodiments, can solve the technical problem of how to perform real-time data observation. Compared with the prior art, the beneficial effects of the data observation device based on service-oriented architecture provided in this application are the same as those of the data observation method based on service-oriented architecture provided in the above embodiments, and other technical features in the data observation device based on service-oriented architecture are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] This application provides a data observation device based on a service-oriented architecture. The data observation device based on a service-oriented architecture includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the data observation method based on the service-oriented architecture in the above embodiment 1.

[0113] The following is for reference. Figure 5 This document illustrates a structural diagram of a data observation device based on a service-oriented architecture suitable for implementing embodiments of this application. The data observation device based on a service-oriented architecture in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The data observation device based on service-oriented architecture shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0114] like Figure 5As shown, a service-oriented architecture-based data observation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the service-oriented architecture-based data observation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the service-oriented architecture-based data observation device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a service-oriented architecture-based data observation device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0115] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0116] The data observation device based on a service-oriented architecture provided in this application, employing the data observation method based on a service-oriented architecture as described in the above embodiments, can solve the technical problem of how to perform real-time data observation. Compared with the prior art, the beneficial effects of the data observation device based on a service-oriented architecture provided in this application are the same as those of the data observation method based on a service-oriented architecture provided in the above embodiments, and other technical features of this data observation device based on a service-oriented architecture are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0117] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0118] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0119] In addition, to achieve the above objectives, this application also proposes a data observation system based on a service-oriented architecture, the system including the vehicle-mounted system and host computer described above.

[0120] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the data observation system based on a service-oriented architecture, as described in this application. The ECU (Electronic Control Unit) is an electronic control unit, typically used in embedded systems in automobiles to control one or more electrical systems or subsystems of the vehicle. The MCU (Microcontroller Unit) is a microcontroller unit, a single-chip computer integrating a CPU, memory, and I / O interfaces, used to control the basic operations of electronic devices. The SOC (System on Chip) is a system-on-a-chip that integrates all the functions required by a computer or electronic system onto a single chip, typically including a CPU, memory, and I / O interfaces. The host computer usually refers to a computer system used for communication and control with the embedded system or device, typically for data acquisition, analysis, and display. The APP refers to an application program that runs on the SOC, responsible for handling specific tasks or providing specific services. SOME / IP is a scalable service middleware protocol based on the IP protocol, used for communication between different ECUs. The observation module is responsible for receiving observation requests sent by the host computer, parsing the requests, and communicating with the APP to obtain the required observation data. A Socket is used to establish communication connections in a computer network and is responsible for data transmission. S2S (Signal to Service) refers to a signal-to-service module used to transmit data from the SOC side to the MCU side, facilitating observation through tools such as CANoe.

[0121] The host computer establishes a communication connection with the observation module on the SOC via a Socket. The host computer sends an observation request, which includes the data type and parameters to be observed. The observation module receives the observation request from the host computer via a Socket, parses the request content, and extracts the target interface name, observation parameters, and service identifier. The observation module uses the SOME / IP protocol to send the parsed observation request to the APP on the SOC. The APP obtains the observation data according to the request content. The APP feeds back the observation data to the observation module via the SOME / IP protocol, and the observation module sends the received observation data back to the host computer via a Socket. After receiving the observation data, the host computer maps the data to preset observation parameters and displays it on the user interface for analysis and monitoring. When it is necessary to transmit data from the SOC side to the MCU side, the observation module transmits the data through the S2S module, enabling the MCU side to perform observations using tools such as CANoe. This diagram illustrates a data observation system based on a service-oriented architecture. The host computer communicates with the observation module on the SOC via a socket. The observation module interacts with the APP using the SOME / IP protocol to obtain observation data and transmits the data to the MCU side via the S2S module. Finally, the host computer receives and processes the data to complete the data observation. This system improves the real-time performance and accuracy of data observation.

[0122] Since this system adopts all the technical solutions of all the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0123] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data observation method based on a service-oriented architecture in the above embodiments.

[0124] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0125] The aforementioned computer-readable storage medium may be included in a service-oriented architecture-based data observation device; or it may exist independently and not be assembled into a service-oriented architecture-based data observation device.

[0126] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a service-oriented architecture-based data observation device, the service-oriented architecture-based data observation device, after connecting to a host computer, receives and parses an observation request sent by the host computer to obtain a target interface name, observation parameters, and a service identifier; based on the target interface name, the observation parameters, and the service identifier, sends the observation request to the application to be observed through an extensible service middleware protocol, so that the application to be observed can provide feedback on observation data; receives the observation data and sends the observation data to the host computer, so that the host computer can complete the data observation based on the observation data.

[0127] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0128] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0129] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0130] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described data observation method based on a service-oriented architecture, thereby solving the technical problem of how to perform real-time data observation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data observation method based on a service-oriented architecture provided in the above embodiments, and will not be repeated here.

[0131] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data observation method based on a service-oriented architecture as described above.

[0132] The computer program product provided in this application can solve the technical problem of how to perform real-time data observation. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the data observation method based on service-oriented architecture provided in the above embodiments, and will not be repeated here.

[0133] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A data observation method based on a service-oriented architecture, characterized in that, The method is applied to an in-vehicle system, and the method includes: After connecting to the host computer, the system receives and parses the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier. Based on the target interface name, the observation parameters, and the service identifier, the observation request is sent to the application to be observed through the extensible service middleware protocol, so that the application to be observed can provide feedback on the observation data. The system receives the observation data and sends it to the host computer so that the host computer can complete the data observation based on the observation data. The step of sending the observation request to the application to be observed via an extensible service middleware protocol based on the target interface name, the observation parameters, and the service identifier includes: Generate a message identifier based on the target interface name and the service identifier; Generate header information based on the message identifier; Load data is generated based on the observed parameters; An observation request message is created based on the header information and the payload data; Load and initialize the extensible service middleware protocol stack; The observation request message is encapsulated into a data packet using an extensible service middleware protocol; The data packets are sent to the application to be observed through the extensible service middleware protocol stack.

2. The method as described in claim 1, characterized in that, The steps of receiving and parsing the observation request sent by the host computer to obtain the target interface name, observation parameters, and service identifier include: The observation request sent by the host computer is received using a blocking reception method; The checksum is obtained based on the observation request; The integrity and validity of the observation request are verified based on the checksum, and the verification result is obtained; When the verification result is incorrect, a request error message is sent to the host computer so that the host computer resends the observation request; When the verification result is correct, the observation request is parsed to obtain the target interface name, observation parameters, and service identifier.

3. The method as described in claim 1, characterized in that, After the step of sending the observation request to the application to be observed via the extensible service middleware protocol, the method further includes: When the observation request is sent to the application to be observed, the sending time is recorded; Get the current time; When the time difference between the current time and the sending time is greater than the preset maximum time difference, the observation request is resent to the application to be observed.

4. The method as described in claim 1, characterized in that, The steps for connecting to the host computer include: Configure network interface parameters and network stack, and broadcast service information using the service discovery protocol to enable the host computer to provide feedback information. Parse the response information to obtain the IP address and port number of the host computer; Based on the IP address and the port number, a test message is sent to the host computer to enable the host computer to send a response message. The test message includes a first timestamp and a first sequence number. Receive and parse the response message to obtain the second timestamp and the second sequence number; When the first serial number and the second serial number are the same and the time difference between the first timestamp and the second timestamp is less than or equal to a preset time difference value, a connection is established with the host computer through a preset protocol.

5. A data observation method based on a service-oriented architecture, characterized in that, The method is applied to a host computer, and the method includes: After connecting to the vehicle system, an observation request is sent to the vehicle system so that the vehicle system can provide feedback on the observation data. Obtain observation parameters; Receive the observation data, map the observation data onto the observation parameters, and display it on the user interface to complete the data observation; The step of sending an observation request to the vehicle system to enable the vehicle system to feed back observation data includes: Send an observation request to the vehicle system so that the vehicle system can receive and parse the observation request to obtain the target interface name, observation parameters and service identifier; A message identifier is generated based on the target interface name and the service identifier. Generate header information based on the message identifier; Load data is generated based on the observed parameters; An observation request message is created based on the header information and the payload data; Load and initialize the extensible service middleware protocol stack; The observation request message is encapsulated into a data packet using an extensible service middleware protocol; The data packets are sent to the application to be observed through the extensible service middleware protocol stack, so that the application to be observed can provide feedback on the observation data.

6. The method as described in claim 5, characterized in that, The step of mapping the observation data to the observation parameters includes: Load a preset mapping table, which includes the field names of the observation data and the corresponding observation parameter names; The observation data is parsed into key-value pairs to obtain the target observation data; According to the preset mapping table, the field names of the target observation data and the observation parameter names of the observation parameters are matched to complete the mapping.

7. A data observation device based on a service-oriented architecture, characterized in that, The service-oriented architecture-based data observation device is applied to an in-vehicle system, and the device includes: The request receiving module is used to receive and parse the observation request sent by the host computer after connecting to the host computer, and obtain the target interface name, observation parameters and service identifier number; The data acquisition module is used to send the observation request to the application to be observed through the extensible service middleware protocol according to the target interface name, the observation parameters and the service identifier, so that the application to be observed can feed back the observation data. The data transmission module is used to receive the observation data and send the observation data to the host computer so that the host computer can complete the data observation based on the observation data; The step of sending the observation request to the application to be observed via an extensible service middleware protocol based on the target interface name, the observation parameters, and the service identifier includes: Generate a message identifier based on the target interface name and the service identifier; Generate header information based on the message identifier; Load data is generated based on the observed parameters; An observation request message is created based on the header information and the payload data; Load and initialize the extensible service middleware protocol stack; The observation request message is encapsulated into a data packet using an extensible service middleware protocol; The data packets are sent to the application to be observed through the extensible service middleware protocol stack.

8. A data observation device based on a service-oriented architecture, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program on the vehicle system is configured to implement the steps of the data observation method based on a service-oriented architecture as described in any one of claims 1 to 4, and the computer program on the host computer is configured to implement the steps of the data observation method based on a service-oriented architecture as described in any one of claims 5 to 6.

9. A data observation system based on a service-oriented architecture, characterized in that, The system includes the vehicle-mounted system as described in any one of claims 1 to 4 and the host computer as described in any one of claims 6 to 7.

Images