• Not Answered

Fibre Optic Connection Technology validation for Project

We are in FEED for platform project. Platform located about ~165KM away from Onshore. Onshore facility is commissioned and running with DeltaV.

Platform is Not Normally Man (NNM) Platform and will be operated from existing onshore.

Current setup onshore comprised of three (3) zones as Zone A, B & C.  Platform is an additional facility and will have separate Zone called Zone D.  As Platform is Not Normally Manned Platform so it will be operated/Maintained from existing onshore facility.

For operation point of view we are proposing to extend Interzone (IZN) , L2.5 (PIN), Thin Client and Safety (LSN) Network from Platform to Onshore.

The communication between the two facility will be done by Fibre optic connection (FOC). FOC will be supply by Client and they will use SLTE (Submarine Line Terminal Equipment) technology.

As per Client there will be Single core which will transmit the data of all four network with different wavelength.

We have few question as below and also we want technology to confirm about the FOC technology. 

  1. Will DeltaV support  SLTE technology and the distance between two locations?
  2. Can Safety network be clubbed with the process data network?
  3. How can we calculate bandwidth of each networks and What would be  acceptable latency?
  4. In this project we are proposing virtualization, We are exploring the option of keeping two VRTX at different (one at Platform and other at onshore) location. We believe this would be beneficial for remote Operation and control from onshore facility, Will this beneficial for reducing  network traffic ?

Attached please find proposed NW architecture.Proposed NW Architecture.pdf

4 Replies

  • Interesting... You make project for LUKOIL?
  • You have to separate the physical media of the network from the DeltaV system. DeltaV does not need to support SLTE technology. SLTE technology needs to provide adequate performance and security to be used reliably.

    Consider this. The Ethernet cable that connects two DeltaV switches can be Cat5e, or Cat6 or multimode fiber or Single mode fiber. If that connection breaks, communication will stop. Who supports that cable? Someone will repair it, and restore operation.

    From a DeltaV perspective, the system will detect a loss of communication between nodes that use that failed segment, and may switch to the secondary network recording an ACN switchover, and nodes will report integrity faults as they lose connection on primary network. The point is that DeltaV will detect loss of network connectivity within the communication layer diagnostics.

    In the case of this submarine fiber core, multi wavelength signals allow separate 'channels' to operate simultaneously over the fiber, and within each channel, you are also able to VLAN additional networks to create multiple secure networks for use in different systems. At each end of this fiber will be specialized hardware to convert the multiples channels into separate network ports that you can then connect as needed on each end.

    From a DeltaV perspective, you will have two separate networks for Primary and Secondary communication of the Area Control Network (ACN). If you have a VRTX on the platform, you will also need two networks for the Thin Client network to this VM Cluster. If you extend the Safety Network, you will need an additional two networks for this.

    DeltaV ACN communications tolerate significant latency, though standard product deployment usually involves latency <1ms (as seen with a Ping command). Thin clients with RDP work well with latencies upwards of 20 ms, but again, product is tested in a local 1Gb infrastructure at <1ms. I expect that the proposed SLTE infrastructure will deliver very low latency.

    As for Bandwidth, DeltaV ACN is designed around 100Mb (actually was designed around 10Mb Half Duplex, or about 2Mb of throughput in early days). With full duplex, collisions are all but eliminated and full 100 Mb bandwidth is usable on a network port. If the SLTE connection is 1Gb per channel, you will be able to partition this into several VLANS and use QoS to ensure minimum throughput for your critical connections.

    It looks to me that you could allocate two channels for Primary and Secondary networks, and VLAN these for DeltaV ACN, Thin Client and possibly SIS. You will need to provide the requisite hardware that allows these networks to be individually connected from and to standard DeltaV Smart Switches, and treat the SLTE (VLANNED) connections as simply a network connection between Port A and Port B.

    It is this connection that will require local "support". If this breaks, you lose all the networks it serves. That is an availability discussion. From a DeltaV Perspective, you've created primary and secondary networks so the system availability will be high. That is if a network switch fails or a computer NIC fails, redundant communication is still available. Your risk around the SLTE infrastructure, including the fiber, interfaces, VLANs and firewalls, is something you have to manage to tolerable risk. That is independent of DeltaV.

    Many will say you need to have two separate fibers on divergent paths. that would greatly increase the SLTE availability, and also installation cost. A simplex SLTE infrastructure has a defined risk and probability of failure. The balance of the networks on shore and platform will be redundant and offer their stated availability. The risk on the SLTE is one the project/end user has to be comfortable with.

    One thing to understand is that the DeltaV ACN and the SIS safety networks do not behave the same as typical IT networks. They use TCP and UDP traffic as well as multicasts in what could be described as atypical. You will need expertise on your team to properly set up the VLANS and SLTE channels to achieve the required segregation in these networks for cybersecurity and desired functionality. As long as the technology delivers on performance and reliability, and is properly set up, DeltaV will not even know it exists.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Hi Andre,
    Thank you so much for information. This will help us to understand the technology.
    In project client will provide Single FOC through SLTE so there will not be any redundancy in SLTE and FOC. If we correctly understand from your explanation that we can send Primary and secondary communication on one SLTE with different channels!!!
    Just one clarification for latency, can we say DeltaV ACN will required latency of <1ms and Think client Network need <20ms.

    Avinash M Mohod.
  • In reply to Avinash:

    yes, you can send primary and secondary DeltaV over the same fiber. SLTE is the technology used for connecting the Internet across the oceans. So I would expect SLTE to be sub 1ms.

    As for DeltaV maximum latency, there are no published specifications. But we have 400 ms time out values on our peer to peer communications and 200 ms on IO nodes. That is round trip. So 20 ms will not cause you an issue , and it can survive much more. I think 20 ms is reasonable and SLTE should beat that by a mile.

    RDP, which is the technology behind our thin client is very robust over a wide range of network performance, but we expect LAN based performance with latencies of our Thin client network to be fairly low. I've run DeltaV quad monitors on test networks with degraded (increased) latency and with the RDP set to normal LAN settings, no issues are seen with 20 ms. Technically, the RDP client can be tuned to perform well with much larger latency and smaller bandwidth. We don't want that for your Operator Station. So we want our network infrastructure to deliver sum 20ms latency. That's not usually an issue.

    My office to office RDP session over 300 km using standard Internet service provider's standard service is around 6 ms. And it's like sitting at the computer.

    Again, ask you equipment provider about how many separate networks you can create, and what their latency and bandwidth are, and how you would connect. Sub 20 ms at 1 Gb and you are good to go. Also ask about availability and failure modes. Maybe you want to make sure the primary networks and Secondary networks are on different channels or wavelengths. They can guide you on the most robust design give the redundant networks at both ends.

    Andre Dicaire