Intermittent Off Line with 2.0b VTN
In Open ADR 2.0b there are a number of factors which can cause a failure to connect to the VTN. Intermittent failures are not uncommon therefore we must examine the QOS (Quality of Service) to determine if the failures will affect the GRIDlink’s ability to respond to an Event.
This trend screen is a good example of frequent connection failures which do not affect Event participation.
In this example the connection between the GRIDlink and the VTN fails about 50 times in a 12 hour period indicated by the binary values in RED. What is important to note is the BLUE analog values which show the lowest value of 6 at 00:05 and 07:36. This means the GRIDlink was not able to connect to the VTN for about 4 minutes. See definition below.
There is a requirement in the 2.0b specification for End Nodes that have connection failures to increase the “wait period” duration before retries. This serves to reduce the Server load should there be a problem. This also causes failures to appear to be longer than was experienced in 1.0 or 2.0a.
Once an Event is called the payload is stored and executed unless the Event is cancelled or the customer Opts out. Intermittent connection failures will not affect the Event.
GRIDlink Settings
There are setting in GRIDview that could lead to intermittent connections. Check the following:
Log Level
GRIDview Device / Files
Select dras_client.ini file
Check to make sure log_level is not higher than INFO
# ————————— 2.0b Options ————- #
log_level=INFO
Load Averages
GRIDview View / Status
Check load averages which should be < 3.0
Unit Uptime: 10:50pm up 2 days, 10:20, load average: 1.96, 2.00, 1.97
High Data Summary
GRIDview View / Data Summary
Check for tags with high data summary counts
| frequencyPv | 11987 | 24961 | 174430 | 329916 | 329916 |
Solution – Device / Tags
Increase scan delay where practical
Status Updates
GRIDview Device / Settings
Status Updates can be as low as 1 minute for debugging but should be:
Status Updates 10 minutes
Intermittent failures can result from:
- Network issues, particularly wireless communication.
- VTN not responding to requests within time parameters.
QOS (quality of service)
is a 10 minute running average of the number of successful signals received out of the 10 requests. If the all of the last 10 polls were successful, a score of 10 would result. If one poll was unsuccessful then the QOS would be 9 and so on. In 2.0b the GRIDlink would require a QOS value of 0 and remain there for a long period before it would be accurate to say the device is Off Line otherwise a number less than 10 is usually attributed to intermittent network issues
Reboots
are data-logged. Frequent rebooting maybe an indication of insufficient power to the GRIDlink.
GRIDview Off Line Events
monitors the connection between the GRIDlink and the GRIDview cloud server. If there is a low QOS with the VTN at the same time the GRIDlink is Off Line with GRIDview then this is most likely due to a network problem or a power outage.