Some / ip network service state monitoring system and method

Abstract

This invention relates to the field of SOME / IP communication, and proposes a SOME / IP network service status monitoring system and method. The system includes a server-side statistical collection and reporting subsystem and a monitoring tool-side data collection and analysis subsystem. The collection module of the server-side statistical collection and reporting subsystem is used to create an asynchronous message channel for each node. For each service instance, status data is collected in an asynchronous event loop coroutine, the status data is encapsulated into statistical snapshot records, and sent to the central statistical processor through the asynchronous message channel. The reporting module is used to allocate a central statistical processor for each node, receive probe data packets, and send statistical snapshot records to the source address of the probe data packets. The probe module of the monitoring tool-side data collection and analysis subsystem is used to send probe data packets. The query module is used to write the received statistical snapshot records into a local database and query the service status of each service instance.

Description

Technical Field

[0001] This invention relates to the field of SOME / IP communication, and more particularly to a SOME / IP network service status monitoring system and method. Background Technology

[0002] SOME / IP (Scalable Service-Oriented Middleware over IP) is a service-oriented automotive Ethernet communication middleware protocol widely used in intelligent vehicle electronic and electrical architectures. In a SOME / IP network, multiple electronic control units (ECUs) are interconnected via Ethernet, with numerous server and client instances running on each node. A service discovery mechanism enables dynamic registration, discovery, and subscription of services.

[0003] In existing technologies, monitoring of SOME / IP network status is often technically intrusive. At the execution logic level, existing monitoring methods typically embed synchronous log code into the middleware's core send / receive logic. This design forces business processes to wait for log I / O operations to complete when handling critical communication tasks, which interferes with the timing determinism of the vehicle control logic and may even lead to security risks such as task timeouts. At the communication resource level, existing monitoring usually adopts a full-volume real-time push mode. In vehicle multi-service concurrent scenarios, monitoring traffic shares physical links with normal business traffic, which can lead to overload of the vehicle backbone network bandwidth. Summary of the Invention

[0004] The technical problem to be solved by this invention is to address the shortcomings of the prior art by proposing a SOME / IP network service status monitoring system and method, thereby resolving the problem that existing SOME / IP network status monitoring interferes with normal communication services.

[0005] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows:

[0006] Firstly, a SOME / IP network service status monitoring system is proposed, including a server-side statistical collection and reporting subsystem and a monitoring tool-side data collection and analysis subsystem.

[0007] The server-side statistics collection and reporting subsystem includes a collection module and a reporting module. The collection module creates an asynchronous message channel for each node in the SOME / IP network. For each service instance in a node, status data is collected in an asynchronous event loop coroutine, and the status data is encapsulated into statistical snapshot records and sent to the central statistics processor through the asynchronous message channel. Service instances include client instances and server instances. Status data includes service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, business message count, event group information, and timestamp. The reporting module allocates a central statistics processor to each node. Each central statistics processor receives probe data packets and sends the statistical snapshot records of each service instance to the source address of the probe data packets.

[0008] The monitoring tool's data acquisition and analysis subsystem includes a probe module and a query module. The probe module is used to send probe data packets to all central statistical processors in the SOME / IP network. The query module is used to write the statistical snapshot records replied by the central statistical processors into the local database and to query the local database to obtain the service status of each service instance.

[0009] In one implementation, the collection module of the server-side statistics collection and reporting subsystem is used to periodically collect status data for each service instance in the node.

[0010] In one implementation, the collection module of the server-side statistics collection and reporting subsystem is used to collect, in addition to status data, business message counts, service discovery status identifiers, and stop signals for each service instance in the node within an asynchronous event loop coroutine. For business message counts, when a service instance receives or sends a SOME / IP message during business communication, it extracts the identifier from the message header and modifies the message count for that identifier in the send / receive count table. The send / receive count table uses a hash mapping structure, with the identifier as the key and the message count as the value. For service discovery status identifiers, when the service discovery mechanism triggers a status change, the service discovery status identifier is updated. For stop signals, when a service instance receives a stop command, it exits the asynchronous event loop and terminates data collection.

[0011] After being updated, the business message count and service discovery status identifier are stored in the timed status data of the next cycle.

[0012] In one implementation, the collection module of the server-side statistics collection and reporting subsystem is used to set a buffer capacity limit for the asynchronous message channel. When the amount of data in the statistical snapshot records exceeds the buffer capacity limit, the earliest statistical snapshot record is removed.

[0013] In one implementation, the reporting module of the server-side statistical collection and reporting subsystem is used to append the received statistical snapshot records to the end of the rolling buffer while the central statistical processor is processing probe data packets; the rolling buffer is a double-ended queue structure and has a maximum number limit; when the amount of received statistical snapshot record data exceeds the maximum number limit, the earliest statistical snapshot record is removed.

[0014] In one implementation, the detection module of the monitoring tool's data acquisition and analysis subsystem is used to periodically send detection data packets to all central statistical processors in the SOME / IP network.

[0015] In one implementation, the query module of the monitoring tool's data acquisition and analysis subsystem is used to write the statistical snapshot records replied by the central statistical processor into a local database; the local database adopts an embedded relational database, which includes a service statistics master table, a message statistics sub-table, and an event group sub-table.

[0016] Each record in the service statistics master table represents a snapshot of the status statistics of a service instance at a certain moment. It includes an auto-incrementing primary key, service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, and timestamp. The service identification information includes the service identifier number and the instance identifier number, and the network endpoint information includes the IP address, port number, and transport protocol type.

[0017] Each record in the message statistics sub-table represents a message sending and receiving statistic in a status statistics snapshot. The fields include an auto-incrementing primary key, the associated main table record identifier, the sending / receiving statistics type, the method identifier, and the business message count. A one-to-many relationship is established between the service statistics main table and the associated service statistics main table record identifier.

[0018] Each record in the event group sub-table represents an event group association in a status statistics snapshot. The fields include an auto-incrementing primary key, the associated master table record identifier, and the event group identifier. A one-to-many relationship is established between the associated service statistics master table record identifier and the service statistics master table.

[0019] In one implementation, the query module of the monitoring tool's data acquisition and analysis subsystem is used to: specify an IP address, group service instances according to the service identifier information and service type identifier query strategy, and load associated message sending and receiving statistics and event group information to obtain the latest status of all service instances on that IP address; specify a service identifier number, group service instances according to the IP address and service type identifier query strategy, and load associated message sending and receiving statistics and event group information to obtain the latest status of the same service on different nodes; and specify an application, group service instances according to the service identifier information and service type identifier query strategy, and load associated message sending and receiving statistics and event group information to obtain the latest status of all service instances under that application.

[0020] In one implementation, the query module of the monitoring tool's data acquisition and analysis subsystem is used to maintain a set of configurable network parameters, including local communication address, local communication port, target multicast address, and target multicast port.

[0021] Secondly, a method for monitoring the status of SOME / IP network services is provided, including the following steps:

[0022] An asynchronous message channel is created for each node in the SOME / IP network, and a central statistics processor is assigned to each node. For each service instance in a node, status data is collected in an asynchronous event loop coroutine, and the status data is encapsulated into statistical snapshot records, which are then sent to the central statistics processor via the asynchronous message channel. Service instances include client instances and server instances. Status data includes service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, business message count, event group information, and timestamp. Each central statistics processor is used to receive probe packets and send the statistical snapshot records of each service instance to the source address of the probe packets.

[0023] Send probe packets to all central statistics processors in the SOME / IP network; write the statistical snapshot records replied by the central statistics processors to the local database; query the local database to obtain the service status of each service instance.

[0024] The beneficial effects of this invention are:

[0025] 1. The server-side statistics collection and reporting subsystem embeds the collection module in the asynchronous event loop of the SOME / IP service instance in a non-blocking branch form. The collection process only reads the existing state variables inside the service instance and does not involve any network I / O operations, resulting in short execution time. It uses an independent asynchronous message channel for data transmission, and uses dedicated network endpoints for detection and response, which are isolated from SOME / IP business communication. This does not occupy the network ports and bandwidth resources of business communication and does not affect normal communication performance and operating status.

[0026] 2. A single probe can observe the running status of all SOME / IP service instances running in the current local area network via UDP multicast. This includes observing the running status of all service instances when a single process is running multiple service instances. The status data of all SOME / IP service instances is written to the local database, which significantly reduces the workload of operation and maintenance personnel in manually collecting and correlating log information scattered across various nodes.

[0027] 3. By adopting a periodic data collection and detection mechanism, operations and maintenance personnel can observe the changes in the operating status of each service instance in near real-time during the operation of the SOME / IP network without stopping or restarting the service.

[0028] 4. The monitoring tool's data acquisition and analysis subsystem persistently stores all received statistical data in a structured manner in a relational database, supports backtracking queries by time dimension, and makes post-event analysis of transient failures and intermittent problems possible; it provides command-line query interfaces for at least three dimensions, covering the most common troubleshooting scenarios in SOME / IP network operation and maintenance. Attached Figure Description

[0029] The invention will now be further described with reference to the accompanying drawings.

[0030] Figure 1 This is a framework diagram of the SOME / IP network service status monitoring system according to an embodiment of the present invention.

[0031] Figure 2 This is a flowchart of the data collection module of the server-side statistical data collection and reporting subsystem in an embodiment of the present invention. Detailed Implementation

[0032] like Figure 1-2 As shown, this embodiment of the invention provides a SOME / IP network service status monitoring system, including a server-side statistical collection and reporting subsystem and a monitoring tool-side data collection and analysis subsystem;

[0033] The server-side statistical collection and reporting subsystem includes a collection module and a reporting module. The collection module is used to create an asynchronous message channel for each node in the SOME / IP network.

[0034] Specifically, during the initialization phase of the service factory module in the SOME / IP middleware, a dedicated asynchronous message channel is created;

[0035] In one implementation, the server-side statistics collection and reporting subsystem is used to set a buffer capacity limit for the asynchronous message channel. When the amount of data recorded in the statistical snapshot exceeds the buffer capacity limit, the oldest statistical snapshot record is removed. In this embodiment, the buffer capacity limit for the asynchronous message channel is set to 256 messages to ensure that the normal communication logic of the service instance will not be blocked due to channel overflow in high-concurrency scenarios.

[0036] For each service instance in a node, status data is collected in an asynchronous event loop coroutine, and the status data is encapsulated into statistical snapshot records and sent to the central statistics processor through an asynchronous message channel. Service instances include client instances and server instances. Status data includes service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, business message count, event group information, and timestamp.

[0037] Specifically,

[0038] (a) Service identification information: including Service ID and Instance ID, used to uniquely identify a service instance in the network;

[0039] (b) Network endpoint information: including the IP address, port number and transport layer protocol type (UDP or TCP) to which the service instance is bound, indicating the network communication location of the service instance;

[0040] (c) Application Information: Automatically obtain the name of the currently running process to indicate the application to which this service instance belongs;

[0041] (d) Service type identifier: Marks the instance as either a client or a server to distinguish the role of the service;

[0042] (e) Running status indicator: indicates whether the service instance is currently running;

[0043] (f) Service discovery status identifier: For server instances, it indicates whether the service is offering services to the outside world (offering); for client instances, it indicates whether the client has successfully discovered the target service (discovered). The client's discovery status is determined by whether it has established communication with the server internally - if it has, it is marked as discovered; otherwise, it is marked as undiscovered.

[0044] (g) Business Message Counting: Maintain separate sent message count tables and received message count tables. Each count table uses an identifier (Method ID or Event ID) as the key and the cumulative number of messages as the value. For server instances, the sent count reflects the number of response messages and event notifications sent, and the received count reflects the number of client requests received. For client instances, the sent count reflects the number of requests sent, and the received count reflects the number of responses and event notifications received. Each time a message is sent or received, the counter for the corresponding identifier increments.

[0045] (h) Event Group Information: Records a list of event group identifiers associated with this service instance. For server instances, all defined event groups are extracted from their configuration; for client instances, subscribed event groups are obtained from remote service information.

[0046] (i) Timestamp: Records the collection time of this statistical snapshot, accurate to milliseconds, in the format "year-month-day hour:minute:second.millisecond";

[0047] In one implementation, the collection module of the server-side statistics collection and reporting subsystem is used to periodically collect status data for each service instance in the node. In this embodiment, the collection period is set to 1 second. Each time the timer is triggered, the service instance collects status data and encapsulates it into a statistical snapshot record.

[0048] In one implementation, the collection module of the server-side statistics collection and reporting subsystem is used to collect, in addition to status data, business message counts, service discovery status identifiers, and stop signals for each service instance in the node within an asynchronous event loop coroutine. For business message counts, when a service instance receives or sends a SOME / IP message during business communication, it extracts the identifier from the message header and modifies the message count for that identifier in the send / receive count table. The send / receive count table uses a hash mapping structure, with the identifier as the key and the message count as the value. For the service discovery status identifier, it updates the service discovery status identifier when the service discovery mechanism triggers a status change. For the stop signal, when a service instance receives a stop command, it exits the asynchronous event loop and terminates data collection. After being updated, the business message counts and service discovery status identifiers are stored in the timed status data for the next cycle.

[0049] Specifically, a new branch for timed statistical data collection is added to the coroutine of the asynchronous event loop. Each SOME / IP service instance concurrently listens for four types of events in its asynchronous event loop, three of which are directly related to statistical data collection:

[0050] Branch 1: Business Message Counting. When a service instance receives or sends a SOME / IP message during normal business communication, the system extracts the identifier (Method ID or Event ID) from the message header and increments the cumulative count of that identifier in the corresponding send / receive count table. The count table uses a hash mapping structure, with the identifier as the key and the message count as the value. If an identifier appears for the first time, a new count record is automatically created and initialized to 1. This process is synchronized with the normal business message processing flow, adding only one hash table lookup and integer addition operation, and has a minimal impact on business performance.

[0051] Branch 2: Service Discovery Status Flag. When the service discovery mechanism triggers a state change—for example, a client instance discovers a target server and establishes a communication connection via the SOME / IP Service Discovery Protocol (SD), or the connection is lost due to the server going offline—the system updates its internal discovery status flag. For client instances, this flag reflects whether they have successfully discovered and connected to the target server; for server instances, this flag reflects whether they are providing services. This status flag will be read and included in the statistical snapshot during the next scheduled data collection.

[0052] Branch 3: Scheduled Snapshot Collection. Every second, a timer triggers a complete status collection process. The system sequentially reads the service instance's service identifier, instance identifier, current running status (running or suspended), service discovery status, network endpoint information (IP address, port number, transport protocol type), application process name, current cumulative message send / receive count, and associated event group list, generating a timestamp accurate to milliseconds. All of the above information is encapsulated into a statistical snapshot record and sent to the central statistics processor at the service factory level via an asynchronous message channel. This collection process only reads existing state variables within the service instance and does not involve any network I / O operations, therefore its execution time is extremely short.

[0053] Branch 4: Stop Signal. When a service instance receives a stop command from the upper layer, it exits the asynchronous event loop and terminates statistical data collection.

[0054] The reporting module is used to assign a central statistics processor to each node; each central statistics processor is used to receive probe data packets and send the statistical snapshot records of each service instance to the source address of the probe data packets.

[0055] Specifically, during the initialization of the SOME / IP middleware's service factory, two UDP network endpoints are created in each central statistics processor: one unicast endpoint and one multicast endpoint. The multicast endpoint is added to a preset multicast group (default multicast address is 224.56.78.90, port is 9090) to listen for probe requests from the monitoring tool. It sends statistical snapshot records of each service instance to the source address of the probe packets via the UDP unicast endpoint.

[0056] In one implementation, the reporting module of the server-side statistical collection and reporting subsystem is used to append the received statistical snapshot records to the end of the rolling buffer while the central statistical processor is processing probe data packets; the rolling buffer is a double-ended queue structure and has a maximum number limit; when the amount of received statistical snapshot record data exceeds the maximum number limit, the earliest statistical snapshot record is removed.

[0057] Specifically, the central statistics processor runs as an independent asynchronous task, employing a concurrent selection mode to process two types of branches simultaneously:

[0058] Branch 1: Receive statistical data reported by service instances. When a statistical snapshot record of a service instance is received via an asynchronous message channel, it is appended to the tail of a rolling buffer with a double-ended queue structure. When the number of records in the buffer exceeds a preset limit (60 records in this embodiment), the oldest record is automatically removed from the head of the queue, thereby maintaining the most recent statistical data (approximately 60 seconds) in the buffer and preventing unlimited memory growth.

[0059] Branch Two: Responding to Probe Requests from Monitoring Tools. When a probe packet is received via the multicast endpoint, the source address of the packet is extracted. Then, all accumulated statistical snapshot records in the rolling buffer are serialized into a JSON-formatted byte stream and sent via the unicast endpoint to the source address of the probe request. After sending, the rolling buffer is cleared to prepare for the next round of data accumulation.

[0060] The monitoring tool's data acquisition and analysis subsystem includes a probe module and a query module. The probe module is used to send probe data packets to all central statistical processors in the SOME / IP network. The query module is used to write the statistical snapshot records replied by the central statistical processors into the local database and to query the local database to obtain the service status of each service instance.

[0061] In one implementation, the detection module of the monitoring tool's data acquisition and analysis subsystem is used to periodically send detection data packets to all central statistical processors in the SOME / IP network.

[0062] In one implementation, the query module of the monitoring tool's data acquisition and analysis subsystem is used to maintain a set of configurable network parameters, including local communication address, local communication port, target multicast address, and target multicast port.

[0063] Specifically, after the monitoring tool's data acquisition and analysis subsystem starts, it automatically detects available IPv4 network addresses on the local machine and creates a UDP unicast endpoint for communication. The tool internally maintains a configurable set of network parameters, including: local communication address, local communication port, target multicast address (default 224.56.78.90), and target multicast port (default 9090). Users can dynamically modify these parameters via interactive commands without restarting the tool. When the user executes the start monitoring command, the tool enters periodic probing mode, sending an empty UDP packet as a probe signal to the target multicast address and port every second. Upon receiving this probe signal, all service processes running SOME / IP middleware on the network will reply with their respective statistical buffer data in JSON format via unicast, which the tool receives through the UDP unicast endpoint. The tool concurrently processes probe sending and data reception within the same asynchronous event loop: each received reply packet is parsed into a list of statistical snapshot records, and then all records are written to the local database. When the user executes the stop monitoring command, the tool stops periodic probing, but historical data already in the database can still be queried. When network parameters are modified, the tool automatically rebuilds the communication endpoint to make the new configuration take effect.

[0064] In one implementation, the query module of the monitoring tool's data acquisition and analysis subsystem is used to write the statistical snapshot records replied by the central statistical processor into a local database; the local database adopts an embedded relational database, which includes a service statistics master table, a message statistics sub-table, and an event group sub-table.

[0065] Each record in the service statistics master table represents a snapshot of the status statistics of a service instance at a certain moment. It includes an auto-incrementing primary key, service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, and timestamp. The service identification information includes the service identifier number and the instance identifier number, and the network endpoint information includes the IP address, port number, and transport protocol type.

[0066] Each record in the message statistics sub-table represents a message sending and receiving statistic in a status statistics snapshot. The fields include an auto-incrementing primary key, the identifier of the associated main table record (foreign key), the sending / receiving statistics type, the method identifier, and the business message count. A one-to-many relationship is established between the service statistics main table and the associated service statistics main table record identifier (foreign key).

[0067] Each record in the event group sub-table represents an event group association in a status statistics snapshot. The fields include an auto-incrementing primary key, the identifier of the associated master table record (foreign key), and the event group identifier. A one-to-many relationship is established between the associated service statistics master table record identifier (foreign key) and the service statistics master table.

[0068] Specifically, the embedded relational database serves as the persistent storage backend for statistical data, with the database files stored on the local disk of the tool.

[0069] The table creation statements for the above three data tables are as follows:

[0070] CREATE TABLE IF NOT EXISTS odbg_statistics ( id INTEGER PRIMARY KEY AUTOINCREMENT, service_id INTEGER NOT NULL, instance_id INTEGER NOT NULL, ip TEXT NOT NULL, port INTEGER NOT NULL, protocol TEXT NOT NULL, app TEXT NOT NULL, type TEXT NOT NULL, active BOOLEAN NOT NULL, discovered BOOLEAN NOT NULL, time TEXT NOT NULL ); CREATE TABLE IF NOT EXISTS odbg_statistics_items ( id INTEGER PRIMARY KEY AUTOINCREMENT, statistics_id INTEGER NOT NULL, item_type TEXT NOT NULL, -- 'send' or 'recv' item_id INTEGER NOT NULL, count INTEGER NOT NULL, FOREIGN KEY (statistics_id) REFERENCES odbg_statistics (id) ); CREATE TABLE IF NOT EXISTS odbg_event_groups ( id INTEGER PRIMARY KEY AUTOINCREMENT, statistics_id INTEGER NOT NULL, event_group_id INTEGER NOT NULL, FOREIGN KEY (statistics_id) REFERENCES odbg_statistics (id) );

[0071] The data writing process is as follows: For each received statistical snapshot record, its basic information is first inserted into the service statistics master table, and the automatically generated primary key value is obtained. Then, using this primary key as a foreign key, all sent message counts and received message counts in that snapshot are inserted into the message statistics sub-table, respectively. Finally, all event group identifiers are inserted into the event group sub-table. The corresponding insert statement for this writing process is as follows, where ? represents a placeholder for the parameter, and the same applies below:

[0072] -- Step 1: Insert into the main table and retrieve the auto-incrementing primary key INSERT INTO odbg_statistics (service_id, instance_id, ip, port,protocol, app, type, active, discovered, time) VALUES (?, ?, ?, ?, ?, ?, ?,?, ?, ?) RETURNING id; -- Assuming the returned primary key value is 42 -- Step 2: Insert the message sending count (item_type = 'send') INSERT INTO odbg_statistics_items (statistics_id, item_type, item_id,count) VALUES (42, 'send', ?, ?); -- Step 3: Insert the received message count (item_type = 'recv') INSERT INTO odbg_statistics_items (statistics_id, item_type, item_id,count) VALUES (42, 'recv', ?, ?); -- Step 4: Insert Event Group Association INSERT INTO odbg_event_groups (statistics_id, event_group_id) VALUES(42, ?);

[0073] The advantages of this three-table design are: the main table has fixed fields and each record is of consistent size, which is conducive to efficient indexing; message statistics and event group information are stored separately in a one-to-many manner, which is not affected by changes in the number of methods and event groups, and has good scalability; foreign key constraints ensure the reference integrity of the data.

[0074] In one implementation, the query module of the monitoring tool's data acquisition and analysis subsystem is used to: specify an IP address, group service instances according to the service identifier information and service type identifier query strategy, and load associated message sending and receiving statistics and event group information to obtain the latest status of all service instances on that IP address; specify a service identifier number, group service instances according to the IP address and service type identifier query strategy, and load associated message sending and receiving statistics and event group information to obtain the latest status of the same service on different nodes; and specify an application, group service instances according to the service identifier information and service type identifier query strategy, and load associated message sending and receiving statistics and event group information to obtain the latest status of all service instances under that application.

[0075] Specifically, users are provided with three different ways to query service status, each employing a specific query strategy to return the latest service status snapshot:

[0076] (a) Query by Network Node: After the user specifies an IP address, the system retrieves the latest status of all service instances on that IP address from the database. The query strategy uses grouping by "Service Identifier + Instance Identifier + Service Type" and retrieves the record with the largest (i.e., latest) timestamp from each group, ensuring that only the most recent status snapshot is returned for each service instance. Message statistics and event group information associated with that snapshot are also loaded. Alternatively, users can list all discovered nodes in the network directly without specifying an IP address. The corresponding query statement is as follows:

[0077] -- List all discovered network nodes SELECT DISTINCT ip FROM odbg_statistics ORDER BY ip; -- Query the latest status of all service instances on the specified node SELECT id, service_id, instance_id, ip, port, protocol, app, type, active, discovered, time FROM odbg_statistics WHERE ip = ? GROUP BY service_id, instance_id, type HAVING time = MAX(time); -- Load message statistics and event groups from specified snapshot records SELECT item_id, count FROM odbg_statistics_items WHERE statistics_id = ? AND item_type = 'send'; SELECT item_id, count FROM odbg_statistics_items WHERE statistics_id = ? AND item_type = 'recv'; SELECT event_group_id FROM odbg_event_groups WHERE statistics_id = ?;

[0078] (b) Query by Service Identifier: After the user specifies a service identifier and an instance identifier, the system retrieves the status of all instances in the network that match that service identifier. The query strategy groups by "IP address + service type" and retrieves the latest record, thus displaying the latest status of the same service on different nodes for both the client and server. Users can also list all discovered service types in the network directly without specifying a specific identifier. The corresponding query statement is as follows:

[0079] -- List all discovered service types SELECT DISTINCT service_id, instance_id, type, ip FROM odbg_statistics ORDER BY service_id, instance_id; -- Query the latest status of the specified service on each node SELECT id, service_id, instance_id, ip, port, protocol, app, type, active, discovered, time FROM odbg_statistics WHERE service_id = ? AND instance_id = ? GROUP BY ip, type HAVING time = MAX(time);

[0080] (c) Query by Application: After the user specifies an application name, the system retrieves the latest status of all service instances under that application. The query strategy groups by "Service ID + Instance ID + Service Type" and retrieves the latest record. Users can also list all discovered applications on the network directly without specifying a name. The corresponding query statement is as follows:

[0081] -- List all discovered applications SELECT DISTINCT app FROM odbg_statistics ORDER BY app; -- Query the latest status of all service instances under the specified application SELECT id, service_id, instance_id, ip, port, protocol, app, type, active, discovered, time FROM odbg_statistics WHERE app = ? GROUP BY service_id, instance_id, type HAVING time = MAX(time);

[0082] The core strategy of the above three query methods is to retrieve the latest timestamp by grouping (GROUP BY ... HAVINGtime = MAX(time)). This strategy ensures that even when a large amount of historical data has accumulated in the database, each query always returns the most recent state snapshot of each service instance, balancing real-time performance and the complete preservation of historical data.

[0083] This embodiment also provides a method for monitoring the status of SOME / IP network services, including the following steps:

[0084] An asynchronous message channel is created for each node in the SOME / IP network, and a central statistics processor is assigned to each node. For each service instance in a node, status data is collected in an asynchronous event loop coroutine, and the status data is encapsulated into statistical snapshot records, which are then sent to the central statistics processor via the asynchronous message channel. Service instances include client instances and server instances. Status data includes service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, business message count, event group information, and timestamp. Each central statistics processor is used to receive probe packets and send the statistical snapshot records of each service instance to the source address of the probe packets.

[0085] Send probe packets to all central statistics processors in the SOME / IP network; write the statistical snapshot records replied by the central statistics processors to the local database; query the local database to obtain the service status of each service instance.

Claims

1. A SOME / IP network service state monitoring system, characterized in that This includes a server-side statistical data collection and reporting subsystem and a monitoring tool-side data collection and analysis subsystem. The server-side statistics collection and reporting subsystem includes a collection module and a reporting module. The collection module is used to create an asynchronous message channel for each node in the SOME / IP network. For each service instance in the node, status data is collected in an asynchronous event loop coroutine, and the status data is encapsulated into statistical snapshot records and sent to the central statistics processor through the asynchronous message channel. Service instances include client instances and server instances. Status data includes service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, business message count, event group information, and timestamp. The reporting module is used to assign a central statistics processor to each node; each central statistics processor is used to receive probe data packets and send the statistical snapshot records of each service instance to the source address of the probe data packets. The monitoring tool's data acquisition and analysis subsystem includes a probe module and a query module. The probe module is used to send probe data packets to all central statistical processors in the SOME / IP network. The query module is used to write the statistical snapshot records replied by the central statistical processors into the local database and to query the local database to obtain the service status of each service instance.

2. The SOME / IP network service state monitoring system of claim 1, wherein: The collection module of the server-side statistics collection and reporting subsystem is used to periodically collect status data for each service instance in the node.

3. The SOME / IP network service status monitoring system according to claim 2, characterized in that: The data collection module of the server-side statistics collection and reporting subsystem is used to collect, in addition to status data, business message counts, service discovery status identifiers, and stop signals for each service instance in the node within an asynchronous event loop coroutine. For business message counts, when a service instance receives or sends a SOME / IP message during business communication, it extracts the identifier from the message header and modifies the message count for that identifier in the send / receive count table. The send / receive count table uses a hash mapping structure, with the identifier as the key and the message count as the value. For service discovery status identifiers, when the service discovery mechanism triggers a status change, the service discovery status identifier is updated. For stop signals, when a service instance receives a stop command, it exits the asynchronous event loop and terminates data collection. After being updated, the business message count and service discovery status identifier are stored in the timed status data of the next cycle.

4. The SOME / IP network service status monitoring system according to claim 1, characterized in that: The collection module of the server-side statistics collection and reporting subsystem is used to set the upper limit of the buffer capacity for the asynchronous message channel. When the amount of data in the statistical snapshot records exceeds the upper limit of the buffer capacity, the earliest statistical snapshot record is removed.

5. The SOME / IP network service status monitoring system according to claim 1, characterized in that: The reporting module of the server-side statistical collection and reporting subsystem is used by the central statistical processor to append the received statistical snapshot records to the end of the rolling buffer while processing probe data packets. The rolling buffer has a double-ended queue structure and a maximum number of records is set. When the amount of received statistical snapshot records exceeds the maximum number of records, the oldest statistical snapshot record is removed.

6. The SOME / IP network service status monitoring system according to claim 1, characterized in that: The detection module of the monitoring tool's data acquisition and analysis subsystem is used to periodically send detection data packets to all central statistical processors in the SOME / IP network.

7. The SOME / IP network service status monitoring system according to claim 1, characterized in that: The query module of the monitoring tool's data acquisition and analysis subsystem is used to write the statistical snapshot records replied by the central statistical processor into the local database; the local database adopts an embedded relational database, which includes a service statistics main table, a message statistics sub-table, and an event group sub-table; Each record in the service statistics master table represents a snapshot of the status statistics of a service instance at a certain moment. It includes an auto-incrementing primary key, service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, and timestamp. The service identification information includes the service identifier number and the instance identifier number, and the network endpoint information includes the IP address, port number, and transport protocol type. Each record in the message statistics sub-table represents a message sending and receiving statistic in a status statistics snapshot. The fields include an auto-incrementing primary key, the associated main table record identifier, the sending / receiving statistic type, the method identifier, and the business message count. And establish a one-to-many relationship between the service statistics master table record identifier and the service statistics master table; Each record in the event group sub-table represents an event group association in a status statistics snapshot. The fields include an auto-incrementing primary key, the associated master table record identifier, and the event group identifier. A one-to-many relationship is established between the associated service statistics master table record identifier and the service statistics master table.

8. The SOME / IP network service status monitoring system according to claim 7, characterized in that: The query module of the monitoring tool's data acquisition and analysis subsystem is used to group service instances on that IP address by specifying the IP address and merging them according to the service identification information and service type identification query strategy. It also loads the associated message sending and receiving statistics and event group information to obtain the latest status of all service instances on that IP address. The user specifies the service identifier number, groups the data according to the IP address and service type identifier query strategy, and loads the associated message sending and receiving statistics and event group information to obtain the latest status of the same service on different nodes. The user-specified application is grouped according to the service identifier information and service type identifier query strategy, and the associated message sending and receiving statistics and event group information are loaded to obtain the latest status of all service instances under the application.

9. The SOME / IP network service status monitoring system according to claim 1, characterized in that: The query module of the monitoring tool's data acquisition and analysis subsystem is used to maintain a set of configurable network parameters, including local communication address, local communication port, target multicast address, and target multicast port.

10. A method for monitoring the status of SOME / IP network services, characterized in that, Includes the following steps: An asynchronous message channel is created for each node in the SOME / IP network, and a central statistics processor is assigned to each node. For each service instance in a node, status data is collected in an asynchronous event loop coroutine, and the status data is encapsulated into statistical snapshot records, which are then sent to the central statistics processor via the asynchronous message channel. Service instances include client instances and server instances. Status data includes service identification information, network endpoint information, application information, service type identifier, running status identifier, service discovery status identifier, business message count, event group information, and timestamp. Each central statistics processor is used to receive probe packets and send the statistical snapshot records of each service instance to the source address of the probe packets. Send probe packets to all central statistics processors in the SOME / IP network; write the statistical snapshot records replied by the central statistics processors to the local database; query the local database to obtain the service status of each service instance.

Images