Digital Ship December 2010 page 31

Digital Ship

Lightweight Ethernet – a new standard for shipboard networks

TThe International Electrotechnical

Commission (IEC) is an organisa-

tion 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 col-

laborative and consensus based work of

the participants of the working group, as

well as numerous technical comments

and proposals from IEC’s national mem-

ber 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.

BackgroundEthernet 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 redun-

dant network system based on Ethernet

and TCP/IP. This was adopted as an inter-

national standard in 2001 and got the des-

ignation IEC 61162-400.

Unfortunately, the specification proved

too complex for the industry to adopt and

lack of high quality protocol implementa-

tions 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 conver-

gence to Ethernet-like technologies every-

where. Today even very small devices can

have support for Ethernet at almost negli-

gible 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 compati-

bility to lower speeds. Today, identical

Ethernet frames can be transported at link

speeds from 10Mbps to 10Gbps over elec-

trical and optical cables.

Ethernet is also able to supply power

with the ‘Power over Ethernet’ (PoE) stan-

dards. This feature is a relatively new

addition to the Ethernet family that could

potentially cut the cabling used for instal-

lation 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-

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 anddesign 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

� Migration: Provide a simple migration

path for equipment already using sen-

tences from the existing IEC 61162-1

standard (based on NMEA 0183)

� Capacity and scalability: Support

existing bridge systems as well as fore-

seeable capacity and speed require-

ments for new bridge systems

� Increasing complexity: Address

increasing complexity in integrated

navigation and bridge systems design.

This has led to the following design choic-

es for LWE, which mandates the use of:

� Single switched Ethernet

� UDP datagrams

� IP multicast

� A function block approach for devices.

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

Figure 1 - LWE devices connected to an Ethernet switch

p21-36:p26-32.qxd 09/12/2010 13:34 Page 11

Digital Ship December 2010 page 32

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 configu-

ration 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 uni-

cast 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 fil-

tered 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 oper-

ate 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

desired, be looked at as two ‘independent’

function blocks.

Details and implicationsWe 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 connect-

ed 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 correspon-

ding 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 func-

tional 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 encapsula-

tion format for IEC 61162-1 sentences. This

format adds some functionality to the sen-

tences 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 com-

munication, e.g., for alert management.

In addition to the sentence based trans-

missions, the standards also have two other

types of messages. The first is the addition

of special transmission groups and mes-

sage formats for binary image data.

Binary data is all forms of non-IEC

61162 sentence data and could, for exam-

ple, 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 multi-

cast 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

little further by mandating that syslog

messages are sent on a separate multicast

group, as this eliminates the need for man-

ual configuration.

Safety and securityissues

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 inte-

grate both new and legacy systems, and this

makes it very difficult to specify one stan-

dard 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 expect-

ed 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 com-

ments to IEC’s national member organisa-

tions in March 2010. The final draft inter-

national 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.

Group Usage IP address port number

MISC Miscellaneous 239.192.0.1 60001

TGTG Tracking and Targeting data 239.192.0.2 60002

SATD Satellite navigation 239.192.0.3 60003

�AVD Other navigation data 239.192.0.4 60004

VDRD Voyage Data Recorders 239.192.0.5 60005

RCOM Radio communications 239.192.0.6 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

About the authors

Morten Jagd Christensen is technolo-

gy 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.

Ørnulf Jan Rødseth is research direc-

tor at MARI�TEK, in the department of

Maritime Transport Systems. Mr Rødseth's

particular area of interest is digital com-

munication within ships and between ships

and shore, including onboard data net-

works. He is participating in ISO and IEC

standardisation work and was project

manager for the IEC 61162-450 standard.

DS

p21-36:p26-32.qxd 09/12/2010 13:34 Page 12