Standard Network Diagnostic Assembly

Raymond Romito
Rockwell Automation
October 10, 2018

Introduction••

The Standard Network Diagnostic Assembly whitepaper describes newdiagnostic material coming to the CIP Networks Library
It covers the concepts in TDE 0001-025, Network Diagnostic Assembly– Created by the Roundtable for EtherNet/IP Developers• Defines diagnostic structures in six object classes• New common service to help clients interpret structure information• Establishes device-independent Assembly Object instance IDs– Standard Network Diagnostic Assembly• Includes enhancements to Assembly object definition– New attribute, and access rules for diagnostic assemblies• Describes for a scalable diagnostic architecture in devices that allows for variations inproduct features and port assignments– First, a little background on what has been driving thisTechnical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

2

Background - Roundtable Diagnostic Activities
Created a Diagnostic System Framework– Created early on to illustrate the concepts this activity is considering– This has been the reference for the Roundtable’s work
Created scope of work document for a diagnostic system (TDE-0001-023)– Includes data definitions, event logging, delivery mechanisms
Refined/added diagnostic attributes to various objects– These were added to the CIP Networks Library in 2016
EtherNet/IP Troubleshooting Guide– Currently work in progressStandard Network Diagnostic Structure Proposal (TDE 0001-025)– Approved by TRB in spring 2018

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

3Current State•

TDE 0001-025 has been translated into two Specification Enhancements– CIPSE 0001-283 Standard Network Diagnostic Assembly– ESE 0001-064 Diagnostic Connection Points•

These are currently going through SIG review– The paper is based on what was provided to the SIGs, which could change•

Targeting inclusion in the Spring 2019 release of the CIP Networks LibraryTechnical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

4The Need for Diagnostics•

There are more devices connected thanever before– And it continues to grow•

Networks are larger and more complex•Information is needed– To effectively manage networks– To troubleshoot networks that have issues– For early detection of potential problems•

This presents a few challenges

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

5Challenges for Diagnostics – Data Organization•

Variation between devices is prevalent– Many device features are optional in CIP– Optional features often vary from device to device– For many devices, user-selected feature settings
can change data•

Tools and Users must deal with thisinconsistency, often on a device by device basis– Customer application programs are morecomplex

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

6Challenges for Diagnostics – Data Organization•

Consider these commonly useddiagnostic values– Only four are part of required attributes••

Client tools must deal with variations on adevice by device basis
This adds complexity

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

7Challenges for Diagnostics – Messaging Requirements•Diagnostic data is organized as attributes ofvarious objects•

The attributes must be discretely read
– Requires 10 Get Single requests to retrieve 12diagnostic values•

Consider the impact on a large network– 100 nodes x 10 messages/node – 1000 messages– Polled every 5 seconds = 1 message every 5ms

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

8Customer Wish List•

One place to go for diagnostics– Standardized for all products and vendors•

Accommodate the variations in devices– Extensible with minimal configuration requirements•

Minimize traffic needed to obtain the data
– Quieter networks are better•

Simplify control programs– Lower complexity usually means lower development and maintenance costs•

Minimize configuration of diagnostics– Let tools figure it out instead of making a controls engineer do itTechnical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

9How The New Functionality Addresses the Wish List••

Standard Assembly Instance puts the data at a known location regardless ofDevice TypeStandardized content is described in class-specific diagnostic structures– Variable based on features implemented and user feature assignments•••

Rules governing how the content is organized help reduce the need forspecial handling of devices
All this results in less messaging to get the pertinent data
Devices determine the content that is provided, no user setup needed•

Let’s take a closer look at the details

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

10Standard Assembly Instance•Range of IDs are reserved forstandard assemblies– Independent of device type•

Standard Network Diagnostic
Assembly – instance 0xD2•

Other instances can be used
for different diagnostic
information– Not in scope for the current
SEs

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

11

Standard Network Diagnostic Assembly•Instance 0xD2•

Spec-defined content and placement rules make iteasier for clients to understand content•

Accommodates configuration and/or feature variations•

Designed to create a “pluggable” diagnostic structure•Rules for Member List content assures
forward/backward compatibility

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

12Instance 0xD2 Content Definition•This is not network-specific, it is applicable to any CIP network– Requires future additions to network specific objects e.g. Dnet object, etc••

Rules governing: placement and number of instances of members, when/ifmember can be omitted
Limits members to just the listed items

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

13

Instance 0xD2: Examples of 2 Common Devices•1-Port EtherNet/IP Device

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

2-Port EtherNet/IP Device

www.odva.org

14

Additions to the Assembly Class Definition•

Add the Member List Signature attribute (instance attribute #5)– Provides a signature over the Member List (Attribute #2) contents• Value changes when device features change (causes the Member List to change)• Detects positional and content changes in the data

– Clients use this to tell when the Member List needs to be parsed for changes– Always the first member in the Standard Network Diagnostic Assembly•

New assembly type is needed because of the Standard Network Diagnostic
Assembly requirements are not quite in line with dynamic or static
assemblies– e.g. the Member List attribute is required as read only, Member List Signature
required as first member

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

15

Diagnostic Content for Object Classes•Diagnostic content will be defined in a new optional section in the object
definition “Diagnostic Connection Points”– SIGs maintain, know the diagnostic significance/importance of the content•

Defines one or more structures of diagnostic attributes from the class– Values that when they change indicate that device/network health or resourceloading has changed– Does not include values that are generally static like device settings•

These structures are addressed using the Logical Segment type
“Connection Point”– These have typically only been used for establishing I/O connections before

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

16

Connection Point Definition Details••Provides the building blocks for standardized ‘pluggable’ diagnostic content
Doesn’t require the use of EDS files– Many client devices can’t utilize these effectively•

Together with the Standard Diagnostic Assembly, the content isdiscoverable– Assembly instance is always 0xD2
– The Assembly Member List contains the EPATHS to the object-class definedstructures– Classes implement a new CIP Common service it obtain the EPATHs of themembers of each Connection Point• This allows devices to use Parameter Instances to provide more meta data about thediagnostic attributeTechnical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

17

Example Diagnostic Structure•

Example of Connection Point 1 of the Connection Manager object

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

18

Connection Point Definition Details Continued•

The model developed is generic– Can be used for more than just network diagnostics•The specification content establishes the rules for managing the content– Not just what goes into it but the order and packing– Future modification requirements are established• Can be extended, cannot have members removed/replaced, etc• Goal is to provide forward compatibility for clients and devices•

Supporting these implies all the member attributes are supported– Some are optional– No “holes” or placeholders for attributes not supported

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

19

Diagnostic Application Profile
•••
•
•
•

Borrows on the concept in Volume 2, Chapter 8 for COTS vs Industrial
performance levels for the Ethernet interface port
A way to specify that optional content is required if a product meets thisApplication Profile
Designed to raise the bar for EtherNet/IP and CIP
Makes it easier for vendors to know what optional content they should
implement
Define testable content that ODVA’s CA can, if desired, test for compliance
withThis definition is planned as a potential next step in enhancing diagnostics
capabilities of EtherNet/IP devices

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

20

THANK YOU