Traditional Distributed Control Systems are complex and require multiple networking levels to be managed through different technologies. It is not uncommon for a system to have more than four different layers using different protocols, field, I/O subsystem, etc.
H1 fieldbus (IEC 61158-2) is a replacement for the field and I/O-sub-system protocols, with HSE at the host-level taking the control & business network’s place. A gateway is used to separate both host- and business-level networks, but as they use the same networking technology, it enables them to remain integrated while maintaining security.
Within a control system’s architecture, the H1 fieldbus has been used at the field level, connecting transmitters and positioners. On the other hand, HSE is used at host level, linking workstations and devices. This doesn’t mean that HSE will mean the end of H1, rather the two systems will supplement each other, compensating each other’s weaknesses. For instance, ethernet has a limited range of 100 meters, requiring multi-core cabling that can add up costs. In addition, ethernet requires a hub, which is cheap, but requires one port for each field device. On the other hand, H1 has low bandwidth capabilities making it inappropriate to form the backbone of the plant and does not have media redundancy.
The following is a feature-wise comparison of the H1 and HSE:
|
|
H1 |
Ethernet |
|
Speed |
31.25 kbit/s |
100 Mbit/s |
|
Distance |
1900 m |
100 m |
|
Two-wire |
Yes |
No |
|
Multidrop |
Yes |
No |
|
Bus power |
Yes |
No |
|
Intrinsically safe |
Yes |
No |
|
Media redundancy |
No |
Yes |
|
Deterministic |
Yes |
Yes |
When two controllers supplied from different manufacturers need to be connected together or to a workstation, ethernet isn’t the best choice, and it is highly likely that compatibility issues will spring up. Why does this happen, even though ethernet is a standard protocol? It’s because using ethernet and TCP/IP doesn’t mean fieldbus standards are eliminated.
Interoperability doesn’t mean connecting two devices together with a wire and not facing any issues. In addition to hardware connection, the devices’ software must be able communicate with each other. To understand this, one must know that ethernet only handles the bottom two layers of the OSI stack, whereas TCP/IP handles the next two. Ethernet was designed to handle several different protocols acting as a facilitator rather than as a sole solution. In order for a technology to have complete interoperability, it must have an application layer (layer 7) that has an open standard. If not, then drivers are needed on both devices to communicate. Furthermore, ethernet networks used in control systems are proprietary as they do not have their own application layer protocol. An example of an open-source interoperable topology would be Modbus/TCP that uses ethernet as the medium while TCP/IP is used for communications between the application layer with the same register method as Modbus/RTU. The standard is quite common in industrial systems, with several manufacturers using it.
But even with Modbus, there are several variations due to its open-source nature. The user needs to configure the network manually, specifying data types, significant digits, register numbers and scaling. The entire process can become cumbersome for large amounts of data. Thankfully, there’s a solution to this, namely OPC, which eliminates the problem as a long as workstation software is concerned. But for embedded devices, this doesn’t hold. A significant limitation for Modbus and other protocols is lack of standard programming and configuration software, leaving engineers no choice but to rely on their own experience.
Ease of use is becoming a defining factor in industrial systems. Clients are looking for simple installation that can be maintained by on-site personnel. Foundation HSE fieldbus uses Ethernet and UDP/IP instead of TCP/IP, supplementing interoperability with ease of use. Thus, by using this combination both these requirements can be met. HSE features not only the application layer but also the “user” layer, thus, providing a functional block diagram programming language, allowing users to build coordinated control strategies spread over devices from different manufacturers.
If a shutdown occurs within a system, it can disrupt the operation of entire plant floors. It is imperative that Ethernet be able to handle faults. Networks deployed within industries are designed with several redundancies while industrial-hardened components are used to handle several faults occurring at the same time. The HSE protocol specification’s upper layer already contains hot-standby redundancy. Moreover, redundant Ethernet hardware can be employed to search for alternative routes for communication if one path is cut off. An example of this is Petrobras’s Namorado-1 platform in Brazil that uses redundant HSE fieldbus network to obtain a high degree of availability. A hardware connection runs through the control room and the field locations with a hub-based star topology, ensuring that only one device per wire operates. If fault occurs, these may be disconnected accordingly without causing any disruptions in operations.
Next, fiber optics takes its roll in linking the switching hubs when long distances are involved. All network components have media redundancy, including but not limited to the hubs. The switchover times are minute, and thus, recovery occurs at an increased pace, resulting in lower loss of productivity. Ring topology is also used for fiber optic connections, either clockwise or counter-clockwise, giving long-term networks enough reliability against all types of faults.
Users are always looking for homogenous software environments, meaning Ethernet must exist as part of a single application and not an isolated software “island”. For example, Smar’s SYSTEM302 makes use of the H1 fieldbus at the field level while HSE is used at the host level. The maintenance tool SYSCON lets the user devise a control strategy, configure devices and manage both networks.
By using this application, network parameters can be optimized to suit devices that have different manufacturers, while meeting all necessary control objectives. The software is responsible for automatically detecting and identifying new devices, making it easy to commission and expand them. H1 network bridging is also managed, allowing the user to connect, disconnect and rearrange them to other ports. Assignment of addresses automatically eliminates potential human errors, while it is also possible to visualize and manage HSE redundancy, even for secondary devices that are inactive.
The software operates in the industrially-accepted Windows NT environment, even integrating with NT network making the maintenance extremely easy. The user can navigate through the network in the Fieldbus Explorer’s tree structure, starting from HSE, down to linking devices to H1, and from there to the instruments. The obvious advantage of using an IP scheme is that it gives administrators the ability to Ping nodes, helping them diagnose the network, especially when there is a string of gateways and subnets to manage. Finally, if required, a log of communication errors can be retrieved and analyzed at any point in time.
The last piece of the puzzle; this is where Ethernet and software really meet. In Process Control, OPC goes by the name OLE. A modern control system isn’t complete only if it has a configuration and monitoring software. Of all the various tools available, none “speaks” HSE or Ethernet. The SYSTEM302 tool discussed earlier is a universal fieldbus bridge called DFI302, helping link HSE and H1. It has a valuable addition as well: an OPC server running in redundant server station, making all process and device data available to a device running OPC client software.
OPC is built on the Distributed Common Object Model (DCOM), meaning any workstation present on the ethernet can access the data. Information can thus, be spread throughout the enterprise, and analyzed if necessary. The configuration tools also use an OLE client-server architecture to compensate for any gap that is left by OPC data access. It is actually a successor to the emerging OPC complex data access, which will soon be taking over.
The OPC and OLE integrate with the entire system, and once a function block is configured within a device, all its parameters are immediately available to OPC client machines, where they can be displayed or used for reporting purposes.
The world is progressing towards Ethernet, irrespective of the protocol that will be used, whether its Modbus/TCP, Profibus or ControlNet. It should be noted that Ethernet doesn’t mean universal interoperability, and you shouldn’t expect the previously stated protocol to work with each other. For process control, Foundation HSE Fieldbus is a viable choice as it is part of the IEC standard. You shouldn’t face any complications as long as the application layer protocol being used is identified. H1 can’t be written off completely though, not until Ethernet starts carrying power, features greater safety and runs without amplification for 2 miles.
Interested in learning more? Visit our website www.premierautomation.com, or talk to one of our specialists today.