02-safeethernet 12 e f

8/16/2019 02-Safeethernet 12 e F

1/67

HIMA Training SILworX safeethernet

02-Safeethernet_12_e_F.docx SILworX Page 1/67© by HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.

Contents:

1 General ............................................................................................ 3

2 Principle, initial situation as example ............................................ 3

3 Interface settings (Hardware editor) .............................................. 4

4 Safeethernet Variables ................................................................... 6

4.1

Create Safeethernet variables .............................................................................. 6

5 Communication settings (safeethernet editor) ............................. 7

5.1 Create links, assign interfaces ............................................................................. 7 5.1.1 Multiple links (new with V6) ........................................................................................... 8

5.2

Set link properties ................................................................................................. 9 5.2.1 Basic link properties ...................................................................................................... 9

5.2.2 Advanced link properties (since SILworX V6) ........................................................... 11

5.3 Assign variables to communication .................................................................. 12

5.4 Check (or set) fragment definitions (optional) .................................................. 13

6 Diagnosis ....................................................................................... 14

6.1

Safeethernet diagnostic block (in logic) (System Variables) ........................... 14

6.2

Basic check safeethernet communication ........................................................ 16

6.3 Check for sporadic or historical errors ............................................................. 18

6.4 Check transmitted data ....................................................................................... 19

6.5

Check safeethernet signatures .......................................................................... 20

7 Safeethernet Reload ..................................................................... 21

7.1 Basics .................................................................................................................. 21 7.1.1

Precondition.................................................................................................................. 21

7.1.2 Update existing link (


2/67


Page 2/67 SILworX 02-Safeethernet_12_e_F.docx© by HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.


3/67



1 GeneralThis document was created with SILworX Version 6.48.In case you have SILworX version 5 or lower use the step guidance version 05-1.To be able to use all new possible functions (multible links, reload) the hardware need an operation system whichsupports all functions of SILworX V6.

SILworX Version V6

M i n i m a l n e e d e d O S v e r s i o n

HIMax CPU andCOM

6.x

Remote I/O CPU -

HIMatrixF* 01/02

CPU -

COM -

HIMatrixF* 03

CPU 10.x

COM 15.x

HIMatrix

M45

CPU 10.x

COM 15.x

Table 1.1: Needed operating system

2 Principle, initial situation as example

For general information and hints about possible network structures please read thecommunication manual.

In this manual we show the setup for a redundant communication between two HIMaxresources.

In our example the “Local Resource” is called “PES10”, the “Target Resource” is called“PES20”

PES10 has System ID = 10PES20 has System ID = 20

Standard settings are finished (see First Step Manual)

Fig 2.1


4/67



3 Interface settings (Hardware editor)

Recommendation for IP addresses:By principle every IP address is possible.In order to meet a simple and understandable addressing principle and to avoid networkproblems we recommend as follows:

- For redundant networks use different network addresses in module within a system,determined by an according Subnet mask.

- Use the System ID as Host address for easy orientation

Example:Subnet Mask: 255.255.255.0 for both CPU’s

PES10 (System ID=10 ), CPU on slot 3: IP address = 192.168.1.10 PES10 (System ID=10 ), CPU on slot 4: IP address = 192.168.2.10

So 1 and 2 identifies the two redundant networks, the last number 10 (Host address) isidentical to the System ID.

Open Hardware Editor of PES10:

Fig 3.1: Hardware overview


5/67



Set IP address of CPU’s: The parameter Code generation must be in accordance to the loaded operating system inthe hardware.

Fig 3.2: Interface setting for CPU in slot 3

Fig 3.3: Interface settings for CPU in slot 4

Set IP addresses of PES20 accordingly:

PES20 (System ID=20 ), CPU on slot 3: IP address = 192.168.1.20 PES20 (System ID=20 ), CPU on slot 4: IP address = 192.168.2.20


6/67



4 Safeethernet Variables

4.1 Create Safeethernet variables

Safeethernet variables must be created on a common level. In our case it is theconfiguration, but it could be also the project level!

Any data type is possible, even arrays or structured variables.

Fig 4.1: Variable defenition


7/67



5 Communication settings (safeethernet editor)Edit “safeethernet” in the Resource. (Doesn’t matter where you start, the settings in the partner Resource are automaticallymatched)

5.1 Create links, assign interfaces

Drag the partner Resource into the upper table in order to create a communication linkbetween this Resource and the partner Resource.

Fig 5.1: Create a safeethernet link

Enter a name for the link:

Fig 5.2: naming a link

Result:

Fig 5.3: Interface overview

LeftCPU

Right CPUlocal

LeftCPU

Right CPUtarget


8/67



Check the IP addresses and set properly if required.Therefore select the available IP addresses out of the drop down menu.The IP addresses of the PES are set in the Hardware editor as a property of CPU and COMmodules. See chapter 3 .

Fig 5.4: Eventual disconnection of the second line of a link

If no redundancy existing set “None” for the second channel.

5.1.1 Multiple links (new with V6)

The transport capacity per link and direction is limited to 1100 Byte.Please note: 1 Bool = 1 Byte

1 Word = 2 Byte1 Real = 4 Byte

Drag the same communication partner again into the table in order to create another link:

Fig 5.5: Creating a second link to the same communication partner

Result:

Fig 5.6: Link list


9/67



5.2 Set link properties

5.2.1 Basic link properties

For every link you can set several parameters in order to adjust the link properties with

respect to the physical environment and expected time behavior.

For details refer to the communication manual.

Fig 5.7: Linkparameters

Recommendations for the most important settings:

Profile: Fast&Noisy (switched network, 100/1000Mbit), matches 98% of cases!

Receive Timeout (Rcv TMO) ≥ 4 x Delay 5 x max. cycle time

Delay: Delay on the transmission path, e.g. due to switches or satellite.

For the calculation of max. cycle time we’ve two options:

In the most conservative calculation the max. cycle time = the greater Watchdog timeof both communication partners

(example: PES10 with Watchdog = 100ms, PES20 with Watchdog = 200ms, no relevantdelays,=> Receive Timeout = 5 x 200ms = 1000ms)

or optimized since version 3 (Silworx and Firmware):

Set in the properties of the Resource a value for “Target Cycle Time” and the “TargetCycle Time” to “dynamic-tolerant” or (if periodic behavior is needed) “fixed-tolerant”. Thismeans only during Reload or synchronization of a CPU the HIMax does exceed the setTarget Cycle Time eventually only one time. Normally the cycle time remains less theTarget Cycle Time.Watch the cycle time statistic for some time. If the indicated “Maximum” is quite stable

you can use the “Target Cycle Time” value for calculating the max. Cycle Time in theformula.This normally allows using smaller values then the Watchdog Time, anyway you shouldset the “Target Cycle Time” to be sufficient for synchronizing a CPU (see Safety Manual).


10/67



Response Time (Rsp t) ≤ Receive Timeout/2

Behavior on Connection Loss

Fig 5.8: Behavior on connection lost

For safety related links the setting must be “Use Initial Value” or a calculated time. This parameter is relevant for safety! Please see also the “Safety Manual”

Rest of parameters is automatically calculated based on the selected Profile.

For a better understanding see also chapter 8.1

Please note:A Receive Timeout of (e.g.) 5 seconds means also after disconnect it takes up to 5seconds to reestablish the communication!

Code GenerationThis parameter is new with version 6 and appears at the very right end of the table:The default value might not match to the system. So it is needed to check this parameter.

Fig 5.9: Codegeneration parameter

For in V6 newly generated links the (default) value is automatically set to „V6 and higher“. This setting is basically a preparation for safeethernet Reload and should only be set ifthe communication partners support the new features (firmware compatible to ≥ V6, seetable Table 1.1 needed operating system).

For converted (old) projects the parameter is set to “Up to V6”

Fig 5.10: Codegeneration parameter

Do not change unless both communication partners are updated to a firmwarecompatible to SILworX ≥ V6!


11/67



5.2.2 Advanced link properties (since SILworX V6)

Safeethernet link ID – safeethernet address

Fig 5.11: Link ID

The link ID is generated automatically but can be modified also.

The ID is part of the safeethernet address, for example used in online displays ormessages:

Example: Control Panel

1 Target System ID2 Rack ID (e.g. for RIOs)3 Link ID

Fig 5.12: Multible link list

Timing Master

Fig 5.13: Timing master

As default the partner with the lower System ID is set as “Timing Master”. If modifying time settings only this partner must be reloaded, the other partner (called:Timing Slave) automatically accepts the new time settings.


12/67



5.3 Assign variables to communication

Edit “safeethernet” in one of the communication partners.

Click “Edit” in the context menu of the link or double-click the line number:

or

Fig 5.14: Open the link editor

Hint:

If not working and the message following appears in the logbook, safe the safeethernet editorand try again!

Fig 5.15: Error message

Assign the variables from the lower list into the upper lists. Regard the communicationdirection!(Multi selection of variables is possible!)

Fig 5.16: Assignment of the communication variables

Variables of various data types can be mixed and get automatically addresses according acertain principle. The internal addresses are not important for the user and therefore

invisible.


13/67



5.4 Check (or set) fragment definitions (optional)

Default: One fragment with priority 1. Recommendation: Keep default!

Priority 1 means, the telegram is transmitted each cycle, what is normal!

Only change the value if the frequency must be reduced, e.g. if facing load problems.Consider the consequences: Slower update rate, impact on timing parameters etc.


14/67


15/67



Fig 6.3: Diagnose function block

The most important information is the status of redundancy. You can transmit any diagnosisinformation into a target scada or DCS system.


16/67



6.2 Basic check safeethernet communication

For details please see the communication manual. In chapter “safeethernet” you find themeaning of all diagnostic data and also hints how to check a safeethernet communication

Check the status of safeethernet links in the Control Panel.In example we see 4 links, including OPC Server.

Fig 6.4: Ckecking the connection state

Check “State”, must be “Connected”.

Check timing and enhanced link information:

First reset the safeethernet statistic. Right mouse click to the word “safeethernet” in the CP:

Fig 6.5: Resetting the safeethernet statistic

Select a link in order to see detailed link information:

Fig 6.6: Checking the link individual datas

Check Rsp t (Response Time) statistic and compare it to the set values for “ReceiveTimeout” and “Resend Timeout”. See chapter 5.2 set link properties and 8.1 in the appendix

Check Errors, Rsnd (Resends), Succeeded (No. of Reconnections) and Early (Queue

Usage), if communication is working well these counters should not count up and normallyafter a reset of statistic remain on zero.


17/67



Check (if existing) the redundant channels:

Both channels are used in parallel and transmitting the same telegrams. Of course alwaysone of them is the first. This fact and even the time delays between are visible in thediagnostic.

Fig 6.7: Channel quality

Coding of the quality (Extraction of communication, manual chapter safeethernet)

Fig 6.8: Bitmeanibgs of the channel quality

The normal indication is 15 or 7, randomly changing between the channels.15 means: Bit 0, 1, 2 and 3 are set channel connected and providing the first messages.7 means: Bit 0, 1 and 2 are set channel connected but not the first.

Example for an error, channel 2 is not working:

Fig 6.9: Not connected second channel

Check “Channel state” and delays:

Fig 6.10: Channel state

Fig 6.11: Bitmeanibgs of the channel state

In example Channel 1 is OK, the redundant Channel (2) is not OK!


18/67



6.3 Check for sporadic or historical errors

First reset in CP the system error statistics:

Fig 6.12: Resetting the error and warning statistic

Check counter “Communication Errors”:

Fig 6.13: Checking the communication errors

Check counter “Communication Warnings”

Fig 6.14: Checking the communication warnings


19/67



Safeethernet can be performed by the CPU or COM modules.Check the diagnostic buffer of both redundant modules, used in reality for safeethernet (seethe settings in the safeethernet editor, chapter 5.1.

1 HH network stands for HIMA-HIMA network, another word for safeethernet2 Node-id= System_ID-Rack_ID-Link_ID of the communication partner3 MAC-Address of the communication partner

4 IP-Address of the communication partner

Fig 6.15: Checking the module diagnose of a CPU or COM module

6.4 Check transmitted data

Start Force Editor and check the Global Variables (Global forcing):

In Register “Inputs” you find the safeethernet data, which this PES receives from a certaincommunication partner:

Fig 6.16: Checking the transmitted data in the Force Editor tab Inputs


20/67



6.5 Check safeethernet signatures

Check and compare the “safeethernet signatures” in the CP’s. There must be always a matching couple of signatures.For detailed explanation see chapter 7.1.3

If no matching signatures found the link is down and safeethernet is not working at all!

Remedy:Start Code generation for both communication partners and load both PES.Use safeethernet Reload, if possible. See chapter 7

:

Fig 6.17: checking the signatures of all links between the two partners


21/67



7 Safeethernet Reload

7.1 Basics

7.1.1 Precondition

The precondition for loading a new or changed safeethernet link by reload is to have an

operating system compatible to SILworX V6 or higher.See therefor the Table 1.1 Needed operating systemHow to load an operating system is described in following documents or the system manuals:HIMax DiagnosticHIMatrix Specials

7.1.2 Update existing link (


22/67



HW Editor::

CPU properties: Code Generation “Up to V6” “V6 and higher” This parameter does not exist in a module which is new in version 6 or higher.

Fig 7.2: Changing the safeethernet reload property in the CPU

COM properties: Code Generation “Up to V6” “V6 and higher”

Fig 7.3: Changing the safeethernet reload property in the COM

Background: The setting is related to the new feature: “Timing Master ”.The setting “Timing Master” allows to change time settings (e.g. receive timeout) only

at the “Timing Master ” Resource. The “Timing Slave” Resource accepts the new timesettings without another Reload. If “Code Generation” is set to “V6 and higher” theCode Version of Resource “Timing Slave” does not change after next CodeGeneration.

In older versions the setting “Receive Timeout” was also used for the timeout of HHping command. With the setting “V6 and higher” the timeout for HH ping has a fixedvalue.Now the CPU or COM does not block the Reload if “Receive Timeout” is changed.The HH ping timeout is now set fix on 2 seconds.

Note:

Depending on existing settings this change sometimes requires a Cold Reloadof the COM module.

4. Generate the Code with reload option for both partners

During Code Generation appropriate messages appear:

Fig 7.4: Code Generation Messages

5. Reload both partners. Don’t do a download if you have a reload code in this situation.6. Repeat the points 4 and 5 a second time.

See update procedure next page.


23/67



Update procedure from link property “up to V6” to “V6 and higher” (see also chapter 7.3)

Editor Partner A Partner B Reaction

Action SIG N SIG N+1 Action SIG N SIG N+1

- - E2


24/67



Information in Version Comparison if changing from “up to V5” to “V6 and higher”

Example configuration (PES_10, System-ID 10):- CPU in Rack 0 Slot 3- CPU in Rack 0 Slot 4

- COM in Rack 0 Slot 5- Safeethernet link from PES_10 to OPC Server-A (System-ID 101)- Safeethernet link from PES_10 to OPC Server-B (System-ID 102)- Safeethernet link from PES_10 to PES_20 (System-ID 20)-

Suppose all above mentioned preparations had been carried out and now we compare theold configuration (“up to V5”) with the new configuration (“V6 and higher”).

In CPU and COM the hh.config file is indicated because the property “Code Generation” haschanged to “V6 and higher”

Ke.config shows the newly generated System Variable “Versions-Zustand”. That’s normal if the link property has changed to “V6 and higher”. No further meaning.

Safety AdviceKe.config must not show any further indications, such as “changedoffsets” for safeethernet variables.Otherwise contact HIMA support!


25/67



cpcsip.config:

Configuration File Version changes automatically when “Extended Configuration” haschanged to “On”, what means the link property “V6 and higher ”.

Since Version 6 the new feature “Timing Master ” exists (see above, same chapter).If the link property “V6 and higher ” is set, SILworX selects one of the two communicationpartners as a “Timing-Master ”. The other partner is getting “Timing-Slave”.The selection is random from a user point of view!

In example the “Timing-Master ” was selected on “OPC-Server-A”, on “OPC-Server-B” and on“PES_10”. Point of view is “PES_10”:

For the “Timing-Slave” (that’s where the “Remote Partner ” is “Timing-Master ”) all relevanttime settings are set to maximum value, what means deactivated, because the really activetime settings are now only set by “Timing-Master ”.


26/67



For the “Timing-Master ” “Max.Receive Timeout” and “Max. Resend Timeout” change tomaximum value. These parameters are normally invisible for the user.The change is due to system internal reasons and not relevant.


27/67



7.1.3 Safeethernet signature (SE signature) and Dual Configuration

Safeethernet is a safety communication in SIL3 quality.One of the safety features is the safeethernet signature (SE signature).

Actually the SE signature is a CRC code, describing e.g. the data layout of transmitted data.The SE signatures are created during the Code Generation and get part of the loaded(Reload or Download) configuration.

Safeethernet communication between two communication partners is only working if bothpartners have identical SE signatures.In example below we assume there’s only one SE signature existing (SILworX V2 – V5)

Imagine a safeethernet modification and Download of Partner A:

Please note:Invalid, not working link, means all transmitted variables are reset to initial values.Consider the consequences for the process.

The challenge:In order to achieve above mentioned conditions we must reach identical SE signatures withinboth partners after carrying out a safeethernet modification.We, as human, can execute the Reload only one by one!Consequently for the meantime between loading both partners the system must be able todeal with two different SE signatures.

As long the two partners find an identical SE signature the link remains valid.It’s the challenge to ensure this condition all the way during the safeethernet Reloadprocedure!

Link valid - workingPartner A:

SE signature: E2 Partner B:

SE signature: E2

Link invalid – not workingPartner A:

SE signature: E3 Partner B:

SE signature: E2


28/67



The solution (SILworX V6):

After safeethernet modification and Reload of Partner A:

Partner A Link status Partner B

SE Signature N E2 Link still active on E2 E2

SE Signature N+1 E3 E2

After Reload of Partner B:

Partner A Link status Partner B

SE Signature N E2 E2

SE Signature N+1 E3 Link now active on E3 E3

Table 7.2:

Both partners have now a Dual Configuration

Basic rules generating safeethernet signatures:

Several CG without Reload:

Editor Partner A Reaction

Action SIG N SIG N+1

- - E2 E2

SE Mod.1 CG E2 E3gen Dual Configuration generated

SE Mod.2 CG E2 E4gen New Dual Configuration generated

SE Mod.2 undo CG E2 E3gen Old Dual Configuration generated

- - E2 E3

No SE Mod. CG E3 E3 Dual Configuration deleted

Table 7.3

Several CG with Reload

Editor Partner A Reaction

Action SIG N SIG N+1

- - E2 E2

SE Mod.1 CG E2 E3gen

Reload E2 E3load E2 E3 possible if Partner updated

SE Mod.2 CG E3 E4gen

Reload E3 E4load E3 E4 possible if Partner updated

SE Mod.2 undo CG E4 E3gen

- Reload E4 E3load E4 E3 can leads to link interruptionif E4 was never activated

- - E4 E3 Link comes back again (if disconnectedbefore)

No SE Mod. CG E3gen E3 Dual Configuration deleted

Reload E3load E3

Table 7.4

Consequence:As long only Code Generations are executed no critical situations can occur – we canstill undo.

But once the first partner is loaded there’s no way back! Now we must execute the fullsequence properly and load also the second partner!


29/67



7.1.4 Possible changes and impact on Dual Configuration, restrictions

Definition:Dual Configuration means there’s a new configuration with new safeethernet data existingand also an old “PreReload” configuration.

Changes creating Dual Configuration, normal Reload possible: Add/delete/rename safeethernet GV Add/delete/rename XOPC (DA) GV Add/delete/rename Events (Name,ID,Severity)Change Timing MasterChange Event priorityChange link ID

Changes not creating Dual Configuration, normal Reload possible: Add/delete communication partner Add/delete link for existing partnerChange timing parametersChange limits for scalar Events

Changes not creating Dual Configuration, Reload possible - but with link interruptionChange interface (e.g from CPU to COM) – COM requires Cold Reload!

Non reloadable changes:Parameter: “Behavior on connection loss” Parameter: “Profiles” HIMatrix Remote IO (RIO) connections (neither data – nor settings)


30/67



7.2 Add/delete (new) link including communication signals

This option only exists for PESPES communication, not for PESXOPC!

HIMax (>=BS V6) and HIMatrix F*03 (>=BS V10) support up to 64 (redundant) links.Each link transmits 1100 Byte per direction.

Create new link and enter a link name:

Fig 7.5

Enter a unique link ID (in example it would be “4”).

Execute (Reload) Code Generation for both partners and Reload both partners.The sequence of Reloads is not important!

Advantages:No existing link is touched – no risk!No Dual Configuration created.No specific procedure required.(Compare the procedures in chapter 7.3)

Disadvantages:More links lead to more complexity.More links increase communication load (Com.Time Slice, cycle time)


31/67



7.3 Add/delete communication signals in existing link (Dual Configuration)

This method is optional for PESPES communication (see chapter 7.2 Add/delete(new) link including communication signals) but the only option for PESXOPCcommunication.

7.3.1 Standard procedures

Color legend:Highlighted: Change, new activity/status in current stepPale: Planed but not executed action E2 color for E2 signatureE3 color for E3 signatureE4 color for E4 signatureE3gen new activity: E3 generated by CG, old signature is still in PES (not displayed)E3load new activity: E3 loaded during Reload

E2, E3, E4 are placeholders for safeethernet signatures, in reality it’s a hex-code:

Fig 7.6: SE-Signatures N and N+1

7.3.1.1 Standard procedure PESPES communication – „golden rule“



- - E2 E2 - E2 E2 Link on E2

SE Mod. CG E2 E3gen - E2 E2 Link on E2- - E2 E3gen CG E2 E3gen Link on E2

- Reload E2 E3load - E2 E3gen Link on E2

- - E2 E3 Reload E2 E3load Link on E3

Table 7.5: Standard procedure

7.3.1.2 Standard procedure – „golden rule“ + deleting Dual Configuration (DC)


Action SIG N SIG N+1 Action SIG N SIG N+1- - E2 E2 - E2 E2 Link on E2

SE Mod. CG E2 E3gen - E2 E2 Link on E2

- - E2 E3gen CG E2 E3gen Link on E2



+ del DC

- CG E3gen E3 - E2 E3 Link on E3

- - E3gen E3 CG E3gen E3 Link on E3

- Reload E3load E3 - E3gen E3 Link on E3

- - E3 E3 Reload E3load E3 Link on E3

Table 7.6: Golden rule inclusive deleting the Dual Configuration

Details and explanation see chapter 7.3.2!


32/67


33/67



7.3.1.4 Standard procedure: Undo SE modification



- - E2 E2 - E2 E2 Link on E2


- - E2 E3gen CG E2 E3gen Link on E2- Reload E2 E3load - E2 E3gen Link on E2


UndoSE Mod.

- CG E3 E2gen - E2 E3 Link on E3

- - E3 E2gen CG E3 E2gen Link on E3



Table 7.8

Recommendation: Now delete Dual Configuration, see chapter 7.3.1.2


34/67



7.3.2 Standard procedure (golden rule) in detail

Every modification of safeethernet data or safeethernet properties requires basically aCode Generation and Reload for both communication partners.

It’s essential for success to follow the procedure consequently! Phases 1 to 5 must be executed for every safeethernet modification!Do not interrupt the procedure, do nothing else between!

Fig 7.8: Standard procedure for safeethernet change

Until Phase 4 still the old safeethernet configuration E2 is working. After the Reload in Phase 5 is successfully finished the new safeethernet configuration E3 isexecuted!

SafeethernetModification

Code Generation(Reload option)

Partner A


Partner B

ReloadPartner B

2

3

5

New SE SignatureE3 created


New SE SignatureE3 loaded

Link active on E3

1

ReloadPartner A4


Link active on E2


35/67



Delete Dual Configuration

Most safeethernet modifications lead to a “Dual Configuration”Then both communication partners still “know” the old configuration E2 and the newconfiguration E3

The Dual Configuration is part of the configuration files and therefore affects the master CRC(Codeversion).The Dual Configuration disappears again after a next Code Generation without anysafeethernet modifications.HIMA recommends to “cleanup” the Dual Configuration (if any existing) always.

Fig 7.9: Additional activity for deleting the dual configuration

Remark:Phases 6 to 9 are not mandatory but recommended.

Otherwise the master CRC may change after a Code Generation unexpectedly.Then use the tool “Version Comparison” and see the details.


Partner A

Code Generation

(Reload option)Partner B

ReloadPartner B

6

7

9

Don’t do anymodifications!

Dual Configurationdeleted

Master CRC changes

Dual Configuration

deletedMaster CRC changes

Dual Configurationin PES deleted

ReloadPartner A8

Dual Configurationin PES deleted


36/67



7.3.3 Standard procedure (Check list for print out!)

ProjectName:

ConfigurationName:

Link details (name, no.)

Checklist can be used for all safeethernet Reloads!- If Partner B is X-OPC: No Reload possible Replace “Reload” by “Download” - If Partner B is X-OPC: No Dual Configuration Skip Phase 3 for Partner B

(e.g. enter “Done √” in all lines) - If safeethernet modification doesn’t create a Dual Configuration (e.g. new link, new

partner, time setting etc.) Skip Phase 3 for both Partners(e.g. enter “Done √” in all lines)

Phase 1: Check correct project basis and Reloadability

This step must be executed only if there’re any doubts whether the present project is reallythe correct basis for the planned Reload or if it’s not sure whether Reload is actually working(correct time settings, Reload allowed etc.)

If Reload already worked several times before (with present project) skip phase 1 (e.g. enter“Done √” in all lines)

SEQ Action onProject, Editor

Partner AName:

Partner BName:

Date/Time Done√

1.1 Check linkstatus online:

Check linkstatus online:

1.2 Projectarchive

1.3 CG(Reload option)

1.4 Note CRC (*1):

………………… 1.5 CG(Reload option)

1.6 Note CRC (*1):…………………

1.7 Execute Reload

1.8 Execute Reload

(*1) No CRC change expected!


37/67



Phase 2: Carry out planned safeethernet modification and Reload

Most mandatory step!

SEQ Action on

Project, Editor

Partner A

Name:

Partner B

Name:

Date/Time Done

√ 2.1 Check link

status online:Check linkstatus online:

2.2 Projectarchive

2.3 SEmodification


2.5 Check CGwarningsexpected: (*1)

2.6 Note CRC:…………………



2.9 Note CRC:…………………

2.10 Execute Reload

2.11 Check Reloadwarnings(not expected)

2.12 Project archive(automatic):expected: (*2)




38/67




Partner AName:

Partner BName:

Date/Time Done√

2.14 Execute Reload

2.15 Check Reload

warnings(not expected)




Fig 7.10: Checklist for the safeethernet change

(*1) examples!If Dual Configuration generated:

Fig 7.11

Otherwise no warnings expected.

(*2) example!

Fig 7.12

(*3) example!

Fig 7.13


39/67



Phase 3: Delete Dual Configuration (if existing)

This step must be executed if a stable and explainable Code Version (CRC) is alwaysrequired.Skip this step if Code Version (CRC) change is not relevant at all!Skip this step if the executed safeethernet modification doesn’t even create a DualConfiguration (e.g. new link, new partner, time setting etc.)(Skip enter “Done √” in all lines)


Partner AName:

Partner BName:

Date/Time Done√



3.3

Note CRC:………………… 3.4 CG

(Reload option)


3.6 Note CRC:…………………

3.7 Execute Reloadexpected:



3.10 Execute Reloadexpected:



3.13 Check link statusonline:expected: (*6)

Check link statusonline:expected: (*6)

Table 7.9: Checklist for deleting the dual configuration


40/67



(*4) example!

Fig 7.14

(*5) example!

Fig 7.15

(*6) example!

Fig 7.16


41/67



7.3.4 Guidelines and additional user information (CG and Online)

Examples show a communication between Resource PES 10 and OPC Server .The chapter is related to chapter 7.3.2

Provided info after phase 2 (Code Generation PES 10 ):

Code Generator (PES 10 ):Please watch the warnings from the Code Generator (Example!):

Fig 7.17

The Code Generator is watching whether the newly created Dual Configuration includes a

signature matching to the communication partner (in our example Signature E2 )

Online (CP PES 10 ):

Example!

Fig 7.18

Version Comparison (PES 10 ):

Fig 7.19

Signature E2last loaded

Signature E3prepared for Reload


42/67



Provided info after phase 4 (Reload PES 10 ):


Fig 7.20

Signature N: (in our example E2) is still there and active.Signature N+1(in our example E3 is already prepared and waiting for the update ofcommunication partner:Reload status in CP: “updated” Com LED on CPU shows “Warning”


Fig 7.21

The communication partner realizes the new Signature (E3), already available for PES 10,and indicates the

Reload status: “outdated” Com LED on CPU shows “Warning”

After loading the partner the Reload status is back on “up to date”!

Provided info after deleting the Dual Configuration

In chapter 7.3.1 we recommend to delete the Dual Configuration because of changing themaster CRC.

Info during Code Generation:Example!

Fig 7.22

(Example! “PES10PES20_1” is the name of a link, “PES_10 ” the name of the partner)


43/67



7.3.5 Accident scenarios (overview)

Accident 1: Deleting Dual Configuration before loading the partner:



- - E2 E2 - E2 E2 Link on E2SE Mod. CG E2 E3gen - E2 E2 Link on E2

- Reload E2 E3load - E2 E2 Link on E2

- - CG

- - Reload

- (1)

- CG E3gen E2ld E3 - E2 E2 Link on E2

- Reload E3load E3 - E2 E2 Link down

(1) Means no SE modification but perhaps other (e.g. logic) modification

Tabelle 7.1

Problem:The Dual Configuration in Partner A is deleted. Signature E2 disappears in Partner A, but isstill needed by Partner B. Consequence: The link breaks down!

The mistake is not loading Partner B immediately after Reload of Partner A.The sequence of Code Generation is actually not important – only the sequence of Reloads!

The Code Generator and the System (Firmware) will announce proper warnings, hence theaccident is avoidable!If respecting the CG warnings and/or firmware warnings there’s a way out! For details see chapter 7.3.6.1 “Dual Configuration deleted too early (Accident 1)”


44/67



Accident 2: Yet another SE modification and Reload Partner A again:



- - E2 E2 - E2 E2 Link on E2

SE Mod1 CG E2 E3gen - E2 E2 Link on E2- Reload E2 E3load - E2 E2 Link on E2

- - CG

- - Reload

SE Mod2

- CG E3gen E2ld E4gen - E2 E2 Link on E2

- Reload E3load E4load - E2 E2 Link down

Tabelle 7.2

Problem:Partner A creates yet another signature E4 and deletes signature E2. E2 is replaced by E3but E3 is not yet available by Partner B. Consequence: The link breaks down!


The Code Generator and the System (Firmware) will announce proper warnings, hence theaccident is avoidable!If respecting the CG warnings and/or firmware warnings there’s a way out!

Solution: As long Partner A is not yet loaded (e.g. respecting the warnings) there’s still a chance to getback on track – similar to solution in chapter 7.3.6.1 “Dual Configuration deleted too early

(Accident 1)”

- Undo Mod2- CG Partner B- Reload Partner B Link on E3- CG Partner A (in order to get proper Online functionalities)- Reload Partner A- Then execute Mod2 again and start the full sequence (golden rule)


45/67



Accident 3: Yet another SE modification and Reload Partner B (deadlock):



- - E2 E2 - E2 E2 Link on E2

SE Mod1 CG E2 E3gen - E2 E2 Link on E2


- - CG- - Reload

SE Mod2 E2 E3 CG E2 E4gen Link on E2

- E2 E3 Reload E2 E4load Link on E2

Tabelle 7.3

Problem:Partner B creates yet another signature E4.Both partners are now indicating the Reload status “updated” and actually waiting for eachother.


Up to now nothing serious has happened yet, therefore the Code Generator and the System(Firmware) will not announce any warnings!

You can never get rid of this situation without a short interruption of the link, means whateveryou do; the next Reload will shut down the link.This interruption can take up to two times the Receive Timeout value!See also the basic lesson chapter 7.1.3

Result is a deadlock! There’s no proper way out!

The only remaining solution: Force (if allowed, respecting the safety rules!) all transmittedvariables and execute nevertheless CG and Reload of Partner A (in our example!)The link will jump (with interruption) from E2 to E4.Or wait…

For more details and screenshots see chapter 7.3.6.2


46/67



Accident 4: Undo SE modification in wrong sequence:



- - E2 E2 - E2 E2 Link on E2

SE Mod1 CG E2 E3gen - E2 E2 Link on E2


- - E2 E3 CG E2 E3gen Link on E2- - E2 E3 Reload E2 E3load Link on E3

-

SE Mod2 - E2 E3 CG E3 E4gen Link on E3


UndoSE Mod2

CG * E3gen E3 - E3 E4 Link on E3

- Reload E3load E3 - E3 E4 Link on E3

Tabelle 7.4

CG * : Dual Configuration deleted because new signature is identical to the old signatureRight now (V6.48) no further warnings yet, but in next version!

The sequence of Code Generation is actually not important – only the sequence of Reloads!

Up to now nothing serious has happened yet, but it’s difficult to do the next step correctly.

Option 1 for next step (bad option):If now updating Partner B we get a short link interruption:

Tabelle 7.5

Reload* : During Reload the firmware announces a warning. Hence the accident isavoidable!

Fig 7.23

Abort Reload!

Option 2 for next step (good option):Bring Partner A to the same new version (E4) as Partner B (undo undo)

Table 7.10



- - E3 E3 CG E4 E3gen Link on E3

- E3 E3 Reload* E4 E3load Link down

- E3 E3 - E4 E3 Link E3 back



Back toSE Mod2

CG E3 E4gen - E3 E4 Link on E3

Reload E3 E4load - E3 E4 Link on E4


47/67



Accident 5: Code Generation or Reload denied by Partner B (deadlock):



- - E2 E2 - E2 E2 Link on E2


- Reload E2 E3load - E2 E2 Link on E2- E2 E3 CG* E2 E3gen* Link on E2

- - E2 E3 Reload ** E2 E2 Link on E2

Table 7.11

CG* Planned action, but Code Generation denied due to existing errors

Reload ** Planned action, but Reload denied

Problem:Partner A is already loaded, but Partner B cannot be loaded due to Code Generatorproblems or Reload problems.The Reload sequence cannot be completed.

Solutions:If possible make sure the CG for Partner B works again (e.g. fix the errors)If possible make sure the Reload for Partner B works again.That’s not yet a real problem as long the fixing the problem only affects Partner B.But it’s getting a real Problem if fixing the problem would require another CG and Reload ofPartner ASee next page…


48/67



Example for a deadlock scenario:The CG for Partner B was denied because Partner A accidently transmits the same variabletwice via two different links. That’s no problem for Partner A, but CG for Partner B is notpossible because there the variable is written twice.

Theoretically two options exist:

1. Undo the last safeethernet modification manually(in example: remove the variable from the second link).The CG of Partner A generates the old signature E2 again.

2. Use a project backup and go back to the original version before the last modification.(therefore export the current configuration and import it into the backup project)The CG of Partner A generates the old signature E2 again.

But: If SIG N+1 has already been on E3 (but never activated) stepping back to E2 causes

always a short interruption of the link. See chapter 7.1.3



UndoSE Mod

E2 E3 - E2 E2

- CG* E3gen E2ld E2gen - E2 E2 Link on E2

- Reload* E3load E2load - E2 E2 Link interrupted

- - E3 E2 - E2 E2 Link back on E2

Table 7.12

You can never get rid of this situation without a short interruption of the link, means whateveryou do; the next Reload of Partner A will shut down the link.This interruption can take up to two times the Receive Timeout value!

CG and Reload of Partner A without any safeethernet modification is also not possibleanymore!Firstly this does not solve the problem of Partner B and secondly then the link is really downbecause the Dual Configuration in Partner A (including E2) will be removed

Result is a deadlock! There’s no proper way out!

The only remaining solution: Force (if allowed, respecting the safety rules!) all transmittedvariables and execute nevertheless CG and Reload of Partner A (in our example!) andaccept the link interruption.Or wait…


49/67


50/67



7.3.6 Accident scenarios (details)

7.3.6.1 Dual Configuration deleted too early (Accident 1)

(The correct procedure still appears in light grey – the wrong procedure appears in red!)

Fig 7.26



Partner A


Partner B

ReloadPartner B

2

3

5




Link active on E3

1

ReloadPartner A4New SE Signature

E3 loadedLink active on E2


Partner A

ReloadPartner A

5

6

Dual Configurationdeleted!

Version E2 disappears, version E3 still there

New SE Signature E3 (but not E2 ) l oaded L ink is now down since E2 does not existanymore – but still needed by the partner!

No furthersafeethernet

modification **


51/67



** In diagram we only show Accident 1. Accident 2 occurs if now alternatively another safeethernet modification is carried out.See chapter 7.3.5

Normally step 4 and 5 should be Reload Partner A and Partner B!

Accident 1:Here, for some reason, somebody made another Code Generation for partner A.It doesn’t matter whether the new Code Generation contains even new modifications, e.g.changes in logic, or not.If no further modifications for safeethernet made, the new Code Generation deletes the DualConfiguration and consequently the old SE signature E2.

After executing the Reload (Step 6) the link would be down because SE signature E2 is stillrequired by communication Partner B.

Accident 2: Accident 2 is only a variant. In accident 2 another safeethernet modification is carried beforeloading Partner B. Same consequence: SE signature E2 disappears in Partner Aconfiguration. After executing the Reload (Step 6) the link would be down because SE signature E2 is stillrequired by Partner B.


52/67



Guidelines – or “how to avoid the mistake”:

After phase 5 (second Code Generation of partner A) the Code Generator announces awarning:

Examples!

Fig 7.27

(Normally the warning is displayed in one line)

If the warning is ignored the firmware is the second defense line:

During phase 6 (second Reload of partner A) the firmware announces a warning:

Fig 7.28

Fig 7.29


53/67



The problem now:The last generated Code for Partner-A is valid but cannot be used (yet) since therein theneeded Dual Configuration (Version E2 ) is already deleted. A generated but not loaded code result in problems with Online Test and/or next Reload!

Solution: Back to the original phase 5!-We must execute the Code Generation and Reload of partner B first and thenexecute Code Generation and Reload of Partner A (again).

See next pages!


54/67



The only solution: Reverse!

Fig 7.30



Partner A


Partner B

ReloadPartner B

2

3

5




Link active on E3

1

ReloadPartner A4


Link active on E2


Partner A

ReloadPartner A

5

6

No furthersafeethernetmodification


55/67



Back on track:

Fig 7.31


Partner A

ReloadPartner A

6

7

Dual Configuration is already deletedVersion E3 created again

New SE Signature E3 loaded again!Online Test and Reload possible again!

ReloadPartner B5

New SE Signature E3loaded

Link active on E3



Partner A


Partner B

2

3



1

ReloadPartner A4


Link active on E2


56/67



7.3.6.2 SE Change 1 >Reload Partner A, SE Change 2 >Reload Partner B (Accident 3)

(The correct procedure still appears in light grey – the wrong procedure appears in red!)

Fig 7.32

RESULT: DEADLOCK!



Partner A

ReloadPartner A

Code Generation(Reload option)Partner B

ReloadPartner B

2

3

4

5



Link active on E2

Another new SE Signature E4 created Version E2 is still existing

New SE Signature E4 and old SE Signature E2loaded

Link remains active on E2

1

Anothersafeethernetmodification

Code Generation(Reload option)Partner B

ReloadPartner B

4

5



Link active on E3


57/67



The link is still active on E2, here displayed as Signature N.

Fig 7.33

Please note:There’re no further warnings from the Code Generator or from firmware!

Both partners are now on status “updated”. This is actually not foreseen and results in a crucial situation:

You cannot simply Reload partner A now!This would most likely lead to a short communication interruption!

If you try anyway the system (firmware) announces a warning:

Fig 7.34

“Abort Reload” - or do not even execute the Reload if you cannot afford a temporallylink shutdown!

Do only “Resume Reload” if a temporally link shutdown can be accepted – butconsider the consequences for the process!


58/67


59/67



7.5 Special case: Communication partner is not in the same project

Problem: The Code Generator cannot check the partner’s loaded configuration, because it is not in thesame project.

Warning after Code Generation:

Fig 7.37

Consequence: The guideline “Code Generator” does not exist anymore!The only remaining safeguards are the firmware warnings (consider: they can’t detecteverything).

Your options:

1. Trust yourself and the firmware – and/or

2. Create a project archive and then load the Resource in a Test-PES and read the

generated safeethernet signatures.Compare and analyze the signatures:

Test-PES:

Partner:

Result: OK!

Table 7.13

3. Or create a new link for newly generated communication variables and keep theoriginal link untouched ( risk reduction!) See chapter 7.2


60/67


61/67



cpcsip.config:

Fig 7.41

Hint: The link ID we see in safeethernet editor:

Fig 7.42

Current Online situation (before Reload):

Fig 7.43

Version DL in version comparison is identical to Signature N+1 (loaded in PES)The old “Signature N” is not considered in the version comparison any more.

PartnerSystem-ID

Link-IDhere = 0

Link-ID

SE signature


62/67



ke.config:

Fig 7.44

Fig 7.45

After Reload:

Fig 7.46

Version DL from version comparison is now “Signature N” Version CG from version comparison is now “Signature N+1”


63/67



7.7 Check SE Signature in a project backup

Open SILworX a second time and restore the project in which you assume the expected SESignature.

Export the last loaded configuration via the tool “Version comparison”

Fig 7.47

Import the configuration in your actual project:

Fig 7.48

In this example the imported version is identical to “Last Load”. Means the previously restored project matches the last loaded version and can be used forReoad etc. again!

Fig 7.49


64/67



8 Appendix

8.1 Safeethernet principle (simplified)

1. Example, well working communication

Telegrams are send on the end of a CPU cycle. Any reaction, also the processing of data,happens on the beginning of a CPU cycle. The understanding of this principle is important forcalculating “Receive Timeout” and “Resend Timeout” Advantage of “double shot principle”: Processing newest data without waiting foracknowledge. Makes a communication more efficient especially if the data transmission timeor the cycle time of target system is pretty long.

Fig 8.1

Telegram 1 (T1)

Telegram 2 (T2)

Cycle PES10 Cycle PES20

Acknowledge T1 and T2

T3

T4

Acknowledge T3 and T4

PES20:Processing data of T2


CPU cycle


65/67



2. Example with a loss of telegram:Profile “Fast & Noisy” tolerates the loss of one or more telegrams (depending relationReceive TMO / Resend TMO). Resend after “Resend Timeout”. Safety reaction after “Receive Timeout” expired.

Fig 8.2

T1

T2 lost


Acknowledge T1

Resend T2

PES10:Resend Timeout forT2 started

PES20:If Resend would not behave been successfulReceive Timeout expired.Set imported variables toinitial values

PES20:Processing data of T1Start Receive Timeout


Acknowledge T2

T3

T4

PES10:Resend Timeout forT2 ex ired


66/67



3. Example demonstrates worst case situation regarding cycle time

Here the maximum calculated factor (5 x max. cycle time) is required.

Fig 8.3

T1

T2 lost


Resend T2, lost again

PES10:Resend Timeout forT2 started

PES20:Processing data of T1Start Receive Timeout

Acknowledge T1

PES20:Processing data of T2 ifResend successful

PES20:Resend not successfulReceive Timeout expired.Set imported variables toinitial values

PES10:Resend Timeout forT2 ex ired


67/67


9 Changes

Rev.: Date/Name Text

02 05.08.09/Kull Document new created.

03 10.08.2009/Kull Adjusted to SILworX V3

04 14.06.2012/ML Adjusted to SILworX V4

05 04.07.2012/ML Position of the variable definition changed.

Second Example in the appendix modified.

06-09 Draft versions

10 30.01.2014/Kull V6 features, safeethernet Reload

11 05.02.2014/ML Little updates

12 08.05.2014/ML

13.06.2014/Kull

Little addition in change from

02-safeethernet 12 e f

Documents