Michael J. Roa

Industrial Ethernet Networks and Device Level / Field Bus Networks for Marine and Naval Applications

ABSTRACT

This paper will discuss the application of current ABS Naval Vessel Rules (NVR) for control and automation system industrial Ethernet networks at the sub­system / zonal level including device level and field bus type networks for applications in naval machinery control systems. The background and evolution of industrial Ethernet networks and device level / field bus technology will be discussed. The major characteristics of the most common industrial network technologies available today, including Ethernet/IP, ProfiNET/Profibus, and Modbus/TCP will be outlined. Various network topologies will be compared in terms of performance and survivability. Recommendations for possible future NVR rules to directly address these types of network technologies will be presented.

INTRODUCTION

As a result of the increasing complexities of shipboard control and automation system networks on naval combatants, and the numerous different types of networks and networking technologies being employed at different levels within control and automation systems, the ABS Naval Vessel Rules for control and automation networks have been in continual development. Several major rule changes have been recently implemented to further define the rules for mission critical control and automation system networks. From issues raised on the recent naval projects, it has been suggested that further guidance be provided in the Naval Vessel Rules on how to apply the rules to the mid­level and lower level networks also known as sub­level, zonal, device­level or field bus networks.

The performance characteristics, topologies, and protocols required at these lower levels may differ significantly from what is needed at the higher shipwide levels.

In the Naval Vessel Rules, there are two sets of criteria for control and automation networks provided. The 1 st set of criteria is for shipwide mission critical networks such as shipwide control and automation system networks that serve multiple essential systems over an integrated backbone topology. The 2 nd set of criteria is for dedicated stand alone local area networks which are dedicated to a single sub­system or equipment such as a dedicated waterjet control system network. The type / purpose of the network determines which set of criteria should be applied. While the rules are well defined for higher level shipwide control and automation networks, the rules for mid­level or field bus type networks are not as detailed and it is not obvious to the casual reader which set of criteria to apply to these types of networks. This paper examines the issues closely, provides examples of when each set of criteria applies, and offer suggestions for future rule improvements and areas of development.

NAVAL VESSEL RULES (NVR) BACKGROUND

During 1990s, U.S. Department of Defense Procurement Reform policies began to encourage maximum use of commercial standards and Commercial­off­the­shelf (COTS) equipment. DOD began promoting the use of commercial standards and specifications wherever possible and, consequently, the U.S. Navy General Specifications for Shipbuilding were cancelled in 1998. It was recognized early that ABS has long history of classing Naval

Auxiliaries to commercial Steel Vessel Rules and ABS was tapped as a potential resource and partner in this effort to create new technical shipbuilding standards for the Navy. ABS and the Navy began to work as a team to respond to the need for a new process to maintain and apply baseline technical criteria.

Accordingly, the American Bureau of Shipping (ABS) proceeded with development of Naval Vessel Rules as a joint effort with the Naval Sea Systems Command (NAVSEA). NAVSEA and ABS jointly developed and implemented a set of Naval Vessel Rules to be used in the design, construction, maintenance and modernization of non­nuclear naval combatant ships. After many years of success in applying the ABS ship classification process on many Sealift and Naval Auxiliary programs the Navy and ABS decided to collaborate to address the lower risk aspects of designing and certifying non­nuclear naval combatant ships. This allows in­house Navy engineering resources to be focused more on the higher risk mission related aspects of combatants, while maintaining technical control via close collaboration with ABS on the Naval Vessel Rules ­ the foundation for the process. The Navy retains technical authority, but uses ABS as a business partner to administer the Naval Vessel Rules, and as an agent in classing ships to the Naval Vessel Rules.

The ABS Naval Vessel Rules, as tailored by approved exceptions, are currently applicable for USS Freedom (LCS 1), USS Independence (LCS 2), and USS Zumwalt (DDG 1000) shipbuilding programs and will be applicable for all future non­nuclear surface combatants. As per the rules, the Naval Technical Authority remains in the lead role for certification of Control and Navigation Systems Software, Mission

Critical Networks, and Safety Critical Control Systems.

EVOLUTION OF FIELD BUS AND INDUSTRIAL ETHERNET

Field bus technology was introduced in the 1970s and has become the predominant networking technology for industrial automation systems. The term field bus is defined in IEC 61158, “Digital data Communication for measurement and control – Field bus for use in industrial control systems.” as follows: “Conceptually, a field bus is a digital, serial, multidrop, data bus for communication with industrial control and instrumentation devices such as – but not limited to – transducers, actuators and controllers.” Field bus technology is typically employed at the lowest levels of industrial control and automation systems. It is typically used where individual sensors and controllers can be connected to a common data bus, usually a bus or loop, which is the tied to a data acquisition unit that is communicating with Human Machine Interfaces (HMI) on a higher level shipwide control and automation system network. By connecting multiple equipments and sensors on a daisy­chained bus or loop, much cabling is saved over the traditional point to point wring methods. Three field bus protocols that are commonly used in industry are as follows:

§ DeviceNet § MODBUS § Profibus

IEC Publication 61158 depicts a generic field bus as shown in figure 1(a). A typical traditional marine automation network with field bus technology at the lower levels is shown in Figure 1(b).

FIGURE 1(a). Generic Industry Field bus Network

FIGURE 1(b). Traditional Marine Automation Network with Field bus at Device Level

In this arrangement, three separate communication networks are provided for three separate purposes; (a) Information network, (b) Low Speed control Network, and (c) Device level networks. Each of these separate federated networks is optimized for the intended purpose. Different networking protocols and architectures are typically employed at these three levels.

At the lowest level the 'Device (field bus) Network' collects a large number of relatively small data items (a small number of bits or bytes each). It typically operates in a repetitive cycle, and the speed of the cycle determines the responsiveness of the controller that needs the information.

Information sent down a Device Network is normally 'packed' into a small number of messages, either one per 'drop' for a multi­ drop remote I/O network, or perhaps even a single aggregate message for networks. This consolidates the packet overheads over a large number of data items, and so improves the data carrying capacities of the network at a given network speed.

Since device networks are primarily used to save wiring cost as compared to individual point to point field wiring of each sensor and actuator, it is important that the response time is kept controlled. Therefore these networks are designed to favor low latency requirements over information throughput. One of the most effective techniques for keeping the latency under control is to transfer all information in a continuous scan cycle. Cycle times might be from 1 ms to 100 ms depending upon the type of control being attempted.

The key performance characteristic of a field bus network is determinism. The determinism of a protocol is the ability to support predictable and stable transmission of high speed control parameters between the devices attached to a field bus. The data transfer must be completed in a defined time period and confirmation must be provided. Determinism is critical to the design of stable closed­loop systems for current control problems, and especially for next generation control systems. For real­time control, determinism is the primary measure of field bus reliability and Quality of Service (QOS).

Recently a number of field bus protocols have migrated to switched Ethernet based protocols in order to enhance communications capabilities and make it easier to integrate automation system networks from the HMI level down to the field devices. The major drivers behind this migration to Ethernet are:

• Integration to the office world, IT­ functions, Internet/intranet, remote

configuration. This is a world of TCP/IP on Ethernet with application protocols like SNMP, FTP, MIME, HTTP. Communications over routers and servers where IP­ addressing and TCP­transport are mandatory.

• More bandwidth and bigger data package for communications with more and more intelligent automation devices;

• Faster realtime communication with synchronization good enough for demanding real­time control applications;

• Connecting and addressing more devices over wider areas;

• Homogenous networking mostly using Ethernet;

• New functions like on­line updating of firmware and remote configuration and error handling;

• Integration of existing field buses.

Figure 2 shows the new method of Industrial Ethernet Networking where the information networks (enterprise level) are connected to the field bus level sub­networks through redundant Ethernet links in Figure 2:

FIGURE 2. Industrial Ethernet Network

Three common Ethernet based field bus protocols that have evolved are Ethernet/IP, MODBUS/TCP, and PROFINET. Ethernet/IP has evolved from DeviceNet, MODBUS/TCP has evolved from MODBUS, and PROFINET has evolved from Profibus.

Ethernet/IP EtherNet/IP, based on Ethernet TCP or UDP IP, is a stack extension for automation industry communication. The 'IP', in EtherNet/IP, stands for Industrial Protocol. EtherNet/IP was introduced towards the end of 2000. In EtherNet/IP the upper­level Control and Information Protocol (CIP) which is already used in ControlNet and DeviceNet is adapted to Ethernet TCP/IP and UDP/IP respectively.

Modbus/TCP Modbus/TCP is a derivative of the Modbus protocol and the open specification, based on Ethernet and standard TCP/IP, mounts directly on Layer 4. It defines a simple structured, open and widely used transmission protocol for a master­slave communication.

PROFINET The first version of PROFINET used Ethernet for non time­critical communication of higher­level devices and Profibus­DP field bus technology for real­ time domains integrated to a higher level by Proxies.

In its second release, PROFINET provided two communication mechanisms over Ethernet: The standard non real­time communication channel uses TCP/IP while the second channel bypassing the Layers 3 and 4 of the OSI reference model provides more deterministic communication. The protocol reduces data length in order to minimize the throughput time in the communication stack. For an optimal communication performance PROFINET prioritizes the packet as specified in IEEE 802.1p. For real­time communication the highest priority (priority 7) will be used.

The following Table 1 provides a brief summary of the major characteristics of the three major Ethernet based field bus protocols that are typically employed on Industrial and Marine automation systems:

TABLE 1 Major Characteristics Of The Three Major Ethernet Based Field Bus Protocols

Protocol Description Method Realtime performance

Functions

EtherNet/IP (IP=Industrial Protocol) Defined by Rockwell. Supported by the ODVA with some 250 members. Main producer is Rockwell for controllers, I/O, HMI and drives; Accu­Sort Systems, Datalogic and Sick: bar code readers; Acromag, Phoenix and Wago: I/O; Bosch Rexroth, Parker Hannifin and SMC: valves. About 21 certified products. In spring 2004 General Motors declared that it would standardize on Ethernet/IP for its automation programs.

Based on normal TCP/IP with alternative UDP/IP as an object embedding protocol, CIP (Common Interface Protocol), transports I/O­data, configuration and diagnostics over normal Ethernet. Non­ deterministic with reaction time down to 10ms. Synchronization (CIPsynq ­ IEC61588) can be added. Bandwidth for TCP/IP 90­100%.

Cyclic communication 10­100ms.

Synchronization about 10µs.

Field bus migration over bridges for ControlNet and DeviceNet (installed base 2.5m nodes) which use the same CIP application protocol. Drive control with moderate cycle time and synchronization. Safety protocol planned but not yet ready and approved.

Modbus/TCP Defined by Schneider Electric. Supported by the user group Modbus­ IDA. The original Modbus protocol (e.g. RS485) in use since 1979. Migration to Ethernet easy to implement and widely spread. Probably the most used Ethernet solution so far. About 90 products mostly from suppliers of remote I/O

Based on normal TCP/IP embedding Modbus, a very simple protocol using a request/reply model. The solution is nondeterministic and reaction time is 20ms at best. Realtime with RTPS (Realtime Publisher Subscriber) can be added. This uses UDP/IP to

Cyclic communication 20­100ms.

No synchronization .

Connection of Modbus to Ethernet. Simple protocol for I/O and reading/ writing in registers.

Protocol Description Method Realtime performance

Functions

who have multiple choice of interface. improve performance but not to true realtime standards. Bandwidth for TCP/IP 90­ 100%.

Profinet Defined by Profibus International with more than 1200 members and regional organizations in 25 countries on all continents. More than 25 companies with 100+ products. Beckhoff: PLC and I/O; Comsoft: I/O­controller; Comtrol: I/O­controller and gateways; Danfoss, Rexroth, SEW: drives and motion control; HMS: I/O and I/O­ controller, Interbus Proxy, Gateways; Hilscher: I/O and I/O controller, gateways and software; Phoenix Contact: Interbus proxy, I/O and I/O­ controller; Siemens: PLC, drives and motion control, I/O and I/O­controller, PC­cards, asics; Wago: I/O; Yokogawa: PLC. German auto industry comprising Audi, BMW, Daimler­Chrysler and Volkswagen, declared on Profinet.

Normal TCP/IP is used for most functions. This includes configuration, parameterization and CBA (Component Based Automation). No restrictions on TCP/IP traffic. For I/O and other realtime functions down to 1ms, direct addressing and prioritized messages are used (RT channel). No restrictions for TCP/IP­traffic but shorter delays can occur in switches due to the priority.

Cycle times from 250µs with 30 axis and 50% TCP/IP. 150 axis in 1ms.

Synchronization <1µs.

CBA, transparent migration for Profibus (installed base 13m nodes) and Interbus (installed base: 7.5m nodes). Other field bus migrations in progress. Safety protocol based on PROFIsafe available with approval expected shortly. Other from Profibus profiles for completion over the next two years. New profiles like MES­functions, starting with Maintenance, are implemented.

Source: http://ethernet.industrial­networking.com

DISCUSSION

Examples where field bus technology is typically employed include dedicated local area networks for major equipment such as gas turbine controllers, waterjet steering control systems, and motor drives. Field bus networks are also typically used at the lowest level of a shipwide automation system to connect sensors and equipment to the data acquisition units. The DAUs are then typically connected to each other via a mid­level shipwide network using Ethernet switches to communicate to the various Human Machine Interfaces and consoles throughout the ship.

Another design factor that can impact determinism is the physical architecture of the field bus, better known as topology. The topology of a field bus may have significant impact on the determinism of a field bus. The topology is also the key factor in establishing fault tolerance level.

While the primary reason for using field bus technology is to save weight and costs of point to point wiring, the choice of topology is the main driver of cost and weight, and

fault tolerance. On the scale of cost, weight, and fault tolerance, the most expensive, heavy, and fault tolerant topologies would be full mesh connections between servers, core switches, and edge switches with point to point wiring to equipment and devices; these topologies would also be the most responsive and deterministic. Full mesh and partial mesh topologies are usually employed at the higher level shipwide networks that serve multiple systems and require a high level of fault tolerance and survivability. The software to support these higher level systems usually employs self­ healing algorithms such as Rapid Spanning Tree Protocol to restore network communications in the event of a cable break or switch failure.

Alternative topologies such as redundant bus, star, tree, and ring (loop) topologies are usually less expensive, less weight, and are easier to install, and come with simpler off­ the­shelf interface software/hardware. However, these types of topologies generally provide less determinism, and are not as fault tolerant as a full mesh or partial mesh. For single point failures, the simpler field bus topologies can often recover more

quickly than a mesh network because they are not as complicated and the switches do not have to poll as many nodes to reconfigure the routing tables. The software packages required to reconfigure an Industrial ring topology are usually off­the­ shelf products as this is a very common type of system architecture. Proprietary ring redundancy manager software may be employed to achiever even faster recovery time. However, from a fault tolerance and survivability perspective, these topologies tend not to be as survivable/fault tolerant as mesh networks. While they can handle single point failures faster than a mesh, they

cannot survive multiple switch failures or multiple cable breaks. For this reason, the use of dual­bus, tree, star, and ring topologies use is usually limited to lower level field bus networks or field bus segments that are dedicated to providing a single specific service, such as a dedicated local area network (LAN) for waterjet steering/thrust controls, Gas Turbine LANs, and Propulsion Motor Drive LANs. The equipment and systems served by the lower level networks and the effects of a failure are the key factors in determining which topologies and protocols can be employed. Example topologies are as follows:

FIGURE 3. Star Topology

FIGURE 4. Ring (loop) Topology

FIGURE 5. Bus Topology

FIGURE 6. Tree Toplogy

FIGURE 7. Mesh Toplogy

The illustration shows a full mesh network with five nodes. Each node is shown as a sphere, and connections are shown as straight lines. A mesh network is reliable and offers redundancy. If one node can no longer operate, all the rest can still communicate with each other, directly or through one or more intermediate nodes.

FIGURE 8. Partial Mesh Toplogy

Partial Mesh (core backbone network switches arranged in full mesh with edge switches arranged in partial mesh with at least 2 connections to 2 different core switches)

When Industrial Ethernet based field bus technology is used in a shipwide automation system, careful consideration must be given to define the minimum fault tolerance required for selection of topologies and protocols that will maximize determinism. The Naval Vessel Rules provide two sets of criteria:

NVR Section 4­1­13, Mission Critical Networks, specifies a full mesh network for networks up to 4 switches and a partial mesh network for networks that have 5 or more switches (for 5 or more switches, each switch must be connected to at least 3 other switches). The NVR 4­1­13 criteria is intended for integrated shipwide automation networks that support multiple shipboard systems. In these cases, the maximum level of fault tolerance and survivability are required in order to survive multiple failures due to battle damage.

NVR Section 4­2­6, Computer Based Systems, specifies a basic redundant fault tolerant network such that no single point of failure exists on the system. These rules were derived from the commercial Steel Vessel Rules and were intended for the simpler applications on naval ships such as local area networks that support major equipment such as propulsion motor drives, gas turbines, diesel engines, and waterjets control systems.

The area where there has been some need for clarification is where field bus

technology has been extended up into the mid­level shipwide networks. Ethernet based Industrial Ring topologies with COTS supporting software are fairly common in the commercial world, and meet the minimum class society rules and flag state regulations to survive a single point of failure. However, on a naval combatant, this level of fault tolerance and survivability would not be acceptable for shipwide networks supporting multiple mission critical systems.

For example, a mid­level shipwide network that supports multiple engineering systems would need to meet 4­1­13, unless it was sufficiently integrated with a higher level total ship network such that if the mid level ring network suffered multiple failures and were split into multiple sections, it should still be able communicate via the total ship network. If a mid­level ring topology is not sufficiently integrated with the total ship network, a double failure will not be mitigated by connectivity via the total ship network. In a ring topology, the loop may be broken in two places and the two sides of the broken ring would not be able to communicate bi­directionally via the total ship network interfaces (see figure 9). A condition could occur where the mid­level network could be segregated into several disparate networks, unable to communicate with each other.

FIGURE 9. Mixed Topologies ­ Hi­level Mesh combined with Sub­level Ring

Alternatively, the mid level network could be provided in a mesh configuration with an equivalent level of fault tolerance and survivability as the higher level network. In this case, it would also have to be capable of independent operation in an event of a loss of connectivity with the higher level network.

Another alternative would be dual­ring topologies (see figure 10) where two rings are arranged to provide superior fault tolerance and survivability. This usually consist of two concentric rings that connect each node on a network instead of one network ring that is used in a ring topology. Typically, the secondary ring in a dual­ring topology is redundant. It is used as a backup in case the primary ring fails. In these configurations, data moves in opposite directions around the rings. Each ring is independent of the other until the primary ring fails and the two rings are connected to continue the flow of data traffic. Provided that it meets the NVR performance requirements for mission critical networks, this type of toplogy may be an acceptable alternative to a full­mesh on naval combatants.

Edge switch (green) Interfaces to total ship network

Core switches (blue)

Mid level, Machinery control system Network with Industrial Ring toplogy

Ethernet switches (yellow)

Interface boundary

Hi­level Shipwide Total Ship network, Partial Mesh topology

FIGURE 10. Dual Ring Topology

RECOMMENDATIONS

The Naval Vessel Rules for mid­level control and automation networks need to be clarified in order to prevent misapplication of the requirements. A rule change should be drafted to explain where and when the different criteria are to be applied.

Additionally, consideration should be given to creating an Automation Systems Handbook that provides detailed guidance and examples on how to apply the Naval Vessel Rules to shipboard automation networks. This approach is similar to how the USCG Navigation and Inspection Circulars (NVICs) provide an explanation on how to apply the USCG regulations provided in the Code of Federal Regulations (CFR). Another excellent example is the National Electric Code (NEC) 2005 Handbook (1331 pages with many excellent illustrations) that provides explicit examples of how to apply NEC requirements.

The NVR should be modified to include provisions for data links to meet open

standards for field buses as identified in IEC 61158, “Digital data Communication for measurement and control – Field bus for use in industrial control systems.”, or other recognized industry standards acceptable to the Naval Technical Authority. The rules need to be further developed to fully address field bus in terms of topics such as field bus architectures, protocols, cabling links, and I/O density.

CONCLUSIONS

NVR 4­1­13 is the minimum criteria for a shipwide control and automation system network. It specifies the minimum performance and fault tolerance required for mission critical automation system networks.

The lesser criteria in NVR 4­2­6 may be employed for specific stand alone applications such as dedicated field bus local area networks that operate independently of the ship’s main shipwide network. For these applications, a simpler ring or dual bus

topology is sufficient provided it can survive single point failures.

As Industrial Ethernet and field bus protocols continue to proliferate the Naval Automation systems, additional detailed criteria may have to be established in the future to ensure that the Navy's minimum fault tolerance and survivability levels are maintained at all levels of the ship, from HMI consoles to field devices. Also, to achieve the cost­savings, safety and interoperability benefits of open standards over the ship's life cycle, the Navy/ABS/Industry Team plans to evaluate the Electronic Device Description Language (EDDL), as described in the following two documents:

ANSI/ISA­61804­3 (104.00.01)­2007, Function Blocks (FB) for Process Control ­ Part 3: Electronic Device Description Language (EDDL).

ANSI/ISA­TR61804­4 (104.00.02)­2007, Function Blocks (FB) for Process Control ­ Part 4: Electronic Device Description (EDD) Interoperability Guideline.

ACKNOWLEDGEMENTS

Lou Nelson, NAVSEA 05Z33 (ex 05Z52), Surface Ship Control Systems; Steering, Maneuvering and Motion Stabilization Systems; Integrated Bridge and Navigation Systems (IBNS).

AUTHOR BIOGRAPHY

Michael J. Roa, Principal Engineer, ABS Americas, ABS Government Operations Office, Naval Engineering Department, Alexandria, Virginia USA § B.S. Electrical Engineering, The

Citadel, 1986 § Qualified Engineering Officer of the

Watch, USS CORAL SEA (CV­43), 1988

§ Currently enrolled in Masters of Science Program, Information Systems, University of Maryland at Baltimore Campus (UMBC)

§ 22 years experience in Shipboard Electrical Power, Machinery Control, Navigation, and Communication Systems

§ 7 years on Strategic Sealift Program § 9 years with ABS developing Naval

Vessel Rules Parts 3 & 4 § Principal author for NVR Part 3,

Electrical Systems and NVR Part 4, Control and Navigation Systems

§ Current duties include performing plan review on various ABS classed government vessels including LCS ships and DDG­1000.

§ Member IEEE, ASNE, SNAME, Tau Beta Pi

§ Working Group Member, IEEE Std 45, Shipboard Installations, Control and Automation

§ Working Group Member, IEEE Draft Std P1662, Power Electronics