I'm performing some testing of the 61850 MMS protocol with the GE Multilin 845 and 869 devices using the IEDExplorer tool (rev 0.78) from SourceForge. I'm currently focusing on operator writes.

I know that configuration of the different modes is handled via the XCBR1.Pos.CtlModel which selects either direct or select-before-operate modes with either normal or enhanced security. I've been able to successfully write using direct mode with either normal security (1) or enhanced security (3). For those I send a command structure write to XCBR1.Pos.Oper with the desired Value and Originator Category (REMOTE_CONTROL).

I've also been able to successfully write with normal SBO (2). For that, I first send a read request to XCBR1.Pos.SBO followed by the same write from above to XCBR1.Pos.Oper.

I have not had any success of yet writing SBOw with enhanced security (4). It is my understanding that for SBOw, the fully qualified write structure is first sent to XCBR1.Pos.SBOw as a write command. Upon a successful response, the same structure is once again sent, only this time to XCBR1.Pos.Oper. This is certainly how it works with a device from a different vendor.

For either the 845 or 869, the original SBOw attempt is rejected with an object-access-denied response as per Wireshark.

Do the GE Multilin 845 and 869 devices support SBOw? Is there some special configuration required to enable it? Is there something unique about the write message that would prevent it from being accepted, for example the originator category?

Thank you,
Ron

 

Besides the fact you are using the wrong IEC 61850 client there are some things you can check:

1. I am assuming you have changed the control model of the object by writing the value of 4 (SBO with enhanced security) to the ctlModel attribute of the CF functional constraint. If you did, was it actually equal to 4 before you wrote SBOw? If not, that could be the cause. A device is allowed to have a SBOw and SBO object present in its namespace even though the ctlModel is indicating that SBO operations are not allowed. This is common for devices where the ctlModel is configurable. If you did not receive a cmdTerm message when attempting to write the SBOw it is likely that the device is not in ctlModel = 4 mode. If you did receive it, the AddCause information would contain diagnostic information about the error encountered.

2. The originator category and ID could certainly be an issue that would prevent a successful control operation. However, if you used the same originator values (orCat and orIdent) for the normal operates it is unlikely to be the cause for the enchanced security operate although it is possible for a device to be configured that way. orCat is especially important because devices should not allow remote control operations when the switch controller is set to Local. Or it may not allow Bay level controls from that particular client (orIdent). etc.

3. Errors on operate requests can also be caused if the ctlVal used in the SBOw is set to a value that would not cause a change (e.g. trying to open a switch that is already open).

4. When doing enhanced security controls sometimes devices are programmed by default to do synchrocheck operations before accepting control commands. If the device does not have any I/O connected to it that would allow it to determine the switch is in a state that would be valid for the control requested it can cause an error. In that case you would either need to wire something up to the device or disable those checks using the device configuration tool. I have seen this happen for some relays, although I don't know the specific GE relay you are working with well enough to know if it is true in this case.

Ralph Mackiewicz
SISCO, Inc.
https://www.sisconet.com/products/ax-s4-61850/