Lightweight Ethernet

p21-36:p26-32.qxd

09/12/2010

13:34

Page 11

Digital Ship

Lightweight Ethernet – a new standard for shipboard networks The International Electrotechnical Commission’s TC80 working group has developed a new standard for the use of Ethernet in maritime navigation networks. Nicknamed ‘Lightweight Ethernet’ (LWE), this standard offers a number of potential benefits in the construction of shipboard networks, write Morten Jagd Christensen, Thrane & Thrane, and Ørnulf Jan Rødseth, MARINTEK he International Electrotechnical Commission (IEC) is an organisation responsible for developing standards for electrical, electronic and related technologies.

As part of this responsibility, working group 6 (Digital Interfaces) of IEC’s Technical Committee 80 ‘Maritime Navigation and Radiocommunication Equipment and Systems’, has developed a new computer network standard for use of Ethernet in maritime navigation networks.

This standard is the result of the collaborative and consensus based work of the participants of the working group, as well as numerous technical comments and proposals from IEC’s national member organisations.

The official standard will be named IEC 61162-450 ‘Multiple talkers and multiple listeners - Ethernet interconnection’.

Within the working group the nickname ‘Lightweight Ethernet’ (LWE) has been in common use, and this article continues that tradition.

Here we will present some background information and selected details from the standard.

T

Background Ethernet has been in use onboard ships for a long time and various standards have been suggested since before 1995, when IEC TC80 started to work on this issue.

The first specification was of a redundant network system based on Ethernet and TCP/IP. This was adopted as an international standard in 2001 and got the designation IEC 61162-400.

Unfortunately, the specification proved

too complex for the industry to adopt and lack of high quality protocol implementations led to the standard’s silent demise.

However, the need for a high capacity and high speed bridge data network was more and more acutely felt, and in 2008 a new work item was approved by IEC TC80 to develop a new Lightweight Ethernet standard.

The selection of Ethernet and Internet Protocol (IP) based data transport layers reflects a general trend with a convergence to Ethernet-like technologies everywhere. Today even very small devices can have support for Ethernet at almost negligible cost.

Ethernet has been able to quickly respond to the hunger for bandwidth, which is growing as fast as ever, but at the same time has kept a backwards compatibility to lower speeds. Today, identical Ethernet frames can be transported at link speeds from 10Mbps to 10Gbps over electrical and optical cables.

Ethernet is also able to supply power with the ‘Power over Ethernet’ (PoE) standards. This feature is a relatively new addition to the Ethernet family that could potentially cut the cabling used for installation in half, compared with the current practice of having separate power and data cables.

The IP standards are also ubiquitous in contemporary networked systems, again with extended support even in small embedded computers.

The world wide web is powered by IP as are many industrial control systems.

IP is also closely related to Ethernet, and the combination of Ethernet and IP is a de facto standard for emerging net-

Figure 1 - LWE devices connected to an Ethernet switch

worked systems, for home as well as industrial use.

Thus, the selection of Ethernet and IP was an obvious choice also for the new navigation network standard.

Overall principles and design choices From the outset, there were a number of requirements that needed to be satisfied by the new standard: Easy to implement: On the order of a few weeks’ work to implement the protocol from scratch Lightweight: Possible to implement the protocol on embedded computers, e.g., in a GPS receiver

Digital Ship December 2010 page 31

Migration: Provide a simple migration path for equipment already using sentences from the existing IEC 61162-1 standard (based on NMEA 0183) Capacity and scalability: Support existing bridge systems as well as foreseeable capacity and speed requirements for new bridge systems Increasing complexity: Address increasing complexity in integrated navigation and bridge systems design.

This has led to the following design choices for LWE, which mandates the use of: Single switched Ethernet UDP datagrams IP multicast A function block approach for devices.

p21-36:p26-32.qxd

09/12/2010

13:34

Page 12

ELECTRONICS & NAVIGATION The requirement of a switched network solution makes addressing easier, since all devices reside on the same subnet and both routing protocols as well as configuration of routing tables are avoided.

Switching generally achieves the highest possible aggregate network bandwidth, and the total system load can approach 100 per cent without packet losses.

A unicast solution (e.g., TCP/IP or unicast UDP) was discarded as it was decided to keep the ‘one talker to many listeners’ paradigm from IEC 61162-1.

The use of multicast was chosen over broadcast for performance considerations – with broadcast every device would receive, read and process all messages to find those of interest to that particular device. This requires the CPU to examine all packets even though the device is only interested in a fraction of the traffic.

IP multicast can be very efficiently filtered in modern Ethernet hardware, with only the relevant packets reaching the CPU. IP multicast addresses map directly to Ethernet multicast addresses and most (if not all) modern Ethernet chipsets have Ethernet address filter tables which operate at wire speed.

The function block approach allows the network to be looked at as a set of logical function blocks, although many function blocks may reside on the same physical device.

This means, e.g., that a combined GLONASS and GPS receiver only needs one physical interface to the network.

However, the two receivers may, if

Group

Usage

IP address

port number

MISC TGTG

Miscellaneous Tracking and Targeting data

239.192.0.1 239.192.0.2

60001 60002

SATD AVD

Satellite navigation Other navigation data

239.192.0.3 239.192.0.4

60003 60004

VDRD RCOM

Voyage Data Recorders Radio communications

239.192.0.5 239.192.0.6

60005 60006

TIME

Time and Date

239.192.0.7

60007

PROP

Proprietary sentences

239.192.0.8

60008

USR1-USR8

User defined transmission groups

239.192.0.9 – 239.192.0.16

60009 – 60016

Table 1 - The default classification maps talker IDs to eight ports and IP addresses

desired, be looked at as two ‘independent’ function blocks.

Details and implications We will now describe the standard and its implications in more detail. We start with an example of a navigation network, which illustrates some of the different types of equipment that might be attached.

In Figure 1 (see previous page) we show a number of LWE devices connected to the Ethernet switch. The devices can be grouped in three types: Receive only, transmit only and generic devices that are assumed to both transmit and receive LWE data.

The illustration also shows an LWE gateway device that provides an interface to one or more IEC 61162-1 devices. The arrows indicate the flow of data between devices and their thickness illustrates the amount of network traffic.

Each transmitting function block uses one IP multicast address and a corresponding UDP port for all its transmissions.

The LWE standard specifies 16 address/port pairs that can be used by senders and receivers. A default address/port pair is assigned to each functional unit identified in the IEC 61162-1 standard (based on the ‘talker identifier’).

The default classification maps the 50+ talker IDs to eight address/port pairs. For example, sentences transmitted with the GP talker ID belong to the NAVD group, which defaults to IP address 239.192.0.4 and port number 60004 (see Table 1).

The standard specifies an encapsulation format for IEC 61162-1 sentences. This format adds some functionality to the sentences in terms of grouping, sender and destination identity, as well as sentence numbering.

This functionality is in part added to provide some possibility for internal checks on lost sentences as well as new functionality related to peer to peer communication, e.g., for alert management.

In addition to the sentence based transmissions, the standards also have two other types of messages. The first is the addition of special transmission groups and message formats for binary image data.

Binary data is all forms of non-IEC 61162 sentence data and could, for example, be radar images or large text files.

These images are anticipated to be large and probably also frequently transmitted, thus utilising a relatively large part of the bandwidth of the Ethernet media. These messages are assigned their own IP multicast address range for efficient filtering.

The other message type is related to system-wide diagnostics and it specifies the use of syslog for external logging.

Syslog is a standard for transmitting errors, events and notifications to a central logging facility. The use of syslog will make troubleshooting an LWE network easier since the notifications from different devices are recorded in order and precise timing of related events can be detected.

The LWE standard even takes syslog a

About the authors Morten Jagd Christensen is technology manager for software at Thrane & Thrane. Mr Chrstensen has been active in standardisation work in IEEE and IETF, and is the main author of the RFC for IGMP snooping, which defines the best current practices for use of multicast in a switched Ethernet environment.

Digital Ship December 2010 page 32

little further by mandating that syslog messages are sent on a separate multicast group, as this eliminates the need for manual configuration.

Safety and security issues The use of integrated networks raises both safety and security concerns. These are addressed in the standard as informative annexes, i.e., no absolute requirements are defined to address these issues.

The reason for this is that current and foreseeable ship systems will need to integrate both new and legacy systems, and this makes it very difficult to specify one standard way to implement, e.g., redundancy.

One may want to use two independent IEC 61162-450 networks, a combination of serial lines and an Ethernet, or any of a multitude of in-between solutions, based on a safety and cost/benefit analysis for the specific system.

Thus, at this specific time, it is not possible to usefully specify one technical solution.

For security, the current solution is to isolate the critical network from access by any unauthorised persons. This is expected to be the case for new systems as well.

However, here one can safely expect manufacturers and users to look at the possibilities of connecting the system to off-ship resources, e.g., for maintenance, repair or software updates.

While the standard contains some informative advice on these issues, one will need to get any such solution approved by the appropriate authorities.

A draft standard (CDV – Committee Draft for Voting) was sent out for comments to IEC’s national member organisations in March 2010. The final draft international standard (FDIS) was aimed to be ready by December 2010 and the expected time for approval is sometime in Q1 2011.

Some manufacturers are already in the process of testing out the specification and we expect the first LWE equipment to appear on the market shortly after final approval.

DS

Ă˜rnulf Jan Rødseth is research director at MARI TEK, in the department of Maritime Transport Systems. Mr Rødseth's particular area of interest is digital communication within ships and between ships and shore, including onboard data networks. He is participating in ISO and IEC standardisation work and was project manager for the IEC 61162-450 standard.