Networked Automation Systems (NAS) (Bussysteme in der … · 2019-06-05 · AS SoSe 19 Georg...

Automation Systems

Discrete Event Control Systems and

Networked Automation Systems

11th Lecture

Ethernet in Automation

http://www.uni-saarland.de/en/

AS

365SoSe 19 Georg Frey

Outline

• Ethernet in Automation

Extensions to the Ethernet standard

• Fast and GigaBit Ethernet

• Improved Performance

Application Layer functionality of the TCP/IP stack for Automation

APIs

• Simple (Message Transfer)

Example: ModBus

• Higher Level (Object Models …)

Replacement of TCP/IP for real-time communication (still with Ethernet at the lowest

layer)

• Industrial Ethernet Solutions

General Approaches

Examples

Comparison


AS



• Extensions to the Ethernet standard Fast and GigaBit Ethernet

Improved performance:

• Predictable Ethernet

• Switched Ethernet

• Synchronization

• Application Layer functionality of the TCP/IP stack for Automation APIs Simple (Message Transfer):

• Modbus TCP/IP (Schneider, publicly available documentation, IEEE standard)

Higher Level (Object Models …)

• Ethernet IP, EIP (Rockwell, documentation available for members of OVDA fees )

• ProfiNet (Siemens, documentation available for members of Profibus International (PI) fees)

many others (Foundation Fieldbus FF, Ethernet PowerLine EPL, …)

• Replacement of TCP/IP for real-time communication (still with Ethernet at the lowest layer) Extensions to ProfiNet, EtherNet/IP special ASICs needed expensive


AS


Extensions to the Ethernet Standard

• Standard Ethernet (10 MBit/s) supports only half-duplex mode

• Fast-Ethernet (100 MBit/s) supports FDX on a direct link

Send and Receive units are physically and logically separated

Medium has to allow FDX

Theoretically 200 MBit/s possible

No collisions CSMA/CD could be deactivated

compatible to Standard Ethernet (no differences on higher layers)

Allows Autonegotiation: two stations exchange control frames to determine speed,

FDX, Flow Control

Allows Flow-Control: A station can request a sender to pause transmission for a

specified time (a switch could react to buffer overflow)

Allows Trunking (several physical channels between two stations (higher capacity,

redundancy)

• Gigabit-Ethernet (1000 MBit/s) normally only used in FDX

Problems in half-duplex because of very short collision window (0.51 µs resulting in

10 to 20 m of max distance) extensions at medium access are necessary (carrier

extension min 512 Bytes to give 4.1 µs)

• 10 GBit/s Ethernet

Only FDX


AS


Predictable Ethernet

• Probability of Collisions and queuing decreases dramatically at a

network load below 20%

Very simple Approach

No guarantees

Low usage of medium

need for segmentation


AS


Fully Switched Ethernet

• Only Point-to-Point Connections of devices to switches and switches to

higher-level-switches

Concurrent (nebenläufige) Communication on different segments

Full-Duplex

No Collissions

Expensive

Switching needs time

Wiring (back to the future!)


AS


Measurements on Switched Ethernet

• Measurements at a real

system show that in a

switched network the network

load can be increased even

further without influence on

the control traffic.

• In the experiment below a

link-load of 90% was

acceptable!!

• Switch load had no influence

at all

Influence area of the

link load generator

RIOMs

switches

controllers

input event output event

area of control function #2

area of control function #1

PLC 1 PLC 2

R1 R2 R3 R5R4 R6 R7 R8 R9

SW1SW2

SW3


AS


Synchronization with Timestamps

• Messages get a timestamp

• Allows constant delay (no jitter) however: Delay for buffering is larger

than mean of delays before

• Allows to react on delay (or even preventive action)

• Synchronization of local clocks is necessary: IEEE 1588

• Real-Time Application on standard Ethernet TCP/IP possible

No restrictions on additional TCP/IP traffic

Each device needs a clock

Two ways of using the clock-information

Programming should take time-stamp into account (new paradigm)

• Start to accelerate motor at time x for n ms

Constant Delay based on buffering

• may be too long for control applications (0.5s)


AS


Modbus Protocols

• Modbus itself is an application layer protocol independent of the

underlying physical layer

• Communication is based on client/server mechanisms

• public-domain protocol that requires a license, but does not require

royalty payment to its owner


AS


Modbus

• Developed in 1979 by Modicon for industrial automation systems and Modicon

PLCs.

• Today an industry standard method for the transfer of discrete/ analogue I/O

information and register data between industrial control and monitoring devices.

• Modbus devices communicate using a master-slave (client-server) technique.

• Devices may function as both, clients (masters) and servers (slaves).

• A master’s query consists of a slave address (or broadcast address), a function

code defining the requested action, any required data, and an error checking

field.

• A slave’s response consists of fields confirming the action taken, any data to be

returned, and an error checking field.

• If an error occurs in the query received, or if the slave is unable to perform the

action requested, the slave will return an exception message.

• The error check field of the slave’s message frame allows the master to confirm

that the contents of the message are valid.

• Traditional Modbus messages are transmitted serially with parity check.


AS


Modbus Transactions


AS


Modbus Data Model

• The Modbus application protocol defines precisely PDU addressing

rules. In a Modbus PDU each data is addressed from 0 to 65535.

• It also defines clearly a MODBUS data model composed of 4 blocks

that comprises several elements numbered from 1 to n.

• Modbus functions operate on memory registers to configure, monitor,

and control device I/O:

Discrete Input Start at 00001

Coils (Discrete Output) Start at 10001

Input Registers (Analogue Input) Start at 20001

Output Registers (Analog Output) Start at 30001


AS


Modbus Address Mapping

• The mapping of the Modbus addresses to the real Memory addresses

of the device depends on the device application:

Mapping into different memory spaces

Mapping of several Modbus addresses onto the same memory address (allows to

access the same data in single bits and 16bit words)


AS


Modbus: Some Common Function Codes


AS


Example: Function 01 Read Coil


AS


Modbus TCP/IP (also Modbus-TCP)

• Modbus TCP/IP basically embeds a Modbus frame into a TCP frame in

a simple manner.

• Connection-oriented transaction which means every query expects a

response.

• The Modbus commands and user data are themselves encapsulated

into the data container of a TCP/IP telegram without being modified in

any way.

• The Modbus error checking field (checksum) is not used, as the

standard Ethernet TCP/IP link layer checksum methods are instead

used to guaranty data integrity.

• The Modbus frame address field is supplanted by the unit identifier in

Modbus TCP/IP, and becomes part of the Modbus Application Protocol

(MBAP)

• Modbus TCP/IP clients and servers listen and receive Modbus data via

TCP port 502.


AS


Modbus TCP Packet


AS


Modbus Application Protocol Header MBAP

• Transaction Identifier - It is used for transaction pairing, the MODBUS server copies in the response the transaction identifier of the request.

• Protocol Identifier – It is used for intra-system multiplexing. The MODBUS protocol is identified by the value 0.

• Length - The length field is a byte count of the following fields, including the Unit Identifier and data fields.

• Unit Identifier – used for intra-system routing purpose. It is typically used to communicate to a MODBUS or a MODBUS+ serial line slave through a gateway between an Ethernet TCP-IP network and a MODBUS serial line.


AS


Protocol-Overhead in Modbus TCP/IP

• Protocol-Overhead = 14 + 4 + 20 + 20 + 7 = 65 Bytes

• PDU Varies but typically less than 10 Bytes !!!


AS


Combination of Modbus Networks


AS


Industrial Ethernet Solutions

Industrial Ethernet Solutions

General Approaches

Examples

Comparison


AS


Example 1: EtherNet/IP

• Ethernet Industrial Protocol

• EtherNet/IP, ControlNet und DeviceNet use the same application

protocol (Control & Information Protocol)

• Main supporter: Rockwell Automation USA

• ODVA (Open DeviceNet Vendor Association) is the user organization

for EtherNet/IP (following: a part of the bylaws)

ODVA MEMBERSHIP

Special Privileges of Regular Membership

Upon becoming a member and signing the appropriate Terms of Usage Agreement,

regular members of ODVA receive the following extra privileges and benefits.

• A one-time, paid-in-full Vendor ID for either DeviceNet or EtherNet/IP (a $500

value).

• One paid-in-full annual subscription to either the DeviceNet or the EtherNet/IP

Specification (a $350 value).

• MEMBERSHIP DUES $5000 for REGULAR MEMBERS


AS


Example 2: ProfiNet

• Builds on Profibus (Siemens)

• Main supporter: Siemens

• PI (Profibus International) is the user organization Membership fees depend on size of company up to 15.000 €

• According to some surveys the standard with good chances to become

the most widely accepted (in Europe anyway)


AS


Two Common Statements on Industrial Ethernet

• Statement 1: “Ethernet could serve as the harmonization force behind

reducing the number of available standards for field networks”

(ARC Research, 1999)

• Statement 2: “Since it is so widely used, it must be cheap”

Is this true?


AS


Recall: Ethernet

• People don’t think about Ethernet as only the standard for the lowest

layers of the ISO/OSI-model that it actually is

• We all consider

protocols and

application

TCP , UDP

IP

HTTP , FTP , SNMP , … .

Media Independent Interface MII

Physical

Media Access MAC

Logical Link Layer

PHY

MAC

Application

Presentation

Session

Transport

Network

Data Link

Physical

7

6

5

4

3

2

1802.3


AS


Industrial Ethernet Hardware

• Industrial Ethernet follows the same constructs as the commercial

Ethernet used for interoffice communication, and it uses the same OSI

model. However the two differ in the robustness of the equipment used:

• “More hostile environment”

freefall

vibration

EMI/RFI ratings

extended temperature range

other hazardous environmental conditions

• At the same time “higher demands”

dependability

need to prove properties (certification)

• Even with the same basic function devices differ and are in general

more expensive

• You should not buy a switch at your preferred discounter and install it in

a factory floor network!


AS


Example: Industrial Ethernet Switch

• 304TX Industrial Ethernet Switch N-TRON

• Four 10/100BaseTX RJ-45 Ports

• Class 1, Div 2 Hazardous Location

Certification

• Rugged Industrial DIN-RAIL Enclosure

• Extended Environmental Specifications

-20ºC to 70ºC Operating Temperature

• D-LINK DSS-5+

• Five Ports

$179

$16


AS


General Structure of Industrial Ethernet Stack

100baseTX

802.3

Ethernet ControllerASIC

IP

TCP

HTTP

SNMP

DHCP

……..

….

..Standard data Real-Time data

Industrial Ethernet Application


AS


Problems of Standard Ethernet

• To replace fieldbuses, right down to field device level, Ethernet must

fulfill more requirements:

Transmit process data deterministically

Synchronize clock precisely

Fit plant topology

• Standard Ethernet is intrinsically non-deterministic due to the

CSMA/CD collision-based multiple access of Data Link Layer. To

overcome this, some proprietary mechanisms were developed, as:

Scheduling network update cycle into discrete transition time slots.

Use of proprietary gateways that tunnel non-real time packets in special Ethernet /

UDP port format.

Use of proprietary Media Access.

Special polling schemes


AS


Major Ethernet based automation networks

• Modbus TCP (www.modbus.org)

• PROFInet (www.profibus.com)

• Ethernet/IP (www.odva.org)

• PowerLink (www.ethernet-powerlink.org)

• EtherCat (www.ethercat.org)

• SynqNet (www.synqnet.org)

• SERCOS III (www.igs.org)

• SafetyNET p (http://www.safetybus.de)


http://www.safetybus.de/

AS


Example SafetyNET p

• SafetyNET p was developed as a deterministic real-time Ethernet for

the industrial environment. Established technology from the

SafetyBUS p safe bus system was also considered and refined.

• In order to meet the various requirements, SafetyNET p supports two

types of communication.

The SafetyNET p RTFL format is optimised for extremely fast communication in

highly dynamic applications.

The RTFN format also provides the ability to communicate via any Ethernet network.

Both versions are compatible with each other and may be used separately or in

combination.


AS


SafetyNET p in the Protocol-Stack


AS


Features of SafetyNET p

• Each Ethernet device can be connected to a SafetyNET p network.

• All Ethernet utilities based on the IP protocol can be used.

• The basic topology in RTFL is a linear structure (existing evolved structures

within industry can continue to be used).

• Branches can be created through the use of switches, enabling the formation of

tree or star structures.

• The security protocol is integrated right from the start (as a software driver).

• The publisher/subscriber principle enables direct communication from

subscriber to subscriber, without the need for a centralised PLC.

• The network structure is identified during operation. This enables mobile

devices to be connected and varying configurations, as required for tool

change.

• Existing fieldbus installations can be incorporated by using proxies.

• Devices with real-time capability (scan times of up to 62.5) can be incorporated

by using special SafetyNET p RTFL protocol chips.

• Applications with scan times > 1 ms can communicate with standard Ethernet

interfaces via SafetyNET p RTFN.


AS


Comparison of major Approaches

ModBus TCP PROFInet PROFInet IRT Ethernet/IP Ethernet/IP v2 PowerLink EtherCat SynqNet SERCOS III

Standard Ethernet Model

yes yes

no separate

normal and IRT traffic

yes yes no

Master/Slave scheduled

no Master/Slave

no Master/Slave

scheduled

no Master/Slave

scheduled

Standard Ethernet Hardware

yes yes no

ERTEC ASIC yes yes yes

no FMMU ASIC

No FPGA

No ASIC

TCP IP / UDP support

yes yes Gateway required

yes yes Gateway required

Gateway required

no Gateway required

Timing Model / Synchronization

none none

Proprietary Isochronous

Channel / IEEE-1588

none IEEE-1588

Proprietary Mixed

Polling/Time slicing

Proprietary Proprietary

Synchronous Cyclic

Proprietary Cyclic

Real Time Performance Cycle / Jitter

n.a.

100ms (TCP/IP)

10ms (SRT) jitter: 1ms

(SRT)

0,25 .. 1,0 ms jitter: 1μs

n . a .

1 m s

j i t t e r : 2 0 0 n s

(100 axes)

0,2 .. 1,0 ms jitter: 1μs

(100 axes)

Min 0,1ms jitter: 1μs

(100 axes)

Min 0,01ms jitter: 1μs

M i n 0 , 0 3 m s

j i t t e r : 1 μ s

Topology Star Star, Tree,

Line Line, Ring Star, Tree Star, Tree Star, Tree

Star, Tree, Line

Line, Ring Line, Ring

RTOS required no no no yes yes yes no no no

Device Profile none Profi Profi CIP CIP CANopen CANopen,

Sercos None API

Sercos

Application Focus

Modbus messaging on

TCP/IP

Industrial Ethernet fieldbus.

Industrial Ethernet

fieldbus with motion.

Industrial Ethernet fieldbus.

Industrial Ethernet


Specialized motion bus

with field I/O extension.

Industrial Ethernet


Specialized motion bus.

Specialized motion bus

with field I/O extension.

• A good overview can be found at: http://www.echtzeit-ethernet.de/


AS


Chances for Industrial Ethernet for Communication at Lowest Lewels

• Industrial Ethernet solution appear suitable for:

Dedicated Motion bus (more performance, less standard Ethernet approach)

(PowerLink, Ethercat, SynqNet, PROFInet IRT, Ethernet/IP CIP Sync,

SERCOS III)

PLC/Machine intercommunication, HMI, TCP/IP application integration (ModBus

TCP, PROFInet CBA, Ethernet/IP)

• Replacing fieldbus is still difficult for Industrial Ethernet :

High protocol overhead for small I/O field devices (min 802.3 packet is 64bytes) that

can waste the bandwidth.

Fair performance with TCP/IP stack.

Standard star topology (higher cable length than in bus topology).

Overall costs greater than low cost fieldbus (CANopen devices).

• However, new technologies favor the position of Ethernet

Power over Ethernet reduces cabling

Seamless integration of wireless segments

• Finally: The decision for Ethernet is not only a technical one

Weak Reason: “it is more modern”

Strong Reason: Total Cost of Ownership (Harmonization of all networks in a

company reduces cost for maintenance, engineering, training, …)


AS


Back to the Initial Statements

• Statement 1: “Ethernet could serve as the harmonization force behind

reducing the number of available standards for field networks” (ARC Research,

1999)

• Not true at the moment. Actually the number of solutions has increased.

Different Industrial Ethernets are interoperable in the sense that they can share

the same medium but they are not compatible i.e. can not exchange

information.

• Harmonization was moved to the next higher Level

with OPC DX and OPC UA currently a standard for a higher level network access (objects and

data model) is built

support from different of the Industrial Ethernet Groups

aim is not to replace the existing solutions but to group them under a common scheme

allows to build a system of several Industrial Ethernets with common Engineering and

Management

aims not at the lower levels

• Statement 2: “Since it is so widely used, it must be cheap”

• Depends on Viewpoint

Components are more expensive than in some standard fieldbuses

Total Cost of Ownership may be less (hard to assess, too early to give definite answers)


AS


OPC

• Historically: OPC = OLE for Process Control

Use of Microsoft Technology (OLE, COM, DCOM) to allow PCs to communicate with

Process Hardware

At least since OPC DX (Data Exchange) and OPC XML DA new orientation towards

XML and Web-Services

Provides an Architectural Framework for Communication in Automation on a high

abstract level

Client-Server-Architecture

• Device (e.g. PLC) should provide an OPC server

• Other devices (SCADA) can request information

Works as Software-Gateway between several systems (especially useful to integrate

several Ethernet based solutions)

Not intended to replace the existing solutions but to integrate them

Not intended for control tasks on lower levels (real-time)

• Now: OPC = “Open Platform Communications”

• OPC DA: Data Access

• OPC AE: Alarm and Events

• OPC DX: Data Exchange OPC UA (Unified Architecture)


AS


Outlook

• Ethernet technology will be the standard industrial communication

system

Definitively on higher levels of the automation pyramid

Good chances to include also lower levels

• OPC is a promising candidate to harmonize industrial communication

via Ethernet on a high abstract level

Main Idea: Client-Server-Architecture to share data

Not Included: Control

• On lower levels

Different proprietary solutions

OPC not directly applicable

For the implementation of controllers IEC 61131 not directly applicable

Abstract model and new standards to implement distributed controllers needed

IEC 61499 as a way for programming in distributed systems


AS


Summary (11th Lecture)

This lecture gave an introduction to



Extensions to Ethernet TCP/IP

Modbus and Modbus TCP/IP

Examples of Industrial Ethernet Solutions


Date post:	17-Mar-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Networked Automation Systems (NAS) (Bussysteme in der … · 2019-06-05 · AS SoSe 19 Georg...

Documents