• Not Answered

Using shared modules across Controllers: if one controller is down, the linked controller will be also down

Hi All,

we encountered an issue on our plant. We are using shared modules (EMs, CMs) across controllers. During a safety test it turned out that if one of our controller is down, all the linked controllers will be down. This means that the whole planet will be down just because of one controller.

There are a lot of inter-controller communications, but we said maybe it is too drastic that from Fretim 80 it goes to 0 just because of some shared modules. We did some further tests and it turned out that 8 shared CMs are enough to create a jump from Fretim 80 to 0 on an SX controller. Is this usual?

As a further test we deleted these 8 shared CMs and we solved the links via External references. Like this there was an only 3% decrease in the Fretim. (not 80% as in the previuos case)

It is usual that shared modules have such an impact on a Controller if the linked Controller is down?

Do you see any other solution than the introduction of redundant Controllers?

We are currently setting up a test system where we do all the connections via External References instead of Shared Modules. I let you know the outcome but I would be very interested in your opinion.

Many Thanks! 

4 Replies

  • It’s not shared modules causing the issues, rather the quantity of unresolved references (following the downed controller) that would cause your fretim issues you are seeing.
     
    Andre Dicaire has on many occasion explained the intricacies of how to handle inter controller referencing, perhaps he can enlighten us all again! A snippet below:

    You should definitely use the status of the parameter and not the "health" of the controller. You should read the parameter value with an external reference, which will also have the .CST (Connection Status) as described by Matt.  I believe the .ST will go BAD if the CST goes bad when using an external reference to read the value.”

    System design should take into consideration inter controller communications and act accordingly.  It seems you will need to build in some exception handling in terms of parameters referenced from external sources.

     
     
    From: Adam Bagosi [mailto:bounce-Bago@community.emerson.com]
    Sent: Tuesday, July 15, 2014 1:35 PM
    To: DeltaV@community.emerson.com
    Subject: [EE365 DeltaV Track] Using shared modules across Controllers: if one controller is down, the linked controller will be also down
     

    Hi All,

    we encountered an issue on our plant. We are using shared modules (EMs, CMs) across controllers. During a safety test it turned out that if one of our controller is down, all the linked controllers will be down. This means that the whole planet will be down just because of one controller.

    There are a lot of inter-controller communications, but we said maybe it is too drastic that from Fretim 80 it goes to 0 just because of some shared modules. We did some further tests and it turned out that 8 shared CMs are enough to create a jump from Fretim 80 to 0 on an SX controller. Is this usual?

    As a further test we deleted these 8 shared CMs and we solved the links via External references. Like this there was an only 3% decrease in the Fretim. (not 80% as in the previuos case)

    It is usual that shared modules have such an impact on a Controller if the linked Controller is down?

    Do you see any other solution than the introduction of redundant Controllers?

    We are currently setting up a test system where we do all the connections via External References instead of Shared Modules. I let you know the outcome but I would be very interested in your opinion.

    Many Thanks! 

  • In reply to AdrianOffield:

    Hi Adrian,

    Thanks for the fast response. You are right, of course the unresolved references are causing the issue, I just wanted to emphasize that even a very small quantity of inter-controller communication is causing serious issues if there is a controller loss (in our case 8 CMs). Another interesting thing is that the shared modules need more communication resource than external references, but maybe the problem is that by using shared modules the internal references are becoming unresolved references and not the external references are unresolved references...

    As of course we cannot put 30 EMs on the same controller, and these EMs have to communicate with each other, there must be a solution to avoid multiple controller loss just because 1 controller is down. My feeling is that by changing the internal references to external references will not solve the issue, only the controllers will have a better MPctOnTime (close to 100 but not 100).

  • In reply to Adam Bagosi:

    Adam,

    Keep in mind that an external reference is only one parameter to communicate while a shared module block I think is communicating ALL of the parameters from the module level (Not just the Input and Output nubs) of the module linked to the shared module block.

    If you are only needing the PV of an AI module, it will be better to just use an external reference so you are only communicating the required information.

    I wish the EM had it's own alias resolution table like a Unit module that would prevent this and would only communicate what was required. You can use the aliases of a Unit Module but this requires an Advanced Unit Management License to do this.

    Regards,

    Matt

  • In reply to Matt Stoner:

    Matt,

    Thank you for your response. I have the feeling that you are right, even if there was a thread on the community (if I remember right) where it was discussed that even if it is a shared module, NOT ALL the parameters are communicating across the modules, only the affected ones...