P139 - IEC61850 CILO Logical Node

[ManuelTrebilcock]

Hello everyone,

I want to use the CILO logical nodes to map the interlock status of the devices configured on a P139 FW671 but it's not working. I am using a customized Bay and IED scout to simulate the client. I also tried to use the BlkOpn and BlkCls data objects from the logical node of the respective device but, it didn't work either. I don´t know if there is any trick to make it work. I am using the interlocks of each device located on the control directory as you can see in the attachment.  

I'd really appreciate your help since we are on FAT tests and the client is requiring to send the status of the interlocks using this logical nodes.

Best regards,

Manuel

[AndreMelo · Accepted solution]

Hi @ManuelTrebilcock 

There are few things to check, according to the manual, in the new firmware versions the ILOCK had suffered some changes, it was before always enable, now it was added the 250 102 parameters to enable it or not. In addition to that, the ILOCK was before checked just when the relay received the command (which was an issue to report it via protocol) now you can configure the cycling check period in the parameter 221 104. 

To summarize it is a combination of parameters on section 3.50 of the manual you can find a Block diagram explaining the whole work principle. (I attached it for you) Please take a look at that cause there are important details.

[ManuelTrebilcock]

Thank you very much Andre. It was a matter of just changing the cycle time interlocking check parameter as you mentioned.

[Michael_H]

Fine to hear that your application is working now. Thank you, Andre.

With reference to parameter 221.104 ILOCK cycle time. In its default setting, the cycle time is blocked, meaning that the interlock equation outputs are refreshed once one of the inputs to the equations changed (event triggered mode). As soon as the cycle time is configured with any value, the calculation mode changes to cyclic, performing with the set operation period.

Please note that XCBR.BlkCls and XCBR.BlkOpn have nothing to do with interlocking. These signals neither reflect nor influence the interlocking status. These signals represent the blocking of XCBR for switchgear technical reasons (gas pressure below the limit, e.g.). These signals can also be forced by the operator to deliberately block a switchgear from being operated. On the other hand, the operation capability ("spring charged", e.g.) is not mapped to these signals, since a temporary reduced operation capability while the drive is being recharged to full capacity is not a reason for blocking; this occurs operationally.

[ManuelTrebilcock]

Hi @Michael_H ,

Just for curiosity, how can you force the XCBR.BlkCls and XCBR.BlkOpn signals? 

Best regards,

Manuel Trebilcock

[Michael_H]

Hi Manuel,

From the standard, 'BlkCls' and 'BlkOpn' are controllable objects. So, an operator can send commands to set / reset them as wanted. A configuration parameter 'ctlModel' i.e. "control model", defines how to access them using IEC 61850-7-2 services. You would typically use a "direct-with-normal-security" control service.

In MiCOM P30 these signals are also implemented as controllable objects (as defined in the standard), but the s/c control model for each of them, is set to "status-only", meaning that control is not supported by the device firmware. For the time being, 'BlkCls' and 'BlkOpn' are  status signals only.

Best regards,

Michael