Emerson Exchange 365

• Not Answered

Non-secure parameter update rate

I have a SIS module in a CSLS and a PAS module in a controller which is the not the safety controller for the SIS network. The SIS module has a non-secure parameter reference to the PAS module. The PAS module has an external reference to a SIS parameter. The PAS module is executing at 500 ms, the SIS a lot faster. What is the maximum delay in propagating a change between PAS and SIS and SIS and PAS? If I put the PAS module in the safety controller (which I believe I can't at the moment as it is class-based) would this reduce the times?

Cedric Dawnhawk

• 6 Nov 2020 1:04 PM
• Cancel

6 Replies

• Tadeu Batista

  

  • 22 Jan 2021 5:20 PM

  Hello Cedric,
  
  Can you elaborate a little bit more on the application, architecture and what's the propagation time are you looking for?
  
  Rgs,

  • Cancel
• Cedric Dawnhawk

  

  • 25 Jan 2021 5:02 PM

  In reply to Tadeu Batista:

  I'm not sure I can tell you any more about the architecture other than the SIS controller is an SZ, the PAS controller an SX, DeltaV is version 13.3.
  
  The application is basically that the operator presses a button in the field which generates a 2s timed pulse in the PAS module. The SIS module reads the pulse signal via a non-secure parameter reference and, if other conditions are appropriate, changes an internal permit signal to true. This permit signal is monitored by PAS using an external reference. If the PAS module sees the permit signal before the 2s timed pulse expires, an action is performed by the PAS module.
  
  Originally I had set the pulse length at 2s which I assumed would be more than adequate. However when tried on site, the permit signal from the SIS was only occasionally reaching the PAS module before the 2s expired. I therefore increased it to 5s and it seems to work consistently. However even after allowing for the scan time of the PAS module it seems that the PAS to SIS and back communication must be taking at least 1.5s which seemed a lot to me. This is why I raised the query, really to see if anyone could enlighten me as to where the delay might be.

  • Cancel
• Andre Dicaire

  

  • 25 Jan 2021 6:09 PM

  In reply to Cedric Dawnhawk:

  Cedric, You indicate the PAS module is in a "PAS" controller and not the SZ controller. Is this correct? If the PAS IO is CHARMS, you could place this module directly in the SZ controller, and assign this one CHARM to the SZ, which would reduce some latency.
  
  When you create a non-secure parameter in the Logic Solver, it can be to any module in the PAS to read a value. The SZ controller will setup a Proxy server to read the value from the remote controller. The update rate for this connection is determined by slower of the Proxy Client update request rate and the Host module scan time. The fastest Peer to Peer update rate that can be requested in 500 ms, but that would require two modules to be set to 500 ms or faster. The proxy client requested update rate is likely 1 second. The Logic solver will read the value from the SZ Proxy Client. So the DI signal must first be read by the module (every 500 ms), and is checked by the Proxy Server every second for a change, which sends it to the Proxy Client, and the CSLS retrieves this none secure parameter every second, at which point the SIS module executes and reads the value within 50 ms. At this point, the SIS parameter is updated and is communicated to the SZ controller for retransmission back to the PAS Module that is monitoring this parameter. Again, there are latencies in each step. The return path is a read initiated by the 500 ms module, which sets up another Proxy Client to receive the data from the SZ, which will send according to its update rate, which again could be 1 second
  
  If the PAS module was running in the SZ controller, we would eliminate the SZ to PAS controller proxy clients.
  
  Full disclosure: I'm not sure if the SZ proxy client and Server will set the communication rate to 1 second or if it is faster. It will not be the rate of the SIS module. The CSLS can be set up to report IO signals to the SZ at a faster speed, but SIS Module parameters are at a set rate which I think is 1 second. The HMI will request data every second, which means the SZ will serve the data no faster. Your module requests data every 500 ms. That is the fastest the SZ would serve it, provided there is a new value to send. If the CSLS sends updates every second, the SZ will only send changed data.
  
  Latching the DI in the PAS module until the readback confirms receipt, or times out, would be one way to avoid drops while maintaining the minimum time that adjusts for any "jitter" in the signal. Since all these steps are asynchronous, you have to assume a worst case alignment that results in maximum round trip. That could easily exceed 2 to 3 seconds, or could be within 1 second, if the stars align.

  Andre Dicaire

  • Cancel
• Tadeu Batista

  

  • 25 Jan 2021 6:21 PM

  In reply to Andre Dicaire:

  Hi Cedric,
  
  The reason I asked about the application, is to assess whether it's a time critical application or not.
  
  Based on some tests we've done, the 1.5-2s you mentioned for the whole loop, meaning the Non-Secure parameter reference going from PAS to SIS and back, seem correct, and the reason for that is it depends on a number of factors, I guess Andre has already pointed out a number of it (Thank you Andre)
  
  My suggestion would be wiring the push button to the SIS, and then the SIS, if the conditions are met, will send the Non-Secure reference to the SX Controller, that would definitely reduce the comms time, since we're talking about sending the info one direction only.
  
  Hope that helps.

  • Cancel
• Andre Dicaire

  

  • 25 Jan 2021 11:19 PM

  In reply to Tadeu Batista:

  I would agree with Tadeu that wiring to the CSLS will eliminate one leg of the round trip.  

  I set up a simulation with a module in an SX and CSLS.  

  

  I set the value Param2, which is read by the SIS module as a non-secure read. This is wired to an Output parameter in the SIS Module which is ready by Param3.  The RET Timer measures how long it takes for this module to confirm the round trip.

  At 1 second execution of this module, the timer say values between 3 and 6 seconds.  mostly around 4 seconds.  

  At 500ms the time was still around 4 seconds.  This was a limited number of tries, but it is consistent with one second unsolicited updates between both controllers.  

  Moving this module to the SZ controller, assuming the DI is a CHARM input, the response time dropped to between two to 2.5 seconds.  

  All this pretty much supports the expected impact of the unsolicited communications and SZ to CSLS data exchange. 

  Andre Dicaire

  • Cancel
• Cedric Dawnhawk

  

  • 26 Jan 2021 12:44 PM

  In reply to Andre Dicaire:

  Thanks both for your very useful information which confirms and explains the delays I am experiencing.
  
  The original setting of 2 s for the delay was based on my very naive idea that the PAS module was running at 500 ms and the CSLS was far quicker so 2 s would allow for any other delays. The initial experience was that this very occasionally worked "when the stars aligned" as Andre described it. After adjusting the delay to 5 s it seemed to work consistently and I have not had any reports from site to the contrary. This ties in with Andre's experiments that with 500 ms PAS scan, the delay would be around 4 s.
  
  The I/O is CHARMs and so, in principle, I do have the option of moving the PAS module to execute in the SIS controller. However there are a lot more inputs and outputs from the module and it is class-based so this would not be so straightforward. As it happens the delay is not at all critical to the function, which is basically initiating an override, so I am happy to live with it. However armed with far more knowledge, I should be able to make sure that in the future that things are arranged in a more appropriate way, particularly if the time delay is critical.
  
  Thanks again
  Andrew Chadwick

  • Cancel