The IEC61850 Standard defines service 'Abort' mapping to MMS.Abort, but the MMS does not have own Abort, the Abort there is defined by lower protocols. There are MANY documents, in different standards, to be considered for the Abort. It results in unclear interpretations, different Aborts by different manufactures. Newly the UCAIug provided 'Aborting_MMS_Association_rev2.docx' (06-April-2015) - with clear recommendation how the Abort service shall be implemented.
The iec850 driver (client) by Abort only closes the TCP socket - sends TCP.FIN. It is fast and simple but some devices (850-Servers) expect ACSE.Abort to fast recognise disconnect.
The IEC61850 Client should follow this final recommendation from UCAIug and use ACSE.Abort (and timer) by aborting connection.
The IEC61850 Standard defines service 'Abort' mapping to MMS.Abort, but the MMS does not have own Abort, the Abort there is defined by lower protocols. There are MANY documents, in different standards, to be considered for the Abort. It results in unclear interpretations, different Aborts by different manufactures. Newly the UCAIug provided 'Aborting_MMS_Association_rev2.docx' (06-April-2015) - with clear recommendation how the Abort service shall be implemented.
The iec850 driver (client) by Abort only closes the TCP socket - sends TCP.FIN. It is fast and simple but some devices (850-Servers) expect ACSE.Abort to fast recognise disconnect.
The IEC61850 Client should follow this final recommendation from UCAIug and use ACSE.Abort (and timer) by aborting connection.
Abort service now: the client's stack first sends the ACSE.Abort frame and waits on device (850-server) reaction and then closes TCP socket (TCP.FIN).
The stack closes socket when receives from the device: the Abort-accept frame or TCP.FIN
or when the device replays some wrong frame
or when (new) internal abort-timeout (1s) is elapsed.
The iec850 driver (client) uses 'Abort' service when a user exits Runtime or stops the driver (using driver command function).
The newest recommendation of UCAIug demands that driver waits on 850-Server reaction. It may result in delay by project reload (or exit). A measurable delay may occur in projects where there are many connections defined per one iec850 driver instance (more as one 850-Servers configured in one iec850 driver). A significant delay (few seconds) may occur when some devices are not reacting on ACSE.Abort - so with 850-Servers not conform to the Standard.
Recommendation: use for each connection with an 850-Server separated instance of iec850 driver - create in zenon project as many iec850 drivers as there are 850-Servers in your system.