The industrial ethernet protocol wars fieldbus revisited

%< $5& $'9,625< *5283 2&72%(5

7KH ,QGXVWULDO (WKHUQHW 3URWRFRO :DUV
)LHOGEXV 5HYLVLWHG

([HFXWLYH 2YHUYLHZ

RPSHWLWLRQ 0RYHV WR 8SSHU /DHUV

RPSHWLQJ $UFKLWHFWXUHV ,QFOXGH 7UDGLWLRQDO 'HYLFH 1HWZRUNV

(WKHU1HW,3 7DNHV ,3 WR D +LJKHU /HYHO

3XUH3OD ,'$ 7DUJHWV 'LVWULEXWHG :HEEDVHG $UFKLWHFWXUH
ZLWK ,QWHJUDO 6DIHW

352),QHW ,V 127 352),EXV RYHU (WKHUQHW

)RXQGDWLRQ )LHOGEXV +6( ([SDQGV ,WV +RUL]RQV %HRQG
3URFHVV RQWURO

,$21$ 6HHNV RPPRQ *URXQG

23 -XPSV LQWR WKH )UD

(QWHUSULVH $XWRPDWLRQ 6WUDWHJLHV IRU ,QGXVWU ([HFXWLYHV

6S8ÃT‡…h‡rtvr†Ã‡ÃPp‡‚ir…Ã! Ã

6XSHUYLVRU

';
352),QHW
1(7:25. /(9(/

RQWURO +6(

,2
'3

'HYLFH +
3$
73( 2) 21752/
0DFKLQHU 3URFHVV

Hr€‚…hqˆ€Ã‚sÃVqr…†‡hqvt

/HDGLQJ ,QGXVWULDO (WKHUQHW RQWHQGHUV DQG 5HODWHG 1HWZRUNV

1HWZRUN
(QYLURQPHQW 7HFKQRORJLHV 6SHFLILFDWLRQV

9HQGRU6SHFLILF
8‚svtˆ…h‡v‚ÃÉÃ
8‚svtˆ…h‡v‚
Hhhtr€r‡ÃT‚s‡h…r
6LHPHQV 5RFNZHOO
6FKQHLGHU

V†r…ÃGh’r…
9r‰vprÃQ…‚svyr†ÃPiwrp‡Ã 3URWRFRO6SHFLILF
H‚qryÃ‚…ÃGvi…h…’
(WKHU1HW,3
THUQÃ Hr†† 352),QHW ,'$

26, /DHUV

6ƒƒyvph‡v‚ CUUQ AUQ
r‡p htvt

Ir‡‚…xÃÉÃU…h†ƒ‚…‡ U8QDQÃV9Q
,QGXVWU
6WDQGDUGV
GvxÃÉÃQu’†vphy @‡ur…r‡

,QGXVWU 6WDQGDUGV $UH 2QO 3DUW RI WKH ,QGXVWULDO (WKHUQHW $UFKLWHFWXUH

Ã‡Ã6S8rip‚€Ã‡Ã8‚ƒ’…vtu‡Ã‹Ã6S8Ã6q‰v†‚…’ÃB…‚ˆƒ

Ã 6S8ÃT‡…h‡rtvr†Ã‡ÃPp‡‚ir…Ã! Ã

([HFXWLYH 2YHUYLHZ

Industrial Ethernet continues its march to lower levels of the plant hierarchy
as both standards organizations and automation suppliers address criticisms
of its suitability for plant floor applications. While Ethernet is an interna-
tional standard, IEEE 802.3 specifies only the physical and data link layers of
the 7-layer network stack. TCP/IP adds the further but minimal guarantee
that two devices can exchange data with one another. In the industrial
automation space, however, the lack of standard application and user layers
translates to ongoing headaches concerning which devices may connect to
the network, how devices interoperate on the network, and what level of
functionality is supported.

Ethernet’s rise in prominence comes after a protracted, decade-plus long bat-
tle to standardize the process Fieldbus certification, and now many fear that
industrial Ethernet protocol standardization will result in “Son
of Fieldbus.” Judging by today’s market profile, this fear of (WKHUQHW SURYLGHV D FRPPRQ
Fieldbus revisited is well founded. The only solace lies in QHWZRUN PHGLXP EXW FRPPRQ
DSSOLFDWLRQ ODHU SURWRFROV DUH
availability of common physical and network/transport layers
UHTXLUHG IRU WUXH GHYLFH
and the need to reconcile just three or four upper-level Ethernet
LQWHURSHUDELOLW
protocols compared to the ten or more Fieldbus protocols.

While the Fieldbus wars were fought all the way down to the level of com-
peting network media or physical layers, availability of a common Ethernet
TCP/IP stack has largely moved the protocol wars to the higher-level appli-
cation or “user” layers. This upper-layer functionality represents the new
battleground where the strategies of competing industrial Ethernet protocols
such as EtherNet/IP, PROFInet, IDA, and Foundation Fieldbus diverge.

Both IAONA and OPC are stepping in as third parties to try and mitigate the
potential for still another fieldbus war. After its initial founding as still an-
other industrial Ethernet specifying body, IAONA has positioned itself as a
neutral umbrella organization for the disparate industrial Ethernet factions.
The OPC foundation, on the other hand, has announced its intention to ex-
tend the existing OPC DA (Data Access) specification to allow run-time
interoperability across systems based on disparate industrial Ethernet net-
works.

8‚ƒ’…vtu‡Ã‹Ã6S8Ã6q‰v†‚…’ÃB…‚ˆƒÃ‡Ã6S8rip‚€Ã‡Ã


RPSHWLWLRQ 0RYHV WR 8SSHU /DHUV

User layer functionality such as common device profiles and their associated
object models is supposed to ensure device interoperability and interchange-
ability. Common EtherNet/IP device profiles, for example, are designed to
ensure that a replacement device is configured to produce or consume the
same basic set of I/O data and exhibits the same network behavior as the
original. This upper-layer functionality represents the new battleground
where the strategies of competing industrial Ethernet protocols such as
EtherNet/IP, PROFInet, IDA, and Foundation Fieldbus diverge.

The competitive landscape parts even further at the network configuration
level. While each protocol specifies some configuration parameters, vendors
augment this functionality with their own proprietary network configuration
tools that often add incremental functionality to their own devices or systems
versus those of competitors. As more and more of the industrial network is
standardized in first the industry standard Ethernet TCP/IP protocol, then
the higher-level industrial Ethernet protocol specifications, these vendor-
specific network configuration tools and associated software assume even
greater importance in control system selection.

When considering industrial Ethernet for control applications, varying inter-
pretations of often-broad protocol specifications are leading some end users
to implement homogenous vendor environments even when a common
higher-level protocol is employed. This strategy stems from the bottom-line
need for correct interpretation of control messages among plant
$ELOLW WR PL[ DQG PDWFK GHYLFHV floor devices and concern that devices from different vendors,
ZLWK IXQFWLRQDOLW IURP XSSHU ODHUV
even those supporting the same protocol, may not interoperate.
RI WKH LQGXVWULDO (WKHUQHW VWDFN LV
In order for true interoperability to occur, all suppliers must im-
QRW SDUW RI WKH LQLWLDO ,QGXVWULDO
(WKHUQHW YDOXH SURSRVLWLRQ plement a common set of communication services in the same
manner.

Similar to the findings in the device network arena, the combination of these
factors will result in most machines or control systems being implemented
with a single Ethernet protocol, e.g., EtherNet/IP or PROFInet, rather than a
mix and match of products supporting differing protocols. Consequently the
value proposition for industrial Ethernet will initially stem not from an abil-
ity to mix and match devices from different suppliers, but rather the
commonality and incremental functionality detailed in ARC’s recent report
on the Industrial Ethernet Value Proposition. Even at the supposedly com-



mon physical layer a standard industrial Ethernet connector may prove elu-
sive, although the efforts of standardization bodies such as EIA/TIA
(Electronics Industry Association/Telecommunications Industry Association)
may result in a standard physical layer connector suitable for industrial ap-
plications.

RPSHWLQJ $UFKLWHFWXUHV ,QFOXGH
7UDGLWLRQDO 'HYLFH 1HWZRUNV

In spite of efforts designed to push Ethernet to the lowest levels of the auto-
mation hierarchy, the reality is that most manufacturers will end up with a
continued cascade of automation networks from the supervisory through
control and ultimately device levels. Traditional device networks such as
PROFIbus DP and DeviceNet have established a firm foothold in the mar-
ketplace and in the near term many manufacturers will continue to specify
these networks for their low cost, real-time, multi-drop capabilities. This is
particularly true as long as the cost of an Ethernet interface, plus power to
the device if necessary, exceeds the cost of a similar configuration using a
standard device network. The star topology employed with Ethernet’s hub-
and switch configuration also sends
some customers to device networks for
(WKHUQHW 3URWRFRO RPSOHPHQWDU 'HYLFH 1HWZRUNV

their multi-drop capability and resulting
(WKHU1HW,3 'HYLFH1HW RQWURO1HW
lower wiring cost. With the notable
exception of the emerging IDA interface, )RXQGDWLRQ )LHOGEXV +6( )RXQGDWLRQ )LHOGEXV +

most of the competing industrial ,'$ 1RQH ,'$

Ethernet protocols have complementary 352),QHW 352),EXV '3 352),EXV 3$ $6L
device networks as part of their overall
'HYLFH 1HWZRUNV :LOO RQWLQXH WR 3OD D .H 5ROH LQ WKH
architecture. ,QGXVWULDO (WKHUQHW (UD

Interestingly enough and as a reversal of the prior Fieldbus landscape, the
process industries will likely end up with a single Ethernet standard – Foun-
dation Fieldbus HSE and its associated H1 non-Ethernet device level
network. The discrete or machine control side of the automation business, on
the other hand, has several competing protocols. Global PLC market leader
Siemens is promoting the PROFInet/PROFIbus combination while Rockwell
Automation and Omron, among others, are moving forward with
EtherNet/IP and its sister CIP-based DeviceNet and ControlNet interfaces.
Long associated with the Modbus TCP technology that is widely adopted in



third party Ethernet products but does not incorporate a true application
layer, Schneider Electric is now positioning itself for the future by allying
itself with the IDA organization. GE Fanuc, on the other hand, has assumed
the same passive “pull” stance evidenced in the device network realm where
they waited to see what the market and their projects demanded.

Many of the industry leaders have pledged support for third party efforts
designed to foster commonality across the competing protocols. EtherNet/IP
and IDA have signed a Memorandum of Understanding to pursue common-
ality through the umbrella IAONA organization, for example, and the
sponsoring organizations for EtherNet/IP, Foundation Fieldbus HSE, and
PROFInet have all lined up behind the OPC DX specification. In the near
term, however, particularly as the fruits of these efforts take shape, single
vendor industrial Ethernet environments will remain the norm.

(WKHU1HW,3 7DNHV ,3 WR D +LJKHU /HYHO

Official EtherNet/IP products first hit the market in the year 2000, but in re-
ality Rockwell had already been shipping like products under the ControlNet
over Ethernet moniker for some time. As this last label implies, EtherNet/IP
represents migration of the upper-level CIP or Control Information Proto-
col common to the ControlNet and DeviceNet networks onto the Ethernet
physical media. As a media-independent protocol, CIP is capable of migrat-
ing to further media such as FireWire or wireless networks.

While EtherNet/IP is positioned as the
9HQGRUVSHFLILF RQILJXUDWLRQ 7RROV information-oriented supervisory inter-
face designed to serve plant floor
8‚€€‚Ã9r‰vpr Q…‚svyr† ÉÃ6ƒƒyvph‡v‚ Piwrp‡†

,3 information to higher-level systems, the
3URWRFRO protocol is designed to accommodate
8‚€€‚ÃHr††htvtÃQ…‚qˆpr…8‚†ˆ€r…

real-time transfer of control messages as
@phƒ†ˆyh‡v‚ well as non time-critical data transfers.
26, 8‚‡…‚yIr‡ 9r‰vprIr‡

/DHUV V9Q U8Q U…h†ƒ‚…‡ÃÃ
9h‡hÃGvxÃGh’r…
U…h†ƒ‚…‡ÃÃ
9h‡hÃGvxÃGh’r… Xv…ryr††Ã This capability is evident in Rockwell’s
DQ
Av…rv…rÃ
r‡p introduction of not only control-level
8‚‡…‚yIr‡ 9r‰vprIr‡
D@@@Ã'!
Qu’†vphyÃGh’r… Qu’†vphyÃGh’r… EtherNet/IP products, such as its new
ControlLogix line of processors, but also
)XWXUH
I/O level products such as Flex I/O and
7KH ,3 3URWRFRO ,V RPPRQ WR WKH (WKHU1HW,3 MicroLogix controllers. The high-
RQWURO1HW DQG 'HYLFH1HW 1HWZRUNV



bandwidth producer/consumer network also lends itself to incorporation of
sensors with high data content. Cognex, for example, recently announced a
family of EtherNet/IP-compatible networkable vision sensors.

EtherNet/IP is able to accommodate both real-time and non time-critical
messages through its encapsulation of both the UDP and TCP protocols.
Critics contend that this approach creates significant protocol overhead, but
it does allow control messages and data transfers to be handled through the
same network interface. Implicit messaging is used for real-time control and
interlocking via UDP, while non time-critical uploads and downloads use
explicit messaging over TCP. All set-up functions and incidental messaging
also employ the TCP protocol. While EtherNet/IP can accommodate real-
time control, applications requiring strict determinism and user-defined
scheduling are steered toward ControlNet.

'HYLFH 3URILOHV DQG 2EMHFW /LEUDU )DOO 8QGHU 2'9$ 6,*
The EtherNet/IP SIG (Special Interest Group) within ODVA, or the Open
DeviceNet Vendor Association, is the keeper of EtherNet/IP-specific objects
and device profiles that go beyond the basic CIP specification. CIP device
profiles contain the object model for the device type in question, along with
object configuration data and the public inter-
faces to that data. Sample control object types
@‡r…ƒ…v†r Ds‚…€h‡v‚P…vr‡rqÃ
include Digital Input Point, Digital Output Point, Tˆƒr…‰v†‚…’ÃD‡r…shpr

etc., which are similar to the objects specified in G
@
Bˆh…h‡rrqÃ
Tˆƒr…‰v†‚…’ 9r‡r…€vv†€Ã
W
other industrial network protocols. Electronic @
G
D‡…v†vpÃThsr‡’
Ã
F Xv…rÃ
Data Sheets (EDS) are used to provide the infor- 8‚‡…‚y S Srƒyhpr€r‡Ã
P 9vht‚†‡vp†

mation necessary to access and alter the X
U
DP @
configurable parameters of a device. At this I

point the specification does not include XML- 9r‰vpr

based EDSs, which would be a logical next step,
I@UXPSFÃAVI8UDPI
but common Internet protocols such as HTTP, 8‚‡…‚y Ds‚…€h‡v‚

FTP, and SNMP are supported in the existing 3RVLWLRQLQJ RI ([LVWLQJ ,3EDVHG 1HWZRUNV
specification.

Along with ODVA, sister group ControlNet International (CI) is a primary
promoter of EtherNet/IP, while the Synergetic-sponsored Industrial Ethernet
Association is also on board. Rockwell Automation, strategic partner Om-
ron, and Cutler-Hammer are the leading players in the DeviceNet camp,
although numerous other suppliers also belong to ODVA and/or CI and of-
fer compatible products. ODVA also signed a memorandum of



understanding with IDA and the IAONA group in late 2000 concerning in-
dustrial Ethernet. This activity will not impact the existing EtherNet/IP
specification but instead is designed to address areas of potential compatibil-
ity that are not currently addressed in the competing protocols.

(WKHU1HW,3 ,QGXVWULDO RQQHFWRU 2IIHUHG WR ,$21$ (,$7,$
EtherNet/IP’s physical layer specification directly states that the use of COTS
Ethernet components may result in unsatisfactory performance in industrial
control applications. A bayonet-style IP 65/67 industrially rated connector,
really an encapsulated RJ 45, is specified instead. The group has offered this
connector to IAONA and EIA/TIA for consideration as a possible common
industrial Ethernet connector.

3XUH3OD ,'$ 7DUJHWV 'LVWULEXWHG :HE
EDVHG $UFKLWHFWXUH ZLWK ,QWHJUDO 6DIHW

IDA, or the Interface for Distributed Automation, is a pure-play industrial
Ethernet specification that promises to marry a real-time, distributed, web-
based automation environment with an integrated safety architecture. As a
pure-play protocol, the IDA industrial Ethernet vision encompasses all levels
of the automation hierarchy, including the device level. This strategy differs
from other competing industrial Ethernet protocols that have an accompany-
ing, non-Ethernet-based, device network component.

The IDA group was formed in the year 2000, soon after forma-
,'$·V PDFKLQH FRQWURORULHQWHG
tion of IAONA. In August of that year the two groups
SXUHSOD LQGXVWULDO (WKHUQHW
announced an intent to merge which was subsequently called
SURWRFRO HPSKDVL]HV D GLVWULEXWHG
ZHEEDVHG DUFKLWHFWXUH ZLWK off. While IAONA opted to pursue evaluation and rationaliza-
LQWHJUDO VDIHW IHDWXUHV tion of existing industrial Ethernet protocols, the original
founders of the IDA group chose to actually develop an indus-
trial Ethernet specification. Like ODVA and its EtherNet/IP SIG, IDA has
since signed a Memorandum of Understanding with IAONA whereby the
groups will work towards defining areas of commonality among the compet-
ing industrial Ethernet protocols.

,'$ 0RGHOHG $IWHU ,( )XQFWLRQ %ORFN 6WDQGDUG
The IDA protocol is based on the architectural elements included in the IEC
61499 Part 1: Architecture draft function block standard, but replaces por-



tions of the IEC model with IDA architecture. Along with support of the full
suite of Ethernet TCP, UDP, and IP-related web services, the IDA protocol
specification to date incorporates RTPS (real-time publish/subscribe) mid-
dleware based on RTI’s NDDS (Network Data Delivery Service), IDA
communication objects, and real-time and safety APIs. Real time applica-
tions are executed on UDP using the RTPS middleware.

(XURSHDQ 0DFKLQH RQWURO 6XSSOLHUV /HDG WKH :D
IDA’s original founders include European suppliers Jetter, Kuka, Phoenix
Contact and Sick. Turck, AG-E, Lenze, Innotec, middleware technology pro-
vider RTI and Schneider Electric have since joined IDA, with late arrival
Schneider as the “big fish” that every group of this nature needs as a mini-
mum requirement for success. For Schneider, IDA offers an easy migration
path to a distributed web-based architecture on the Ethernet network, a ca-
pability their popular Modbus TCP protocol does not provide due to its lack
of true user layer functionality.

Representatives from these companies staff the five working groups cur-
rently formed within the IDA organization: architecture, web, real-time
communication, safety, and marketing. Activities of the architecture commit-
tee are currently focused on infrastructure development in the following
areas: Application Model, Engineering Model, Presentation Model, Process
Model, and HMI model. The web group is defining XML-
based style sheets and data structures for web-based monitor-
ing, visualization (HMI), diagnosis, control, and device
management, as well as input and output. The real-time
group is charged with development of the object model and
device conformance requirements, while the safety group is
working on the definition of protocols and architectural ele-
ments that support architectural safety features. Inclusion of
a safety API in the IDA specification is designed to preclude
the need for a separate machine safety architecture.
7KH ,'$ $UFKLWHFWXUH

IDA issued its first white paper/specification earlier this year detailing the
architecture definition to date and its intended direction. Proponents of the
group point to the architecture’s emphasis on distributed, web-based capa-
bilities and leveraging of the technology already available in today’s
marketplace as the rationale behind development of still another industrial
Ethernet protocol. This is in contrast to non pure-play competing protocols
that continue to employ a hierarchical structure and rely on non-Ethernet



protocols for execution of real-time applications. It does, however, result in
development of still another object library since the group has developed
their own object model and accompanying object library.

The protocol and its supporters lean heavily toward motion control and as-
sociated applications in areas such as robotics, packaging, and machine
control in general, so much of the object library and its associated functional-
ity are expected to likewise emphasize real-time motion applications. The
group states that their goal is not to define device profiles but instead their
associated containers and XML-based interfaces.

,'$ 7KH 352),QHW $OWHUQDWLYH IRU *HUPDQ 0DFKLQH %XLOGHUV
The most likely scenario where manufacturing customers will encounter the
IDA protocol is when buying machinery from European, particularly Ger-
man, OEM machine builders who are not using PROFInet and its associated
networks. When complete, the IDA architecture will allow leading-edge ma-
chine builders to implement distributed, web-based machine control
architectures with integral safety features. Inklings of this were already evi-
dent at this year’s Hannover trade fair where IDA co-founder Kuka
demonstrated IDA-based material handling robots and “Control Web” soft-
ware for cell control applications that utilized the IDA architecture. Phoenix
Contact (Ethernet hubs and switches), Lenze (intelligent standalone drives),
and Bosch (integrated welding stations) all demonstrated supporting prod-
ucts.

352),QHW ,V 127 352),EXV RYHU (WKHUQHW

PROFInet is the industrial Ethernet communications profile from Profibus
International and joins PROFIbus DP, PA, PROFIdrive, PROFIsafe, and other
application and communications profiles in that stable of automation net-
works. Unlike these other profiles, however, the PROFInet specification did
not emerge as the expected PROFIbus protocol ported onto the Ethernet me-
dium. Instead, PROFInet is a non real-time control-level architecture that
bears no resemblance to existing PROFIbus networks. The new protocol lev-
erages commercial Ethernet, Microsoft component technology, and other
commercial elements such as XML. While this marked departure from the
legacy PROFIbus architecture may come as a surprise for some, in reality it



dovetails nicely with the Component- 26,
352),QHW
/DHUV
based Automation strategy currently pur-
sued by primary Profibus supporter
Siemens. Q…‚sviˆ† Q…‚svyr†)ÃÃ 8‚€ƒ‚r‡Ã
V†r…ÃGh’r…
9QÃQ6ÃAHTÃr‡p @tvrr…vtÃH‚qry

PROFInet supporters contend that they 6ƒƒyvph‡v‚ 98PHÃSQ8

are not part of the industrial Ethernet
Ir‡‚…xÃÉÃU…h†ƒ‚…‡ U8QDQÃV9Q

“fieldbus wars” because PROFInet is a
9h‡hÃGvx Q…‚sviˆ† 9h‡hÃGvx @‡ur…r‡
high-level interface designed for peer-to-
Qu’†vphy ST#'$ÃD@8Ã% $'!ÃAvir… @‡ur…r‡
peer or controller-to-HMI connectivity
and is not targeting the device or I/O
352),QHW %HDUV 1R 5HVHPEODQFH WR 352),EXV
level. PROFInet is however the Ethernet-
based portion of an overall automation architecture that invokes the lower-
level PROFIbus networks for real-time activity and is therefore included in
this discussion of industrial Ethernet networks.

7KH 352),QHW $UFKLWHFWXUH
PROFInet is designed to provide an environment that allows machine build-
ers to develop an object-based distributed automation system using standard
PROFInet engineering tools and vendor-specific programming and configu-
ration software. The Ethernet portion of the PROFInet architecture employs
TCP and UDP along with IP, plus the DCOM wire protocol for communica-
tion between automation objects created by the various vendors.

The system developer or machine
builder will use the PROFInet engineer- (QWHUSULVH I‚ÃUv€rÃ
8…v‡vphy
ing model to create COM-based
1(7:25. /(9(/

automation objects out of devices devel- 6XSHUYLVRU Srhy‡v€rÃ
8‚‡…‚y 352),QHW
oped in controller programming
software. The tool will also be used to RQWURO

configure PROFInet-based automation
,2 Xv…rÃ
systems, including those containing 8‚pr‡…h‡‚…

automation objects developed by others.
'HYLFH
Device descriptions developed using
vendor-specific development tools are 1(7:25. )817,21
RQWURO ,QIRUPDWLRQ
given COM interfaces and exported via
XML for use by other developers in their 352),QHW ,V 3RVLWLRQHG DV WKH (WKHUQHWEDVHG 6XSHUYLVRU
RXQWHUSDUW WR WKH 5HDOWLPH 352),EXV DQG $6L 1HWZRUNV
own systems. PROFInet supporters
claim that use of their vendor-independent object and connection editor can
reduce engineering time up to 15 percent relative to traditional methods.



Within the system itself, OLE and Active X are employed for object handling
in the engineering and HMI environments.

Machine builders or other system developers will use the programming or
configuration software that comes with their controllers to create the actual
automation objects and their functionality. For example, in the Siemens envi-
ronment a machine builder would use Step 7 software to create object
functionality specific to their machine and then the PROFInet engineering
tool to turn it into a COM-based object for use in the PROFInet environment.
As this example illustrates, the PROFInet concept hinges on implementation
of the Microsoft-defined object interfaces rather than definition of the actual
library of automation objects.

PROFInet extends its component-based ap-
proach to the device or I/O level by
352),QHW
I‚Ã‡v€rp…v‡vphy incorporating devices on non-Ethernet
automation networks, including real-time
GvxvtQ…‚‘’Ã device networks, via proxy. With this con-
9r‰vpr

cept, each I/O-level device is made into a
COM-based automation object that can be
Srhy‡v€r
RIO recognized and manipulated in the PROFI-
net environment. Ability to incorporate
352),QHW ,QFRUSRUDWHV 352),EXV 'HYLFHV E 3UR[
7XUQLQJ 7KHP LQWR '20 2EMHFWV device networks by proxy is said to extend to
both PROFIbus and non-PROFIbus device
networks alike but to date this capability has not been demonstrated.

$ *OLPSVH DW WKH 6LHPHQV 6WUDWHJ IRU 352),QHW
With the development work on Stage 1 of the PROFInet protocol just com-
pleted, the market will likely have to wait until the end of this year to see the
first compatible products actually shipping. One of the earliest Siemens
products announced by Siemens is their iMAP engineering software. iMAP
marries PROFInet and Siemens’ Component-based Automation strategy and
is a key part of the company’s emphasis on reducing engineering costs for
builders of complex machines and others with similar engineering require-
ments.

Component-based Automation is a subset of the Totally Integrated Automa-
tion strategy announced by Siemens several years ago. Component-based
automation targets system modularization through the use of Microsoft-
based component technology. Execution of this strategy in the machine con-
trol segment is evident as the company goes to market with the PROFInet



architecture, accompanying SIMATIC and other controllers, and now iMAP
engineering tools. Targeted at distributed machine control architectures,
Siemens is positioning iMAP and PROFInet as the vendor-independent envi-
ronment that joins distributed applications into an integrated solution and
enables Component-based Automation.

)RXQGDWLRQ )LHOGEXV +6( ([SDQGV ,WV
+RUL]RQV %HRQG 3URFHVV RQWURO

While Foundation Fieldbus H1 was designed to connect field-level process
instrumentation in harsh or intrinsically safe environments, Foundation
Fieldbus HSE (High Speed Ethernet) was introduced to the market as a con-
trol level backbone. HSE maps the existing 26, )RXQGDWLRQ )RXQGDWLRQ
Foundation Fieldbus H1 protocol to UDP /DHUV )LHOGEXV + )LHOGEXV + +6(

over IP and uses conventional 100BaseTX
Ethernet cable. PID and other field control
AAÃAˆp‡v‚Ã7y‚px†ÃÉÃ AAÃAˆp‡v‚Ã7y‚px†ÃÉÃ
V†r…ÃGh’r…
options are already built into Foundation 9r‰vprÃ9r†p…vƒ‡v‚† 9r‰vprÃ9r†p…vƒ‡v‚†

Fieldbus via the user layer Fieldbus Func- 6ƒƒyvph‡v‚
Avryqiˆ† Hr††htrÃ
Tƒrpvsvph‡v‚
Avryqiˆ† Hr††htrÃ
Tƒrpvsvph‡v‚

tion Blocks that are common to both H1 and Ir‡‚…xÃÉÃU…h†ƒ‚…‡ V9QÃU8QDQ

HSE. Foundation Fieldbus networks are
9h‡hÃGvx Avryqiˆ† 9h‡hÃGvxÃGh’r… D@@@Ã'!Ã@‡ur…r‡
standardized as Type 1 and Type 5, respec-
Qu’†vphy D@8Ã% $' D@@@Ã'!Ã@‡ur…r‡
tively, of the multi-headed IEC 61158 Field-
bus protocol standard. Unlike the H1 )RXQGDWLRQ )LHOGEXV +6( ,PSOHPHQWV WKH 6DPH )XQFWLRQ
%ORFNV 'HYLFH 'HVFULSWLRQV DQG 8SSHU/DHU 3URWRFRO DV
network, HSE is not rated for intrinsically WKH 2ULJLQDO + )LHOG 1HWZRUN
safe operation.

The contrast between the battle to establish the original Foundation Fieldbus
protocol stack and the relative lack of competition for HSE at the control level
is an irony not lost on many fieldbus watchers. The protracted path to speci-
fication of the H1 standard was littered with turf wars involving virtually
every leading member of the process automation supplier community. The
HSE experience is shaping up to be much different, however, with the net-
work emerging as a common Ethernet-based control level network already
included in the new system designs of many process automation suppliers.
Emerson Process Management was among the first to publicly announce
their intentions, but similar announcements are expected shortly. At this
time only HSE Linking Devices from ABB and SMAR have been certified by
the Foundation.



Convergence of the majority of the process control community around the
HSE standard results in process applications drawing largely from a single
technology base while discrete machine control remains a contended field.
Siemens, who serves both process and machine control customers, remains
the primary process automation supplier not in the Foundation Fieldbus
camp as the company continues to market their Profibus architecture, includ-
ing Ethernet-based PROFInet and the field level Profibus PA network.

:LOO +6( %H 8VHG DW WKH )LHOG /HYHO
While HSE is designed mostly for use at the control network layer, some
PAS/DCS suppliers are likely to extend the network into the field for use
with their own I/O multiplexers and smart devices. Like other Ethernet pro-
tocols vying for use at the device level, Foundation Fieldbus HSE will be
used to connect field devices when the environmental, power supply, and
safety requirements of Ethernet are all met at a lower cost than H1. The in-
centive lies in eliminating the need for HSE Linking Devices by eliminating
the two-tier H1/HSE architecture. Substituting an Ethernet switch for each
Linking Device simplifies the network architecture and reduces the end cost.
Ability to use HSE at the field level will also be advantageous on a perform-
ance basis since the network was not designed to have other protocols
running underneath it.

3UREOHP :RUNLQJ *URXS /LNHO 2XWFRPH

RPPHUFLDO (,$7,$ :* $ VSHFLILFDWLRQ IRU D UXJJHGL]HG 5- FRQQHFWRU WKDW
(WKHUQHW PHHWV ,3 DQG LV UDWHG LQ H[FHVV RI J YLEUDWLRQ
FRQQHFWRUV
$ EDUUHOWSH 0

FRQQHFWRU IRU ,3 DQG H[FHVV RI
J YLEUDWLRQ

3RZHU WR ,((( DI 6SHFLILFDWLRQ IRU XS WR 9 : SRZHU GLVWULEXWLRQ
ILHOG GHYLFH 1RW IRU LQWULQVLF VDIHW

,QWULQVLF 1RW DVVLJQHG ,6 VXSSOLHUV ZLOO SURGXFH EDUULHUV IRU +6( ZKHQ UH
VDIHW TXLUHG 3RZHU OLPLWV IRU DI PXVW EH FRQVLGHUHG
2EVWDFOHV ,QKLELWLQJ 8VH RI )RXQGDWLRQ )LHOGEXV +6( DW WKH )LHOG 'HYLFH /HYHO

)OH[LEOH )XQFWLRQ %ORFNV ([SDQG +6(V $SSOLFDWLRQ 6FRSH
Recent additions to the Foundation Fieldbus function block library expand
the scope of potential applications for the network. In September of this year
the Fieldbus Foundation released specifications for fully configurable Flexi-
ble Function Blocks (FFBs) that allow the system developer to specify both
the number and type of I/O parameters plus the algorithm to be configured.
These fully configurable FFBs complement the previously released pre-
configured FFBs, designed largely for use with remote I/O, where the num-


The industrial ethernet protocol wars fieldbus revisited

More Related Content

Similar to The industrial ethernet protocol wars fieldbus revisited

More from ARC Advisory Group

The industrial ethernet protocol wars fieldbus revisited