Sir,
1. Is it possible to change the GI_period which is default= 330 seconds to any other value in Qtester? How should one decide the GI interval time period?
2. i have come across a few implementations of IEC 104 where the master sends GI commands every second. The Second interrogation Activation is being sent by the master even while the slave is still sending I frames in response to a previous GI command. Is it really required to have such a fast GI interval when background scan and spontaneous transmission are active.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Nitish!
1. Yes, it is possible to configure the time period for interrogations in the qtester104.ini file.
[RTU1]
...
; period in seconds for general interrogations (default=330)
GI_PERIOD=660
...
The time should never be less (nor aproximate) than the time it takes for the slave to send all the data points for the interrogation. So, if the interrogation takes 10s to complete you should program a time superior to 20s. This way you can leave some time for the slave to send exception data. In systems that operate adequately by exception it is ok to program the general interrogation period as 30min or even more.
This is only required when the remote system can not report all the points by exception. In this case it can be really necessary to poll the data by interrogation in short periods like 10s or less. But it should not be too short or it will overwhelm the remote system and it will reduce the bandwith available to report exceptions.
Regards!
Ricardo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sir,
Thanks a lot!
Your advice was extremely helpful.
I can now simulate a fast GI interval using qtester on a low signal strength GSM/wifi network and check for link failures. Will provide an update when done.
Regards
Nitish
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes Nitish, your feedback is very important to me, please keep me updated with your results.
DNP3 is also great for low bandwidth applications. It allows for interrogations by class, range of addresses, etc. I have also a DNP3 driver implemented as part of the OSHMI project.
My Best
Ricardo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sir,
I have used qtester and another master to test an RTU with GI interval 1 second. It works fine. Then i tried to simulate multiple disconnections by setting a router disconnect of 10 mins. after running this setup for sometime (around 17 hrs), RTU stopped responding to any I format ASDUs and only responds to U format and sends confirmation S format ASDUs.
Any I format ASDU gets ignored by the RTU till the RTU is reinitialized locally and the end of initialization command is sent by the salve. RTU log file is attached.
**In this regard, how does the Master check for the remote Link status in IEC 104 (as in IEC 101 master continuosly checks for remote link status and sends a remote link reset )?
Is the reset process command of IEC 104 the same as remote link reset in IEC 101 and how to send this command be in qtester104?
Regards,
Nitish
Hello Nitish!
I think that the RTU is not able to handle so many interrogations (1 per second is way too much).
The link in I104 is somewhat abstracted as it is taken care by the TCP/IP stack.
The reset process in I104 is an application level function and the reset link of I101 is link level, so they are different beasts. With the reset process command there is the option of general reset or just reset of events queue. There is also Test Command C_TS_TA_1 in I104 and it is also from application level.
QTester104 does not have Test Command and Reset Process implemented. I'll write down this to implement them in the next version.
I think this I104 client has the link reset function you need, you should try it out: https://sourceforge.net/projects/iec-104-client-simulator/
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sir,
1. Is it possible to change the GI_period which is default= 330 seconds to any other value in Qtester? How should one decide the GI interval time period?
2. i have come across a few implementations of IEC 104 where the master sends GI commands every second. The Second interrogation Activation is being sent by the master even while the slave is still sending I frames in response to a previous GI command. Is it really required to have such a fast GI interval when background scan and spontaneous transmission are active.
Hi Nitish!
1. Yes, it is possible to configure the time period for interrogations in the qtester104.ini file.
[RTU1]
...
; period in seconds for general interrogations (default=330)
GI_PERIOD=660
...
The time should never be less (nor aproximate) than the time it takes for the slave to send all the data points for the interrogation. So, if the interrogation takes 10s to complete you should program a time superior to 20s. This way you can leave some time for the slave to send exception data. In systems that operate adequately by exception it is ok to program the general interrogation period as 30min or even more.
Regards!
Ricardo
Sir,
Thanks a lot!
Your advice was extremely helpful.
I can now simulate a fast GI interval using qtester on a low signal strength GSM/wifi network and check for link failures. Will provide an update when done.
Regards
Nitish
Yes Nitish, your feedback is very important to me, please keep me updated with your results.
DNP3 is also great for low bandwidth applications. It allows for interrogations by class, range of addresses, etc. I have also a DNP3 driver implemented as part of the OSHMI project.
My Best
Ricardo
Sir,
I have used qtester and another master to test an RTU with GI interval 1 second. It works fine. Then i tried to simulate multiple disconnections by setting a router disconnect of 10 mins. after running this setup for sometime (around 17 hrs), RTU stopped responding to any I format ASDUs and only responds to U format and sends confirmation S format ASDUs.
Any I format ASDU gets ignored by the RTU till the RTU is reinitialized locally and the end of initialization command is sent by the salve. RTU log file is attached.
**In this regard, how does the Master check for the remote Link status in IEC 104 (as in IEC 101 master continuosly checks for remote link status and sends a remote link reset )?
Is the reset process command of IEC 104 the same as remote link reset in IEC 101 and how to send this command be in qtester104?
Regards,
Nitish
Hello Nitish!
I think that the RTU is not able to handle so many interrogations (1 per second is way too much).
The link in I104 is somewhat abstracted as it is taken care by the TCP/IP stack.
The reset process in I104 is an application level function and the reset link of I101 is link level, so they are different beasts. With the reset process command there is the option of general reset or just reset of events queue. There is also Test Command C_TS_TA_1 in I104 and it is also from application level.
QTester104 does not have Test Command and Reset Process implemented. I'll write down this to implement them in the next version.
I think this I104 client has the link reset function you need, you should try it out:
https://sourceforge.net/projects/iec-104-client-simulator/
Regards
Sir,
Yes this simulator has both the reset process and test commands. Thanks once again for your valuable guidance.
Regards,
Nitish