Network Message Delay Control via Runtime Threshold Monitoring
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for controlling message delays in networks, especially those used for safety-critical applications, are inefficient and burdensome, requiring complex time synchronization and significant network resources, which can lead to fatal consequences if not implemented correctly.
Innovation Solution
A method where participants measure the transit time of messages within defined intervals and compare it to a threshold value, generating an error signal if it exceeds, allowing for efficient delay control without the need for exact time synchronization or timestamps, thereby optimizing network capacity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If time synchronization with timestamps is implemented, then message delay control precision is improved, but device complexity and network resource consumption increase
Solution Approach 1:
The patent extracts the essential function of delay measurement from complex time synchronization protocols. Instead of implementing full IEEE 1588 time synchronization with timestamps, the invention extracts only the necessary runtime measurement capability by having the message recipient measure the time interval between receiving a message and sending a corresponding response, thereby obtaining the message runtime without requiring synchronized clocks or timestamp mechanisms across all network participants.
Solution Approach 2:
The patent uses simple, lightweight response messages instead of complex timestamped synchronization messages. These response messages serve a single purpose (measuring runtime) and are discarded after use, avoiding the overhead of maintaining synchronized time across the network. The measurement mechanism is simple and disposable rather than requiring persistent time synchronization infrastructure.
2Reliability
If confirmation messages with time expectations are used, then message delay monitoring is improved, but network capacity consumption increases
Solution Approach 1:
The patent merges the runtime measurement function with the existing confirmation message mechanism. Instead of sending separate synchronization messages and confirmation messages, the invention combines these functions into a single response message that serves both as acknowledgment of receipt and as a carrier for runtime measurement data. This integration reduces the total number of messages required while maintaining both reliability and measurement capability.
3Measurement precision
If clocks are synchronized across all participants, then timestamp accuracy is improved, but ease of operation deteriorates due to continuous synchronization requirements
Solution Approach 1:
The patent implements a self-service measurement approach where each message recipient independently measures the runtime of received messages by recording the time of receipt and the time of sending a response. This eliminates the need for centralized time synchronization or coordinated clock adjustment across network participants. Each node performs its own measurement locally without requiring knowledge of other nodes' clock states or participation in synchronization protocols.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
In a network (29) comprising a plurality of subscribers having at least one message transmitter (50) and at least one message receiver (52), the at least one message transmitter (50) sends a plurality of messages (54). The message receiver (52) receives the plurality of messages (54). The run time (59) of the messages is monitored by means of time expectations (58). According to one aspect of the invention, at least one of the subscribers (52) repeatedly estimates the current run time of the messages (54) within defined first time intervals (70, 70') while the network is running. The estimated run time (64) is compared to a defined threshold value (66). If the estimated run time (64) exceeds the defined threshold value (66), an error signal (68) is generated.