PROFIBUS Profile Guidelines, Part 3 - 3+-+Profibus+Guidelines+3.522+... · PROFIBUS DP standards,...

PROFIBUS

Profile Guidelines, Part 3

Diagnosis, Alarms and Time Stamping

Version 1.0 July 2004

Order No: 3.522

PROFIBUS Profile Guidelines: Part 3 Diagnosis and Alarms Version 1.00, 15-July-2004

PROFIBUS Profile Guidelines, Order No: 3.522 Part 3: Diagnosis, Alarms and Time Stamping Version 1.0 July 2004 This series of PROFIBUS profile guidelines specifies generic profile features for all PROFIBUS devices as long as dedicated profiles do not overrule them by well-founded reasons, e.g. al-ready existing profiles or DP-V0 functionality only. Developed by various PROFIBUS Working Groups mainly within the Technical Committee for „Application Profiles“ (TC3). This version passed the PI Review by end of June 2004 and has been released by the advisory board in October 2004. Publisher: PROFIBUS Nutzerorganisation e.V. Haid-und-Neu-Str. 7 D-76131 Karlsruhe Germany Phone: ++49 721 / 96 58 590 Fax: ++49 721 / 96 58 589 E-mail: [email protected] http://www.profibus.com No part of this publication may be reproduced or uitilized in any form or by any means, electronic or mechanical, including photocopying and mi-crofilm, without permission in writing from the publisher.

© Copyright PNO 2004 – All Rights Reserved

Profile-Guidelines-Diagnostic_3.522_V10_Oct04.doc

http://www.profibus.com/


Revision Log:

Version Date Changes/History

0.8 09-Dec-2003 Working draft

0.81 12-Dec-2003 Input from X. Schmidt: Diagnosis Alarm, GSD

0.92 22-Feb-2004 Review comments as of Dec 15th, 2003

0.95 08-Jun-2004 Comments from 3 months PNO review covered (see PNO project database for contributions). Version for final discussion in TC3.

1.00 15-Jul-2004 chapter 5.2, page 40, 1st chapter: destination service address (33 --> 51).....optionally (32 --> 50)....

15-Jul-2004 New document layout and formatting. Final version.

01-Oct-2004 Released by PROFIBUS advisory board

© Copyright PNO 2004 – All Rights Reserved Profile-Guidelines-Diagnostic_3.522_V10_Oct04.doc


Table of Contents 1 Motivation and Scope....................................................................................................................... 7 2 Terms and Definitions ...................................................................................................................... 8

2.1 Definitions .............................................................................................................................. 8 2.2 Standards............................................................................................................................. 13 2.3 Abbreviations ....................................................................................................................... 13

3 Diagnosis scenarios within distributed automation systems .......................................................... 15 3.1 Network level / commissioning............................................................................................. 15

3.1.1 Fieldbus installation ................................................................................................ 15 3.1.2 Bus signals ............................................................................................................. 16 3.1.3 Reachable participants ........................................................................................... 16 3.1.4 Network traffic / bus monitors ................................................................................. 16

3.2 Online diagnosis / operation ................................................................................................ 18 3.2.1 Diagnosis repeater.................................................................................................. 19 3.2.2 Field device diagnosis ............................................................................................ 19 3.2.3 Diagnosis messages coming and going................................................................. 20 3.2.4 Variable language support...................................................................................... 20 3.2.5 Testability................................................................................................................ 20 3.2.6 Complex field devices............................................................................................. 20 3.2.7 Data exchange broadcast....................................................................................... 21 3.2.8 Isochronous mode (e.g.drives) ............................................................................... 21 3.2.9 Slave redundancy ................................................................................................... 22 3.2.10 System diagnosis.................................................................................................... 22 3.2.11 Process diagnosis................................................................................................... 22 3.2.12 Message flooding / time stamping .......................................................................... 22 3.2.13 Acknowledgements................................................................................................. 22

3.3 Maintenance / repair ............................................................................................................ 23 3.3.1 Wrong or missing parts........................................................................................... 23 3.3.2 Localization............................................................................................................. 23

3.4 Preventive Maintenance ...................................................................................................... 23 4 Possibilities of fault indications for field devices (Slaves) .............................................................. 24

4.1 The main diagnosis model of PROFIBUS DP ..................................................................... 24 4.2 Diagnosis via master class 2 ............................................................................................... 28 4.3 Device Displays.................................................................................................................... 28 4.4 [Value] Qualifiers.................................................................................................................. 29 4.5 Impact of diagnosis messages on the automation system .................................................. 30 4.6 Semantics of diagnosis messages / usability ...................................................................... 31 4.7 Time-stamping ..................................................................................................................... 31

4.7.1 Clock time synchronization..................................................................................... 31 4.7.2 Time-stamped Alarms and Events ......................................................................... 31

4.8 Processing of diagnosis information .................................................................................... 31 4.8.1 DP-V0/V1................................................................................................................ 31 4.8.2 DP-V1 ..................................................................................................................... 32 4.8.3 Standardized software interfaces (IEC 61131-3) ................................................... 33



5 Diagnosis mechanisms of PROFIBUS DP..................................................................................... 34 5.1 Overview .............................................................................................................................. 34 5.2 Diagnosis communication .................................................................................................... 37 5.3 Alarm communication........................................................................................................... 41 5.4 Diagnosis data structure ...................................................................................................... 42

5.4.1 Standard Diagnosis ................................................................................................ 43 5.4.2 Identifier_Related_Diagnosis.................................................................................. 45 5.4.3 Module_Status........................................................................................................ 46 5.4.4 Channel_Related_Diagnosis .................................................................................. 47 5.4.5 Diagnosis Alarm...................................................................................................... 48

5.5 DxB Link Status.................................................................................................................... 49 5.6 Time stamped Alarms and Events ....................................................................................... 50

6 MS2 Diagnosis ............................................................................................................................... 54 7 Diagnosis configuration techniques (GSD) .................................................................................... 55

7.1 General configuration of PROFIBUS segments using GSD files ........................................ 55 7.2 Diagnosis in the GSD file ..................................................................................................... 55

7.2.1 Text and help for channel related diagnosis........................................................... 55 7.2.2 Text and help for diagnosis alarms......................................................................... 56

7.3 GSD tool set......................................................................................................................... 57 8 Migration to PROFINET IO............................................................................................................. 58 9 Appendix......................................................................................................................................... 59

9.1 General structure of the diagnosis type "Alarm model" ....................................................... 59 9.2 General structure of the diagnosis type "Status model" ...................................................... 60 9.3 General structure of the Alarm Acknowledgements ............................................................ 61

10 Literature ........................................................................................................................................ 64

Figures Figure 1-1 Profile guidelines “Diagnosis” as an agreement between partners ..................................... 7 Figure 3-1 Errors, failures and faults within an automation system .................................................... 15 Figure 3-2 One typical display of a PROFIBUS monitor program....................................................... 17 Figure 3-3 Another typical display of a PROFIBUS monitor program................................................. 17 Figure 3-4 Diagnosis repeater to detect network problems ................................................................ 19 Figure 3-5 Delayed diagnosis mode for time critical applications ....................................................... 21 Figure 3-6 Time stamping of alarms and events ................................................................................ 22 Figure 4-1 Data flow for diagnosis, status, and alarms ....................................................................... 24 Figure 4-2 Network view with slaves notifying faults........................................................................... 25 Figure 4-3 Diagnosis overview of a panel display............................................................................... 25 Figure 4-4 Structure of recommended diagnosis messages.............................................................. 26 Figure 4-5 Detailed channel diagnosis ................................................................................................ 27 Figure 4-6 Structure of the recommended diagnosis for special technologies .................................. 27 Figure 4-7 Control definitions for the LED indicators .......................................................................... 29 Figure 4-8 Example for a value qualifier.............................................................................................. 29



Figure 4-9 Process image and diagnosis information (separate)........................................................ 32 Figure 4-10 Diagnosis using acyclic read/write services..................................................................... 32 Figure 4-11 Diagnosis using standardized software interfaces........................................................... 33 Figure 5-1 Overview on PROFIBUS DP diagnosis structures ............................................................ 34 Figure 5-2 Physical and logical structures of field devices.................................................................. 35 Figure 5-3 Basic PROFIBUS DP communication ............................................................................... 37 Figure 5-4 Run-up state chart of a slave ............................................................................................. 38 Figure 5-5 Message structure for cyclic data exchange...................................................................... 38 Figure 5-6 Exchange of diagnosis information.................................................................................... 39 Figure 5-7 Communication services of PROFIBUS DP ...................................................................... 40 Figure 5-8 Basic diagnosis communication mechanism .................................................................... 41 Figure 5-9 Alarm communication mechanism..................................................................................... 42 Figure 5-10 Recommended structure of a diagnosis message........................................................... 43 Figure 7-1 Alarm data description in a GSD file.................................................................................. 56 Figure 7-2 GSD editor screenshot....................................................................................................... 57 Figure 7-3 Tools and handling of GSD files ........................................................................................ 58 Figure 8-1 Overview on the recommended diagnosis types and the migration .................................. 59



1 Motivation and Scope

Over the years the PROFIBUS community got acquainted with a couple of application profiles such as "PA devices", "PROFIdrive", "Encoders", and others. For these device families structures and behavior are well defined, the acceptance is increasing and thus application profiles are becoming more popu-lar. On the other hand the community is facing some flaws with profiles. One of these is the fact that it is not worthwhile for every device type to develop a profile. Thus many manufacturers are designing their devices according to their own rules and optimization strategies and hence customers are suffer-ing from diversity in functions, syntax and semantics. Another problem comes with the staggered ap-pearance of profiles on the market. It is nearly impossible to keep all the profiles on the same level of knowledge and standardization.

Technical Committee 3 within the PROFIBUS Organization therefore decided to publish a series of profile guidelines dealing with the most important common features of PROFIBUS slave devices. This part 3 is dealing with the different aspects of diagnosis, the various means and levels provided by the PROFIBUS DP standards, some additional helpful features like LED indicators and recommended best practice design patterns for field devices. The expected benefit is an improvement of the quality of information for the user in case of faults, a more uniform system handling in order to reduce engi-neering costs via standard software within controllers, and an optimized overall system performance. These general profile guidelines are reducing the effort for individual application profiles for device families and represent an agreement between the communicating partners on PROFIBUS DP: control-lers (master class 1 devices), field devices (slaves), and engineering or monitoring devices (master class 2). See Figure 1-1.

1

2

7

1

2

7

Controller (Master) Field Device (Slave)

Process Monitoring and

Engineering (Master)

IEC 61158Communication profileType 3 (PROFIBUS)

Diagnosis

Figure 1-1 Profile guidelines “Diagnosis” as an agreement between partners

After terms and definitions in chapter 2, the guidelines in chapter 3 describe common scenarios for bus systems to guarantee short down times via excellent diagnosis information. Chapter 4 demon-strates the various possibilities of fault reporting to operators and maintenance persons and the differ-ent system reactions. Chapter 5 and 6 inform about the standard diagnosis features of PROFIBUS DP. The system integration techniques via GSD are treated in chapter 7.



2 Terms and Definitions

2.1 Definitions

Term Definition IEC Reference1

Alarm Notification of an abnormal or unexpected event within a system. Alarms in PROFIBUS DP are requiring a sepa-rate acyclic acknowledgment procedure between a host and a slave application in addition to the standard diag-nosis mechanism within the cyclic data exchange.

The preconditions for the transmission of an alarm are: • DP-slave in the data exchange mode • the MS1 connections to be open • the corresponding alarm type to be enabled • the limit of active alarms is not exceeded.

Two alternatives for the alarm handling are defined: • Alarm type mode • Alarm sequence mode

Alarms are to be queued. They remain active until the master (class 1) explicitly acknowledges the alarm.

P5, 8.2.4

Alarm ack The master (class 1) uses this service to acknowledge the reception of an alarm notification, which has been previously received from the slave.

P5, 8.2.4.3.2

Alarm limit This parameter indicates the maximum number of paral-lel alarms a master (class 1) is able to handle. See “A-larm sequence mode”.

P5, 8.2.5.3.15

Alarm max This attribute indicates the maximum number of alarms per slave, which can be handled by a master (class 1). Shall be at least 7.

P5, 8.2.10.3.2.2

Alarm sequence mode

Several alarms (2 to 32) independent of the type can be active at the same time. This mode is optional for slaves and master (class 1) if alarms are supported. Currently not recommended. “Alarm type mode” should be used instead.

P5, 8.2.4.1

Alarm specifier This attribute specifies additional alarm information like fault occurred or disappeared. Details for multiple faults one after the other or all at one point in time should be defined within the context of device profiles.

P5, 8.2.4.2.2

Alarm model type The following alarm model types*) are defined: • Diagnosis • Process • Pull • Plug • Status • Update • Manufacturer specific

*) GSD file contains: "DPV1"=1

P5, 8.2.4.2

P6, 6.2.3.7

Alarm type mode Only one alarm of a specific alarm type can be active at the same time. This mode is mandatory for slaves and

P5, 8.2.4.1

——————— 1 IEC 61158-x:2003(E); x = Part 1..6



master (class 1) if alarms are supported.

Alert Alert is a generic term for two different types of notifica-tions within a PROFIBUS DP/PA network especially ar-ranged but not exclusively for the process automation: • Alarm • Event

Both alert types may be used with or without a user ac-knowledgement mechanism.

IEC 61804 and [4]

Channel Single physical or logical link of an input or output appli-cation object of a server to the process. E.g. a subunit of a slave or module of a slave that is connected to process input or output signals (switches, sensors, transducer, bar code readers, transponders, actuators, etc.).

P5, 3.6.18

P6, 3.4.4.3

Channel related di-agnosis

This diagnosis information is related to one channel (sig-nal input, or output) of a slave or a module of a slave. A module may have several channels. 9 common fault ty-pes are predefined. More manufacturer specific types are available. Deployment within slaves is highly recom-mended.

P5, 3.6.19

P6, 8.2.3.2.3

Chk_Cfg message A master class 1 can use a special service to send a slave its planned configuration and ask for comparison with its internal actual configuration.

-

Delayed diagnosis mode

For the isochronous mode operations of masters class 1 (DP-V2) the response to the diagnosis request shall not affect the normal process data exchange. This response rather will be delayed to the configured period of time for acyclic data exchange.

-

Device related diag-nosis

This diagnosis information is related to the whole slave and only shall be used in case of DP-V0 slaves. It is lim-ited to 62 octets. For DP-V0 slaves the coding of the di-agnosis data was not structured and specified and there-fore this type of diagnosis is no more recommended for new implementations. Since DP-V1, “Device related di-agnosis” is the basis for the “Alarm” and “Status” types of diagnosis messages (GSD file with “DPV1” = 1).

P5, 8.2.3.2.1 P6, 3.4.4.13 P6, 6.1.1

Diagnosis Identification of the nature or cause of some abnormal or unexpected phenomenon, hereinafter from a PROFIBUS slave. Most of the diagnosis scenarios require interven-tion through service personal. PROFIBUS DP provides means to associate human readable information to ma-chine-readable information with helpful instruction texts or graphics. This shortens repair latency times and thus improves the uptime of automation systems.

Predictive diagnosis via "warnings" avoids surprising downtimes as it allows preventive maintenance.

-

Diagnosis alarm One of the alarm types. A diagnosis alarm signals a fault within a module, for instance overtemperature, short cir-cuit, etc. The alarm type code is “1”.

P5, 8.2.4.1

Diagnosis data Digitally coded failure or error types of modules or field devices according to the IEC 61158 standard type 3.

Diagnosis information This term is used to identify the whole diagnosis data of a slave.

P6, 3.4.4.14



Diagnosis information collection

A system diagnosis information that is collected at the master (class 1).

P6, 3.4.4.15

Diagnosis types The following diagnosis types are defined: • Device related diagnosis (DP-V0 versus DP-V1) • Identifier related diagnosis • Channel related diagnosis • Revision Number (usage not recommended)

P5, 8.2.3.1

Diagnosis_User_ Data

Manufacturer specific diagnosis data that can be trans-ferred via the diagnosis types "Status”. Structure and texts defined within the GSD file of a particular slave.

P6, 6.1.1

Diagnostics The means to examine dedicated parts of a device and to generate diagnosis information, e.g. a diagnostic pro-gram.

-

DxB link status This diagnosis information indicates faults within the data exchange of publishers and subscribers (e.g. wrong data length).

P5, 8.2.3.2.6

Error Errors are static conditions that exist throughout the product lifecycle, and are inherent characteristics of the system. These errors are caused by a misconception in the design resulting from e.g. incorrect information.

Errors may also be temporary incorrect bits within memories or within received messages e.g. due to elec-tromagnetic interference (EMI).

-

Event Within PROFIBUS DP/PA this is the value of a signal, I/O data, or process data within a field device at that point in time where a certain trigger condition arises. The values are associated with a time stamp and stored in a buffer.

The time-stamped sample values are used to archive and visualize significant changes over the course of the production process. Such an event mechanism does not prevent from the cyclic transmission of these signals. A separate event alarm is requesting the transfer of the events to the host/master system.

IEC 61804 and [4]

"Ext_Diag“ Flag A synonym for the “Diag.Ext_Diag” parameter in octet 1 of the Standard Diagnosis.

P6, 6.2.3.1

"Ext_Diag_Overflow" Flag

A synonym for the “Diag.Ext_Diag_Overflow” parameter in octet 3 of the Standard Diagnosis indicating more di-agnosis information within the slave than fit into the di-agnosis buffer.

P6, 6.2.3.3

Extented Diagnosis Any diagnosis information beyond the Standard Diagno-sis information (first 6 octets) of a diagnosis message within PROFIBUS DP. Only in case of a fault the pa-rameter “Diag.Ext_Diag” in octet 1 shall be set inde-pendent from any Extended Diagnosis information.

-

Failure The nonperformance of a system to achieve its intended function within its performance constraints. Failures are events that occur. At some point in time they are leading to a failed condition (state) e.g. due to hardware defects. The definition within the IEC dictionary is: "The termina-tion of the ability of an item to perform a required func-

-




tion".

Fault A fault is an unsatisfactory system condition. Thus, fail-ure states and errors are different kinds of faults.

-

Head Station Usually this part of a modular slave that carries the field-bus communication unit. See the PROFIBUS profile "RIO for PA".

[3]

Identifier related diagnosis

This diagnosis information is related to modules of a slave. One bit per (configuration) identifier (module) indi-cates via a “1” the presence of diagnosis data. The length is limited to 32 octets. Deployment within modular or virtual modular slaves is highly recommended.

P5, 3.6.72

P5, 8.2.3.2.2

Index Address of an object within an application process of a PROFIBUS DP slave. In fact the third level within the addressing hierarchy after station and slot address. Used to store and/or retrieve records in modules.

P6, 3.4.4.25

Max_Diag_Data_Len The maximum length of diagnosis messages of a slave (number of octets). This value shall be assigned within the GSD file of the slave to allow the master to optimize its memory allocation.

-

Manufacturer specific alarm

This type of alarm may be assigned a value between 32 and 126. Definitions via GSD file. The application profile “PA Devices” is using and defining type 126.

P5, 8.2.4.2.2

Module Addressable unit inside the slave. P6, 3.4.4.28

Module status A status type whereat 2 bits per module of a slave are indicating module faults, wrong modules, and missing modules. Deployment within modular or virtual modular slaves is highly recommended.

P5, 8.2.3.2.5

Plug alarm A slot signals the insertion of a module. The alarm type code is 4.

P5, 8.2.4.1

Predictive diagnosis Predictive diagnosis via "warnings" avoids surprising downtimes as it allows predictive maintenance via asset management tools. Appropriate requirements are going to be defined within the process industries. Several lev-els/classes of indications are in discussion, e.g. a pro-posal from PNO: “Green” Process value ok. No action required. "Orange" Process value has limited validity. Low priority

maintenance required within the next few days or the next scheduled date (parameter as-signment).

“Yellow” Process value has limited validity. High priority maintenance demand within e.g. the next 24h (parameter assignment).

“Red” Process value invalid. Immediate maintenance due to failure.

“Blue” Device under inspection (local control), e.g. simulation, calibration, etc.

"Black" Device passivated (no function)

[7], [10]

"Prm_Req" Flag A synonym for the “Diag.Prm_Req” parameter in octet 2 of the Standard Diagnosis indicating the need for a new run up (parameterization, configuration) for the slave.

P6, 6.2.3.2

Process alarm A process alarm signals the occurrence of a trigger con- P5, 8.2.4.1




dition in the connected process, for instance upper limit value exceeded. The alarm type code is 2.

PrmCmdAck This status information is associated with redundant slaves. Please refer to the corresponding PROFIBUS guidelines.

[5]

Pull alarm A slot signals the withdrawal of a module. The alarm type code is 3.

P5, 8.2.4.1

Red Status This status information is associated with redundant slaves. Please refer to the corresponding PROFIBUS guidelines.

[5]

Revision number This diagnosis information provides the revision number of a slave. Usage not recommended.

P6, 6.2.3.18

Slot Address of a (physical or virtual) module (unit) within a slave.

P6, 3.4.4.33

Standard diagnosis The first 6 octets of any diagnosis message within PROFIBUS DP.

-

"Stat_Diag" Flag A synonym for the “Diag.Stat_Diag” parameter in octet 2 of the Standard Diagnosis causing the master – before in data exchange mode - to repeat the diagnosis request until this flag disappeared.

P6, 6.2.3.2

Status Temporal indication of current states and activities within a system or device. Within PROFIBUS DP a diagnosis message without acknowledgement.

-

Status alarm (state change)

A status alarm signals a change in the state of a module, for instance run, stop or ready. The alarm type code is 5.

P5, 8.2.4.1

Status message A status type whereat a special slot based information can be transferred to the master. Prior to implementation please contact the PNO office.

P5, 8.2.3.2.4

Status model types The following status model types *) are defined: • Status message • Module status • DxB Link status (DP-V2) • PrmCmdAck (Redundancy) • Red Status (Redundancy) • Manufacturer specific

*) GSD file contains: "DPV1"=1

P5, 8.2.3.2.4

P6, 6.2.3.8

System diagnosis The System Diagnosis within a DP-master (Class 1) re-flects the state of all DP-slaves assigned to it. The state itself is a one-bit-information for each DP-slave, which is set to the value 1 if a diagnosis information is recognized and reset to the value 0 after the MS0 communication is successfully re-established. See the reference for more details.

The system diagnosis of a host (e.g. PLC) comprises many more states such as cycle time monitoring, pro-gramming errors and alike.

P5, 8.2.6

Update alarm An update alarm signals the change of a parameter in a module e.g. by a local operation or a remote access. The assigned value shall be 6.

P5, 8.2.4.1

[Value] Qualifier Qualifiers are values usually associated to measured [9]



quantities e.g. the specific trustability (good, uncertain, bad), the exceeding of limits, the unavailability due to failures, etc. Together with the measurement value they are transmitted in a cyclic manner. Problems may arise if device and process information is intermingled within qualifiers.

Warning See “Predictive diagnosis”. -

See IEC 61158 for further terms and definitions.

2.2 Standards

IEC 61158-5:2003, Digital data communications for measurement and control – Fieldbus for use in industrial control systems - Part 5: Application Layer Protocol Specification

IEC 61158-6:2003, Digital data communications for measurement and control – Fieldbus for use in industrial control systems - Part 6: Application Layer Service Specification

IEC 61784-1:2003, Digital data communications for measurement and control – Part 1: Profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems

IEC 61804-2:CDIS, Function blocks (FB) for process control - Part 2: Specification of FB concept and Electronic Device Description Language (EDDL)

2.3 Abbreviations

Ack Acknowledgement

Add Address

Cfg Configuration

Cmd Command

DCS Distributed Control System

DSAP Destination Service Access Point

DxB Data Exchange Broadcast

GSD General Station Description

ID Identifier

I/O Input / Output

IsoM Isochronous Mode

LED Light emission diodes

LSB Least Significant Bit

MBP-IS Manchester encoded Bus Powered – Intrinsically Safe

MS0 Cyclic Master Slave communication (master class 1)

MS1 Acyclic Master Slave communication (master class 1)

MS2 Acyclic Master Slave communication (master class 2)

MSB Most Significant Bit

PC Personal computer, usually running the WINDOWS® operating system

PLC Programmable Logic Controller



Prm Parameter

PDU Protocol Data Unit; here within the fieldbus application layer

RD_ Read

Red Redundancy

Req Request

Rsp Response

SAP Service Access Point

SD Start Delimiter

SDR Station Delay Responder

Seq Sequence

Src Source

SSAP Source Service Access Point

WD Watchdog

WR_ Write



3 Diagnosis scenarios within distributed automation systems

One of the most impressive advantages of fieldbus communication is the possibility for field devices to provide distinct information about failures and errors any time they occur via occasional messages. However, these occasional messages should not stress the determinism of the automation system at all.

Even more important is the possibility to indicate upcoming reliability problems or worn-out situations in order to provide a predictive maintenance. It is important to distinguish between the detection of faults within the electronics or electromechanics of the automation system and those within the manu-facturing process.

Controller

Field device

ManufacturingProcess

Supplies Environmental conditions

Errors Failures

Errors, failures

Figure 3-1 Errors, failures and faults within an automation system

Failures are random defects occurring in field devices due to e.g. weak soldering or due to environ-mental stress (e.g. temperature, torque, pressure, humidity) and in auxiliary devices such as missing power, liquid, gas, oil, etc. supply. Others may occur within the links between manufacturing equip-ment and sensors and actuators (e.g. broken gear), and in communication systems between devices (e.g. broken lines). Failures as a permanent defect usually need human intervention for maintenance or repair.

Errors are more static and are inherent characteristics of the system, as in design or configuration er-rors as well as scrambled bits within a message due to electromagnetic interference.

Faults are unsatisfactory system conditions or states, so failures and errors are different kinds of faults.

Prior to a detailed description of the different mechanisms of PROFIBUS DP for field devices the fol-lowing chapters will give an overview of the levels of troubles and trouble shooting possibilities within a fieldbus based distributed automation system.

3.1 Network level / commissioning

The transition from signal wiring to data transmission via PROFIBUS DP had surely not only been a paradigm shift for the planning, commissioning, and normal operation phases of a project. It soon be-came obvious that the simple signal testers of former times had to be supplemented by new trouble shooting means.

3.1.1 Fieldbus installation

During the installation of fieldbus components the following critical areas for diagnostics are con-cerned:



• Wire-break of the transmission lines • Break of the shielding • Wrong or missing terminating resistors at the end of segments • No power supply for the terminating resistor circuit • Short circuits between the transmission lines A and B or A/B to the shielding • Detection of reflexion points (e.g. spur = branch line connected to a segment) • Exceeding maximum segment lengths for a particular transmission rate

For these kinds of diagnostics several handheld devices are available on the market. See www.profibus.com.

3.1.2 Bus signals

The next level of diagnostics is dealing with the quality of the bus signals: • The minimum differential voltage between A and B line • Minimum rectangular signal characteristic • Internal 5V power supply • RTS signal

Most of the handheld devices mentioned in chapter 3.1.1 are supporting these diagnostics. See www.profibus.com.

3.1.3 Reachable participants

The next level of diagnostics is dealing with the determination of available participants on a PROFIBUS segment. A so-called "lifelist" informs about the devices connected to the bus segment and the associated addresses. One common error is the duplication of addresses for field devices which cannot be detected automatically. Most of the handheld devices mentioned in chapter 3.1.1 are supporting the "lifelist". See www.profibus.com.

3.1.4 Network traffic / bus monitors

Usually the diagnostic means of handheld devices and/or engineering tools are sufficient to detect the faults of a bus installation. More during the development phase of a field device it may be necessary to use a so-called "bus monitor", that records the sequence of messages for a particular period of time and allows displaying the contents of the messages together with an associated timeline. Various trig-ger possibilities enable the finding of even very difficult timing problems. A typical trigger condition for diagnosis messages is e.g. “383Ch”.






Figure 3-2 One typical display of a PROFIBUS monitor program

Figure 3-3 Another typical display of a PROFIBUS monitor program

There are several sophisticated "bus monitor" software products for standard Personal Computers in conjunction with PROFIBUS DP interfaces available on the market. See www.profibus.com.

Following an overview on the functionality of such a typical monitor program:

Basic Functionality:

RS485-Interface Connector to a PROFIBUS segment with physical RS485-transmission

MBP- Interface Connector to a PROFIBUS segment with physical MBP-transmission

Data Export Export of recorded data frames in different data formats (ASCII, EXCEL)

Remote Access Access of the monitor from a remote station




Online-Functionality:

Automatic baudrate scanning Automatic Identification of the baudrate during recording

Time stamping Recording of an absolute time stamp created by hardware for each ob-served data frame

Error detection Detection of faulty data frames while recording

Permanent recording Permanent recording that stores observed data frames without interruption

Recording filter Depending on their properties (destination-/source-address, destination-/source-SAP, service-PDU) only particular data frames are recorded.

Trigger filter with start condition Depending on the properties of an observed data frame (destination-/source-address, destination-/source-SAP, faults in data frames) recording is started.

Trigger filter with stop condition Depending on the properties of an observed data frame (destination-/source-address, destination-/source-SAP, faults in data frames) recording is stopped.

Lifelist All devices connected to the bus are listed

Log book Modification of the live list and modification of the bus characteristics are logged together with a time stamp.

Error statistics Statistic evaluation of errors or breakdown of devices, faulty data frames, frame repetition

Communication statistics Statistic evaluation of bus communication with respect to user data, bus load, token-rotation-time, data bytes per ms.

Recording of device specific information Recording of diagnosis data, parameterization data, configuration data, cyclic data per slave

Multimonitoring with synchronization Synchronous recording of multiple PROFIBUS segments (Application in redundant systems).

Offline Functionality:

Layer-n decoding Depending on a selected communication layer (DLL, FAL, profile specific) the recorded data frames are decoded

Presentation filtering Depending on its properties (destination-/source-address, destination-/source-SAP, service) only a subset of the recorded data frames are shown.

Search Depending on its properties (destination-/source-address, destination-/source-SAP, service) the set of recorded data frames is scanned for par-ticular data frames.

Time unit There are different time units selectable (bit time, micro seconds)

Time relation Different time relations (absolute time, time difference between start of succeeding data frames, time difference between end/start of succeeding data frames) are selectable.

Graphical representation of process val-ues

Graphical representation of process values out of cyclic data transmission.

3.2 Online diagnosis / operation

Errors and failures are also occurring at production time, causing a downtime. In order to achieve a high availability (= uptime / uptime + downtime) short maintenance and repair times are necessary. A precondition is immediate diagnosis information for the operators or the maintenance staff as soon as



the fault occurs. Provision is made with PROFIBUS DP automation systems to support several levels of diagnosis reporting, as we will see in further chapters.

3.2.1 Diagnosis repeater

With the help of sophisticated network devices, so-called "diagnostic repeaters", the following detec-tions are possible within permanent installations:

• Automatic determination of the network topology and its presentation via engineering tools • Location of cable defects via measurements of signal reflection • Disruption of transmission lines A, B • Short circuit from A, B to the shielding • Missing terminating resistors • Sporadic errors

Distance to disruption

Segment 2

Segment 1Diagnosis

1 2

Diagnosisrepeater

Master(Class 1)

SlaveSlave

Figure 3-4 Diagnosis repeater to detect network problems

Please check www.profibus.com for available products.

3.2.2 Field device diagnosis

This area is the main focus of this document. The next two chapters are to provide an overview on the different possibilities supported by PROFIBUS DP.

The first level of diagnosis with field devices is LED indicators. No guidelines from PNO had been pub-lished so far. Thus different implementations are out in the field and can be more confusing than help-ful. This document thereinafter will provide a specification for the following LEDs (see chapter 4.3):

• Power supply • Bus failure (configuration, parameterization) • System failure (device, module, channel)

It is highly recommended to provide LEDs for binary input and output signals. The assignments should be (hint: NAMUR recommendations NE44 [6] suggest yellow LEDs):

• Green LED "ON": signal > 0 Volt or closed contact, corresponding to a logical "1", • Green LED "OFF": signal = 0 Volt or open contact, corresponding to a logical "0".

. Once the diagnostic means inside a device had been able to detect a defect, an appropriate diagno-sis information can be sent to the PROFIBUS DP master while in normal data exchange mode (MS0, see 4.8 and Figure 3-5). This special message affects the system and user program inside a control-ler (e.g. PLC). In the simplest case the machine can be stopped to avoid further damage. The user also can take control of the reaction via special programming.




Within the network view of engineering tools or process monitoring special marks on the device icons can indicate troubles with the associated device (see Figure 4-2).

The special diagnosis message contains some standard information (6 octets) covering the communi-cation, configuration and parameterization level of a field device and usually plays a role during run-up of a field device. Extended diagnosis information that covers faults within the technological parts of the field device may be provided through

• “Module (identifier) diagnosis overview” (indicating the faulty modules) • "Module status" (missing, wrong spare parts, etc.) • "Channel diagnosis within modules" (process connection, power failure, line break, etc.) • or specialized diagnosis information (publisher/subscriber errors, redundancy, etc.)

If the PROFIBUS master is not able to process the content of the arriving diagnosis messages just in time an overwriting of the information in the diagnosis buffer of the master may happen. This disad-vantage can be avoided by using "alarms" described thereinafter.

Within the process industries it is the main focus of the control program to keep the process running and controllers for these kinds of application shall use diagnosis information only to forward it to op-erators or maintenance staff. Devices for process automation usually provide two main different ways of indicating faults. One comes directly as an extension to the measurement value that is transmitted cyclically to the control program and is called value qualifier. This value qualifier comprises some bits indicating e.g. uncertainty of the measurement value, which very often may happen temporarily. Thus a user program can be enabled to stabilize the process as long as possible without further human in-teraction.

The other way is an extension to the diagnosis message procedure, the "alarms". Here the field de-vice stores diagnosis information within several subsequent records within a diagnosis buffer and initi-ates a normal diagnosis message. The alerted PROFIBUS master then starts reading the diagnosis information out of the diagnosis buffer via acyclic MS1 communication services (chapters 4.7 and 4.8).

3.2.3 Diagnosis messages coming and going

It is part of a good diagnostics design whenever a "coming" diagnosis message is followed by a "go-ing" diagnosis message after repair, i.e. just a standard diagnosis message that turns off the “Ext_Diag” flag (chapter 5.4.1). Complex devices require a more sophisticated mechanism based on state machines that explicitly define these situations. Some diagnosis types provide a certain specifier for this purpose (chapter 5.4.5 and 5.6). It is up to profile working groups to define the behavior and the state machines if necessary.

3.2.4 Variable language support

Immediate diagnosis information for operators and maintenance personal may be good but not good enough if they are displayed in a foreign language. Thus PROFIBUS DP provides for language sup-port via GSD. The manufacturer of a field device generates the reference texts for the codes of the diagnosis information together with some “help” texts on how to fix a certain problem in the appropri-ate language and GSD file. The engineering and process monitoring tools take this language depend-ent information out of the GSD and associate it to the received diagnosis code at runtime. Some codes are already predefined and monitoring tools may “know” the texts already so that the user can save engineering effort.

3.2.5 Testability

One of the major handicaps for diagnosis implementations is to force devices into the defined error or failure state in order to generate the particular diagnosis message. Normally this is not possible with-out the destruction of some parts (wire break, memory error, etc.) or without quite some effort (voltage underrun/overrun, overtemperature, etc.). It is very helpful to already incorporate these considerations into the design of a device.

3.2.6 Complex field devices

Field devices may have high levels of complexity and the functionality of the available diagnosis means may look limited (e.g. missing interactions). In this case PROFIBUS DP recommends to make use of the DTM technology (Device Type Manager). The manufacturers who already have an existing



individual PC program that can be connected to the device on a proprietary basis (e.g. RS232 inter-face) may upgrade their software to a DTM. This DTM supports the FDT communication interface to engineering and process monitoring tools on PROFIBUS DP or Ethernet in a standardized manner and still supports the proprietary interface via adapters/gateways and corresponding Comm-DTM. This way the manufacturer of the field device can offer unlimited information via the acyclic MS2 communi-cation of PROFIBUS DP (chapter 4.8).

Alternatively interpreter programs for electronic device descriptions (EDD) can be used directly as master class 2 applications or in form of a DTM. Similar to the General Station Description (GSD) an EDD contains ASCII text describing the features of individual parameters of the field device and how they can be manipulated. Furthermore, besides other things, it comprises dedicated diagnostic means for the individual technology of the device.

3.2.7 Data exchange broadcast

In its version DP-V2, PROFIBUS DP supports slave to slaves communication (Data Exchange Broad-cast) via the publisher subscriber principle. In order to diagnose faulty situations like publisher sub-scriber dropouts or data length mismatches in such an operational mode, special diagnosis features are specified (chapter 5.5).

3.2.8 Isochronous mode (e.g.drives)

In its version DP-V2, PROFIBUS DP also supports the synchronization of the processing cycles of field devices (slaves) via broadcast messages (global control). The tremendous timing requirements do not allow the normal diagnosis message to use the data exchange communication instead. A spe-cial delayed diagnosis mode within a master class 1 for isochronous mode (Figure 3-5) shall be used in these cases. I.e. the cyclic data exchange is not affected; all slaves are receiving actual data just in time. The diagnosis request from the master is sent within the same cycle but happens during the con-figured period of time for acyclic data exchange. Masters for DP-V2 shall support this feature. No ac-tions needed for slave implementations.

Bus cycle n Slave1 Slave2 Slave3

Cyclic accessof master class 1

Acyclic accessphase of master

class 1

Normal diagnosis:

Bus cycle n+1 Slave1 Slave2 Slave3

Slave 2 indicates diagnosisto its master class 1

Master class 1 receives diagnosismessage instead of process data

Bus cycle n Slave1


Figure 3-5 Delayed diagnosis mode for time critical applications

Hints: If there is already enough time the diagnosis request of slave 2 may be executed in bus cycle n within the acyclic access phase of master class 1. It may be delayed further if there is no time in bus cycle n+1.

Slave2 Slave3

Delayed diagnosis mode:

Bus cycle n+1 Slave1 Slave2 Slave3

Slave 2 indicates diagnosisto its master class 1

Master class 1 receives diagnosismessage during the configuredacyclic phase of the bus cycle,sharing this time frame with theacyclic accesses of the master


Slave2



3.2.9 Slave redundancy

The redundant operation of slaves is specified in PROFIBUS guidelines [5]. The diagnostic of this op-erational mode is supported by special diagnosis messages (Chapter 5.1).

3.2.10 System diagnosis

The online diagnosis information of slave devices is collected and managed by a PROFIBUS DP mas-ter class 1 (Chapter 4.1). It is the task of the computer (in automation usually a PLC or a PCS/DCS) that hosts the PROFIBUS DP master to integrate this information into its own system diagnosis that may comprise additional faults like various types of programming errors, program timeouts, memory faults, etc.

3.2.11 Process diagnosis

These faults are outside the scope of PROFIBUS DP diagnosis. However, they are mentioned in this chapter to complete the view on diagnostic means in distributed automation.

One possibility to deal with process faults or deviations is to use value qualifiers as mentioned earlier in this document. Cases like "value limit overstepping" or "value dependability" can be treated accord-ing to the individual process needs.

For discrete manufacturing processes it is possible with the help of special engineering tools to detect process faults like "switching events did not occur within expected times", "interlocks are not com-plete", etc. Please contact system manufacturers for product details.

3.2.12 Message flooding / time stamping

It was mentioned in chapter 3.2.2 that subsequent diagnosis messages may be overwritten in master systems and that the alarms can be used to overcome those problems. However, the strongly coupled nature of processes may cause a flood of diagnosis messages even if there was only one root cause. In terms of time the root cause incidence can be expected to be the first within the chain. This is why time stamping comes into the game. If all the field devices are carrying the same clock time and are putting a time stamp on each and every diagnosis information, it is much easier to find the root cause.

A detailed description is contained in [4].

MS0

MS1

Master

Slave

Variable

Variable

Variable

Alarm

Alarm and eventbuffer

Figure 3-6 Time stamping of alarms and events

3.2.13 Acknowledgements

The alarm mechanism allows for optional acknowledgement messages to be sent by the host applica-tion to the slave (Chapter 5.3). This guarantees processing of each and every individual diagnosis in-cident of the slave if required.



3.3 Maintenance / repair

During maintenance or repair it often happens that parts are mixed up. In order to track down prob-lems temporary program changes are made or auxiliary parts are integrated. This can cause timing problems as all the field devices on the bus are sharing one cable and normally one controller. If the timing limits had been close, the system may fail. Good engineering tools provide sufficient means to measure bus cycle times and jitters and monitor program cycle times.

3.3.1 Wrong or missing parts

The diagnosis means of PROFIBUS DP provide special module status reports to indicate wrong mod-ule types in place or missing modules based on an analysis of the configuration identifier that is sent to the slave with the “Chk_Cfg” message (Chapter 5.4.3).

3.3.2 Localization

Diagnosis messages shall be associated with physical addresses and not with symbolic information. Without such an indirection it is much easier to identify the troubled device, module or channel. For the geographical localization of the device the I&M functions of PROFIBUS DP can be used (TAG_location) [11].

3.4 Preventive Maintenance

The microprocessors of nowadays field devices are powerful enough to periodically carry out test rou-tines in order to find out the tendency for corrosion, soiling, worn-out indications, etc. With the help of such predictive diagnosis information a preventive maintenance is possible thus reducing downtimes of an automation system. In this case it is more appropriate to call this information "warnings" as no error or failure did occur and the machines or processes shall not stop or shall not be impacted at all. PROFIBUS DP makes no distinctions between diagnosis means and warnings. The definitions are up to profile working groups or the host/system manufacturer.



4 Possibilities of fault indications for field devices (Slaves)

This chapter demonstrates how a field device (slave) is embedded within a complete automation sys-tem including controllers, engineering tools, diagnosis panels, and process monitoring stations. It shows the escalating diagnosis methodologies of PROFIBUS DP and how the information can be dis-played to the user. Not in the scope of PROFIBUS DP but not less important are the highly recom-mended detailed LED functions for field devices or other indicators.

4.1 The main diagnosis model of PROFIBUS DP

It should be noted that the IEC 61158 standard lists many possibilities of diagnosis reporting of inci-dents for PROFIBUS DP. Figure 5-1 in chapter 5.1 presents an overview of all kinds of diagnosis types and how they are related to each other. Some of these types are for special purposes only. This chapter is to sort out the main types that are well accepted and are supported by most of the master and system platforms on the market (Figure 4-1).

OperatorMaintenance Process MonitoringSystem

Ethernet TCP/IP

PROFIBUS DP

Controller Master class 1

Diagnosis message:Standard +Identifier +

Module +Channel

Alarms + acknowledge

Field deviceSlave

AlarmHistory

Engineering Tool,Diagnosis Panel

Process

Engineering Tool,Diagnosis Panel

PCMaster class 2

Time stamping

GSD

GSD

No notification, just Get_Diag

*)

*) Diagnosis messages embeddedwithin cyclic data exchange uponslave request (multiplex)

Figure 4-1 Data flow for diagnosis, status, and alarms

Normally the main station that collects diagnosis information from all the slaves is a controller (PLC or Soft-PLC) hosting a PROFIBUS master class 1. The incoming diagnosis information in form of diag-nosis messages is usually starting service routines or function blocks that may be used to influence the production via corresponding user programs or that may be forwarded to diagnosis panels or process monitoring systems. In order to detect the root cause of several diagnosis messages at one point in time usually either the controller (host) or the slave itself is time stamping the diagnosis infor-mation. Most of the systems nowadays are using controller software for time stamping due to its sim-plicity and cost effectiveness.



It is part of a good design practice for a field device (slave) to structure a diagnosis message in a standardized hierarchical manner. In this case host and system manufacturers are enabled to provide standard routines and function blocks and thus saving time and cost for the user. This guideline se-lects preferred mechanisms and recommends structures that suit most of the slave technologies. This structure consists of a standard block of 6 octets that cannot be influenced by the technology program of a device. This diagnosis information manages the correct run-up until cyclic data exchange. A block of information should follow that carries the diagnosis overview of modules (usually corresponding to a configuration identifier). Thus it is called "Identifier Related Diagnosis". Each and every module is represented by one bit. A "1" indicates a fault within the corresponding module. The next following block provides a more detailed status of the modules ("Module Status") of the device that is fed by an analysis of the configuration within the device due to a "Chk_Cfg" initiative. Two enumerated bits represent each and every module with the following meanings: module ok, invalid data due to a fault, wrong module type, or no module in place. This could be the minimum diagnosis of a device and would be enough to support overview displays. Figure 4-2 shows the comfortable network view of an engineering tool with slaves, notifying faults (red marks in the upper left corner).

Figure 4-2 Network view with slaves notifying faults

Within diagnosis panels the view may be simpler but not less informative (Figure 4-3). The green fields indicate correct working slaves; the yellow fields indicate malfunctioning slaves and the red boxes rep-resent configured slaves that do not respond.

006

030

068

090

110

Slave diagnosis overview Affected slaves 5

MissingMalfunctionSlave ok

Diagnosis Panel

Figure 4-3 Diagnosis overview of a panel display

The module status information is not enough for a user to fix a problem. The module status block of the diagnosis message thus shall be followed by one or more "Channel Related Diagnosis" with de-tails of a problem. This type of diagnosis focuses on the majority of failures within I/O channels and standardizes the diagnosis messages such as "short circuit", "undervoltage", "overvoltage", "over-load", "overtemperature", "wire break", "upper limit value exceeded", "lower limit value underrun", "er-ror due to e.g. EMI" via assignment of fixed numbers (1-9). There is no need for a device manufacturer to define these standardized diagnosis texts within the GSD file. Diagnosis reporting systems (panels,



etc.) shall provide these predefined texts automatically when a slave sends channel related diagnosis messages with the numbers 1-9. Manufacturer specific types are possible (16-31). In this case the GSD file shall contain corresponding diagnosis definitions (GSD keywords: "Channel_Diag" and "Channel_Diag_Help"; see chapter 7.2.1) [8]. For details of the channel related diagnosis see chapters 4.5 and 5.4.4.

Figure 4-4 shows the recommended structure of the diagnosis message of a physical or virtual modu-lar slave. For each of the modules out of order within the "Module Status" block a "Channel related Diagnosis" block shall be created.

Standard DiagnosisBlock

(6 octets)


(6 octets)

Identifier Related DiagnosisBlock

(maximum total of 32 octets)



Provided by the "communicationstack".

Provided by device technology for any identifier / module in caseof failure.

Module StatusBlock


Module StatusBlock


Channel Related DiagnosisOne or more blocks

One block per affected channel(3 octets per block)



Provided by device technology for any module as status infor-mation.

Provided by device technology for channels in case of a fault.Non standard definitions and helptexts via GSD entries.

Figure 4-4 Structure of recommended diagnosis messages

With the help of this channel related diagnosis more details can be displayed on panels and process monitoring screens (Figure 4-5).



DP master addr. 1

DP slave addr.

Station status

Device ID

Module number

Channel number

4 Module status

0

Detailed diagnosis Affected slaves 5

Channel type

Channel fault Short circuit

Fault

068

Slave malfunction

4

106A

Input

Diagnosis Panel

Channeldiagnosis

Help check LED, check wiring, replace sensor

(max. 32 characters)

(max. 256 characters)

GSD

Diagnosis textand help text

Modulstatus

Figure 4-5 Detailed channel diagnosis

It is essential for good diagnosis information to not only report a fault description but to provide sug-gestions on how to fix a certain problem. Since version 5.0 of the GSD specification [8] it is possible to specify additional HELP texts for each channel related diagnosis entry (Chapter 7.2.1).

The methods described so far are not sufficient to support the diagnosis of more specialized devices such as diagnosis repeaters, scales, bar code readers, transponders, etc. In these cases the alarm type Diagnosis Alarm offers a more flexible and individual method instead of the channel related di-agnosis (Chapter 5.4.5 and 7.2.2).


(6 octets)


(6 octets)





Provided by the "communicationstack"

Provided by device technology for any identifier / module in caseof failure (optional)

Provided by device technology for any module as status infor-mation (optional)

Provided by device technology for individual cases of faults.Defined via GSD entries.

Module StatusBlock


Module StatusBlock


Diagnosis Alarmsor

(Status Messages)One or more blocks


Diagnosis Alarmsor

(Status Messages)One or more blocks


Figure 4-6 Structure of the recommended diagnosis for special technologies

It should be noted that the diagnosis alarms require extraordinary support from the master or host as will be described in chapter 5.3. Alternatively, it is recommended to use Status Messages instead



(chapter 5.4.5 and 9.2). The diagnosis information can be the same. Only the guarantee of delivery may be affected.

According to Figure 4-6 the diagnosis alarms or status messages may replace the channel related diagnosis. The GSD file of the corresponding device shall contain "DPV1=1".

For Profile Working Groups the IEC 61158 standard describes several possibilities within the individ-ual diagnosis types (usually marked with "manufacturer specific" or "profile specific") to define specific coding for device families in order to facilitate programming efforts and to avoid confusion of the cus-tomer.

4.2 Diagnosis via master class 2

A diagnosis panel or engineering tool connected directly to the PROFIBUS DP as a master class 2 can also directly request ("connectionless") diagnosis information out of the slaves at any time (poll-ing). However, this will not impact the normal diagnosis procedure between the master class 1 and its slave. A master class 2 cannot get any notification from a particular slave in case of a diagnosis inci-dent.

4.3 Device Displays

Many problems with automation equipment can be fixed just by watching the LED indicators of the bus interface of field devices. However, many different implementations will confuse the user and thus are not that helpful. Therefore, whenever appropriate the following definitions shall apply for PROFIBUS DP slaves.

The LED "SF" (System Failure) can be derived directly from the "Ext_Diag"-Flag of a diagnosis mes-sage (chapter 5.1).

A slave remaining in the "Wait on Parameterization" state (chapter 5.2) after Power-On shall turn on the LED "BF". The LED "BF" (Bus Failure) shall be switched to "blinking" mode if any of the diagnosis bits within the standard part of a diagnosis message (first 6 octets) is set (except "Ext_Diag"-Flag).

Product specific LEDs may be added as needed. Application profiles may specify special indications (e.g. PROFIsafe, RIO-for-PA).

The definitions are in most parts compliant with NAMUR recommendations NE44 [6].




LEDs

SF (red)

BF (red)

ON (green)

Meaning Cause

Off Off Off No power

On or Off

On On No connection to another device

Criterion: no data exchange

- Bus disconnected

- Master not available / switched off

On or Off

Blinking 1)

On Parameterization fault, no data exchange

Criterion: Data exchange correct. However, the slave did not switch to the data exchange mode.

- Slave not configured yet or wrong configu-ration

- Wrong station address assigned (but not outside the permitted range)

- Actual configuration of the slave differs from the nominal configuration

On Off On Fault within slave

Criterion: slave in data exchange mode

- At least one diagnosis message within the slave. The device is within the data ex-change mode.

- Improper station address assigned. The slave is in power-on state.

Off Off On Data exchange. Slave and operation ok.

Legend:

1) The blinking frequency is 0.5 Hz. NE44 and EN 60073 are recommending 1.4 Hz to 2.8 Hz.

Minimal indication time is 3 sec.

Figure 4-7 Control definitions for the LED indicators

4.4 [Value] Qualifiers

In process automation the cyclically exchanged process analog I/O data may comprise so-called value qualifiers, indicating the current quality of the measurement value or input signal: good, uncertainty, limits exceeded, etc. Ideally these qualifiers shall only be able to indicate deviations from normal operation such that a programmer is enabled to optimize the user program for high availability. That means the program shall automatically react in the right direction to stabilize the process (e.g. the us-age of the latest "good" value or replacement values instead). The advantage of qualifiers is the syn-chronism of the qualifier and its measurement value.

However, individual errors or failures that need immediate maintenance actions by service personal should not be reported via qualifiers as this path is not supported for the propagation of the information to process monitoring equipment. Another reason is even more important: The qualifier is a permanent burden for both the cyclic data transmission across the fieldbus and the cyclically running PLC pro-gram. The qualifiers are not standardized within PROFIBUS in general but within some application profiles (PA devices, weighing and dosage systems, RIO for PA). Within the profile “PA Devices” value qualifiers are called “Quality Code”.

Measurement value(e.g. Float, 4 Byte)

Measurement value(e.g. Float, 4 Byte)

Qualifier(e.g. 8 bit)Qualifier(e.g. 8 bit)

Figure 4-8 Example for a value qualifier

The value qualifier indicates the quality of the measurement value as a result of the evaluation of the signal chain in the field device (transducer for physical quantities, signal conditioning, linearization, etc.). It can be good or uncertain with optional additional details. The information in the qualifier is fol-lowing the actual process situation. The qualifier history is neither stored nor buffered in the slave de-



vice in contrast to alarm messages. There is no acknowledgement from the master about the recep-tion of the value qualifier and there is usually no presentation of the qualifier on monitoring systems.

The NAMUR organization published recommendations in its NA 064 "Status Signals of Field Instru-ments" [7]. The PROFIBUS organization is going to publish proposals on how to reduce the volumi-nous variety of different qualifiers to a system of a few “colored” ones. Following the current state of the proposal that is still undergoing some further discussions:

“Green” Process value ok. No action required.

"Orange" Process value has limited validity. Low priority maintenance required within the next e.g. 7 days or the next scheduled date (parameter assignment).

“Yellow” Process value has limited validity. High priority maintenance demand within e.g. the next 24h (parameter assignment).

“Red” Process value invalid. Immediate maintenance necessary due to failure.

“Blue” Device under inspection (local control), e.g. simulation, calibration, etc.

"Black" Device passivated (no function)

For upward compatibility to the existing devices it is planned to provide mappings from the current qualifiers to the new “color system”. This may be provided in monitoring systems first.

Most of the input and output signals within factory automation are binary values. Qualifiers are not common in use due to cost and performance considerations. Sometimes single bits are associated to indicate wire breaks.

4.5 Impact of diagnosis messages on the automation system

PROFIBUS DP provides a special diagnosis feature for failures and errors like wire break, power sup-ply shutdown, memory failure, short circuit, etc. that need support of a maintenance person. In this case PROFIBUS DP is temporarily using the cyclic communication channel to transmit special diag-nosis information, which is stored in separate buffers and then processed within the master class 1. In case of standardized diagnosis data structures like it is recommended and promoted in this guideline system manufacturers are enabled to provide a library of standard system software. This software of-fers standardized interfaces and may help to automatically propagate the diagnosis information to monitoring systems where it can be decoded according to instructions from the GSD file of the corre-sponding field device. Tremendous engineering cost savings are the benefit of this technology.

However, the severity of the cause that creates a certain type of diagnosis message should be con-sidered very carefully. Its intervention is quite vigorous. The device indicates with the diagnosis mes-sage that it cannot maintain its intended functionality anymore. It is up to the programmer of the user program to select the means for a reasonable reaction. This may be a specific exception handling, an acknowledgement after operator intervention or a notification of other system components.

Another problem may emerge from the independent communication channels of I/O data or process values and diagnosis information. On the user program level there is no correlation between the show-up of the one and the other, i.e. the data consistency in respect to time is not guaranteed by the mechanisms.

The diagnosis information is first of all a result of a permanent or periodic check-up of the field device, the connected process, or the local environment. In contrast to the value qualifier that also indicates the “good” situation, the diagnosis data are event or trigger based. In case of a deviation from normal behavior or due to certain trigger conditions diagnosis messages are transferred to the master class 1 only once. For this purpose a special PROFIBUS DP service is used, called “Slave_Diag” (chapter 5.2).

The diagnosis data are usually coded and in binary format. This allows short messages, good per-formance, easy processing, and language neutrality. The propagation to monitoring systems means transformation of the codes to the needs of operators and maintenance persons, i.e. graphical and/or textual information. These texts and graphic symbols are taken from the corresponding GSD file dur-ing the engineering phase of a project. GSD files may comprise several foreign language versions.



4.6 Semantics of diagnosis messages / usability Unfortunately, it is not common practice to test the usability of the manufacturer specific diagnosis in-formation of field devices. The feedback from customers usually comes too late. So, at least the fol-lowing considerations should be taken into account during the development of the device:

• The user appreciates to be informed about the reason or cause of a faulty situation • He/she even more appreciates to get directions about what to do in this particular situation.

PROFIBUS DP provides the following mechanisms in order to support these intentions. A manufac-turer can define specific fault messages via GSD entries (e.g. channel related diagnosis or diagnosis alarm). Those should describe the reason or cause of the fault if possible, and should be short and easy to understand. Furthermore these entries can be supplemented by concrete remedy instructions (directions) entered into the GSD via "help" texts (chapter 7.2). It should be noted that it is not possible to define formal parameters within the GSD file that will be replaced in the diagnosis messages by actual parameters. Example of a diagnosis message text with a formal parameter: <Temperature exceeded by [formal parameter] degrees Celsius>.

4.7 Time-stamping

Failures or errors in a machine or production system can generate a flood of diagnosis messages from different system parts and field devices. It may happen that failures are occurring in a specific order, which can’t be transferred just in time. Diagnosis data can be lost, and the order of the messages can’t be recognized by the automation system. The investigations about the primary fault and its direct con-sequences require for the diagnosis messages additional information about the exact clock times of their incidences.

4.7.1 Clock time synchronization To provide a consistent clock time in the whole system a time master (class 1 or class 2) controls all device clocks in the system using the MS3 clock time synchronization protocol (chapter 5.2). The ac-curacy of the clocks is expected to be better than 1ms within the clock refresh cycle time (e.g. 24h). This time period can be parameterized in the time masters.

4.7.2 Time-stamped Alarms and Events

According to [4] devices are enabled to extend the basic alarm mechanism of PROFIBUS DP (chapter 5.6). Several time-stamped alarms can be stored in a buffer of the device in the order of its occur-rence. After the notification of the master class 1 via normal diagnosis mechanisms, the master can retrieve the time-stamped alarms via acyclic read services (MS1). Each alarm may be acknowledged by the master class 1 thus guaranteeing the processing of each and every alarm (chapter 5.3).

Besides alarms another type of information can be reported to the master, the events. Events contain special information such as time-stamped signal values that are sampled and stored in an event buffer whenever a certain trigger condition is reached. The event buffer may also represent a so-called trend-block of equidistantly sampled values.

It should be noted that time stamping is not yet used by any of the profile working groups. Prior to an implementation please contact your profile working group or the PNO business office.

4.8 Processing of diagnosis information

Several levels of processing complexity and comfort exist.

4.8.1 DP-V0/V1

Simple devices are exchanging I/O data or process values (PV) and value qualifiers finally with the so-called process image of a PLC. The user can process them e.g. with the help of programming lan-guages such as those defined in IEC 61131-3 (ladder diagram, function block design, structured text, etc.). The diagnosis information usually is provided within separate operating system tasks or service routines. Some system/host manufacturers are providing routines or function block libraries for stan-dardized diagnosis structures as per description in this guideline.



Device Type

Manager

Device Type

Manager

PROFIBUS DP

MS0

PROFIBUS DP

MS2 Communication Platform

PROFIBUS

MS2MS0CommunicationPlatform

ProcessImage

Field-Device-Tool (FDT)

Programmer'sInterface (API)

Field device(Diagnostic means)


Master Class 2Master Class 1

Diag-nosis

Slave

User ProgramUser ProgramQC DiagI/O

EDDInterpreter

QC = Quality Code

Figure 4-9 Process image and diagnosis information (separate)

4.8.2 DP-V1

Acknowledged alarms as well as time-stamped alarms and events are tied up to the existence of acyclic MS1 read and write services.

Systemspecific

Systemspecific

PROFIBUS DP

MS0 MS1

PROFIBUS DP


PROFIBUS

MS2MS1MS0CommunicationPlatform

PROFIBUS DP

MS0 MS1

PROFIBUS DP


PROFIBUS


ProcessImage

Manufacturerspecific





Diag-nosis

Slave

User ProgramUser ProgramQC Diag "Buffer" AckI/O

Device Type

Manager

Device Type

Manager


EDDInterpreter

QC = Quality Code

Figure 4-10 Diagnosis using acyclic read/write services



The way programmers can access the acyclic services had not been standardized until recently. This may be one reason for the previous reluctance of the profile working groups to use the alarms more extensively.

4.8.3 Standardized software interfaces (IEC 61131-3)

With the advent of the PROFIBUS guideline “Communication and proxy function blocks according to IEC 61131-3” [12] this situation has been changed dramatically. More and more profile working groups take advantage of the acyclic MS1 read and write services in their designs and portable generic soft-ware based on the “Structured Text” programming language is going to be developed. E.g. profile working groups “PROFIdrive”, “PROFIsafe”, “Ident Systems” and “Weighing and Dosage Systems”.

PROFIBUS DP

MS0 MS1

PROFIBUS DP


PROFIBUS


PROFIBUS DP

MS0 MS1

PROFIBUS DP


PROFIBUS


ProcessImage

Comm. FB(IEC 61131-3)





Diag-nosis

Slave

User Program (incl. Proxy FBs)User Program (incl. Proxy FBs)QC Diag "Buffer" AckI/O

Device Type

Manager

Device Type

Manager


EDDInterpreter

QC = Quality Code

Figure 4-11 Diagnosis using standardized software interfaces



5 Diagnosis mechanisms of PROFIBUS DP The IEC 61158 defines several different methodologies to report status and diagnosis information. In this chapter only the methods are described in detail that are in common use and are recommended according to the master / system profiles. In order to complete the information the remaining methods are supplemented in an annex.

5.1 Overview Figure 5-1 reveals an overview on the defined diagnosis structures of PROFIBUS DP according to IEC 61158-5 and – 6.

PROFIBUS DPDiagnosisPROFIBUS DP

Diagnosis

StandardDiagnosis(Octet 0-6)

StandardDiagnosis(Octet 0-6)

ExtendedDiagnosis(Octets >6)

ExtendedDiagnosis(Octets >6)

DeviceRelated

(00)

DeviceRelated

(00)

IdentifierRelated

(01)

IdentifierRelated

(01)

ChannelRelated

(10)

ChannelRelated

(10)

RevisionNumber

(11)

RevisionNumber

(11)

Alarm Model(0)

Alarm Model(0)

Status Model(1)

Status Model(1)

DiagnosisDiagnosis PlugPlug

ProcessProcess

StatusStatusPullPull

UpdateUpdate

ModuleModule Status M.Status M.

DxB LinkDxB Link PrmCmdAck

PrmCmdAck

Red StatusRed Status

GSD: "DPV1" = 1

Acknowledgement via MS1 No acknowledgement via MS1

Figure 5-1 Overview on PROFIBUS DP diagnosis structures

PROFIBUS DP diagnosis covers the needs of the different hardware and logical structures of modular, virtual modular, compact and complex field devices (Figure 5-2).



Station

Slave Slots 0...244MS0 (cyclic operation)

Channels 0...63

max. 242 Bytes totalper diagnosis message and device

Channel 0

Channel 63

Slots 0...244

Modules

Figure 5-2 Physical and logical structures of field devices

These devices all have in common a PROFIBUS DP communication mechanism usually consisting of an ASIC and “layer stack” software providing the functionality of fieldbus layer 2 and 7. The “Standard Diagnosis” information (first 6 octets of a diagnosis message PDU) provides the indications for all types of run-up faults of a slave (chapter 5.4.1). It can be supplemented within the same message PDU in case the individual technology of a slave wants to report additional faults. This supplement is called “Extended Diagnosis” and may consist of the following parts:

• Device Related Diagnosis (00) • Identifier Related Diagnosis (01) • Channel Related Diagnosis (10) • Revision Number (11)

The existence of a serious fault is indicated within the “Standard Diagnosis” via the Ext_Diag flag (“1”) irrespective of additional "Extended Diagnosis". Usually this flag drives the "SF" LED on the bus inter-face of a field device. After the successful trouble shooting of the serious fault the field device shall send a new diagnosis message with Ext_Diag flag ("0") (Figure 5-8). Extended diagnosis is defined since version DP-V0 of PROFIBUS DP.

The “Device Related Diagnosis” is intended to report about faults of the whole device. Its usage is bound to DP-V0 devices and no more recommended. See “Alarm and Status Model” instead.

The “Identifier Related Diagnosis” is tied to the (configuration) identifier as the representative of a cer-tain module or subunit located within slots of a modular slave. The configuration identifier within the GSD file defines the data structure and data types of the subunit for the cyclic data exchange. For each and every identifier one certain bit is assigned within the “Identifier Related Diagnosis” to indicate a fault or correct function within this subunit or module (chapter 5.4.2). This type of diagnosis shall be provided with any diagnosis message even with no faults.

The “Channel Related Diagnosis” is intended to report about faults of channels within modules. A channel is a subunit of a module of a slave that is connected to process input or output signals (switches, sensors, transducer, bar code readers, transponders, actuators, etc.). Many of the possible faults with channels are common such as short circuit, undervoltage, overvoltage, overload, overtem-perature, line break, etc. Thus PROFIBUS DP already defines those faults within the basic standard but leaving room for profile or manufacturer specific faults (chapter 5.4.4). The profile working group and/or the device manufacturer can describe the latter faults within the GSD file (chapter 7.2.1).

The “Revision Number” is intended to report the revision of the particular slave device. Over the years it turned out to be too restrictive for the complexity of nowadays devices and not detailed enough, e.g. hardware versus software revision etc. The usage of “Revision Number” is not recommended.

Together with the increased functionality of version DP-V1 new diagnosis mechanisms and structures had been added to PROFIBUS DP. They are split into the “Alarm Model” and the “Status Model”. Both are derived from the “Device Related Diagnosis”. The “Alarm Model” comprises the

• Diagnosis Alarm • Status Alarm (state change) • Process Alarm


CNJAZHU

Underline

CNJAZHU

Highlight


• Update Alarm • Pull Alarm • Plug Alarm • Manufacturer specific Alarms

It provides means to overcome the possibility of loss of diagnosis information if the system is flooded with messages. These (optional) means are acknowledgement from an operator or a system program and the possibility to store diagnosis messages within a buffer of the slave, which can be retrieved step by step through acyclic read services (chapter 5.3).

The “Diagnosis Alarm” covers failures and errors of slave technology much like the original “Device Related Diagnosis” but in a more detailed way (chapter 5.4.5). Whenever possible the “Diagnosis Alarm” shall be preferred to “Device Related Diagnosis”. It should be noted that in this case the state-ment “DPV1=1” shall occur in the device’s GSD file. The profile working group and/or the device manufacturer can describe details of the “Diagnosis Alarm” information within the GSD file (chapter 7.2.2).

The “Status Alarm” indicates a change in the state of the module located physically or virtual in a cer-tain slot. Typical states may be run, stop, simulation, calibration, etc. Very sophisticated state charts are developed within the specification “Time Stamps” [4].

The “Process Alarm” is used to notify about an incident in the automated process such as process measurement values crossing upper or lower boundaries. These boundaries can be set as trigger conditions. The “Process Alarm” allows monitoring the process for these trigger conditions, e.g. [4].

The “Update Alarm” is used to notify in the cases where relevant parameters are changed within a module, e.g. [4].

The “Pull Alarm” and “Plug Alarm” is used to notify about changes in the physical configuration of a slave device. Modules can be plugged in and pulled out of a field device (e.g. remote I/O) during main-tenance. The device may recognize a configuration error when executing the “Check Configuration” command message from master class 1 during run-up. There may be no module or the wrong module at a configured slot.

The “Alarm Model” leaves room for manufacturer specific or profile specific alarms. Further details on possible system behavior of alarms may be retrieved in [13].

The “Status Model” comprises the • Module Status (configuration) • DxB Link Status (slave to slaves communication) • Red Status (redundancy status) • PrmCmd Ack Status (redundancy parameterization) • Status Message • Profile and manufacturer specific Status

This model does not support acknowledged diagnosis information. It extends the possibilities of de-tailed status and diagnosis information due to new features of PROFIBUS DP version DP-V2.

The “Module Status” provides a possibility to refine the results of a “Check Configuration” command message from the master class 1. Within standard diagnosis there is only one (Cfg_Fault) flag to indi-cate a configuration fault. The “Module Status” defines two enumerated bits for each and every mod-ule with the following meanings: module ok, invalid data due to a fault, wrong module type, or no mod-ule in place (chapter 5.4.3).

The “DxB Link Status” can be used for the “Link Table” and the “Publisher / Subscriber” version of the data exchange broadcast (slave to slaves communication) of PROFIBUS DP version DP-V2. Link er-rors and link status may be reported per publisher (chapter 5.5).

The “Red Status” and “PrmCmd Ack Status” are tied to redundant operations of slaves [5].

The “Status Message” is a special status model type. Its data structure corresponds directly to diagno-sis alarms. However, it does not require the alarm mechanism in the host/master class1 (see chapter 5.4.5 and 9.2). Slave device may offer "Status Messages" optional to "Diagnosis Alarms".

The “Status Model” leaves room for manufacturer specific or profile specific status.



The recommended general sequence of occurrence within a diagnosis message PDU for an "Ex-tended Diagnosis" structures is the following:

• Identifier Related Diagnosis • Module Status • Channel Related Diagnosis • Alarms or Status Messages

Hint: It is always advisable for device manufacturers to achieve a certificate for PROFIBUS DP con-formity at one of our worldwide test and certification centers (www.profibus.com). One of the many advantages is the help and the additional actual information that can be obtained after application.

5.2 Diagnosis communication

Before the jump in the middle of the details of the diagnosis communication a short introduction to the basic PROFIBUS DP communication will be added in the following for better understanding. PROFIBUS DP is based on a master slave cyclically polling communication system (Figure 5-3). The master class 1 knows its slaves station addresses, the data structures to exchange, and the slave pa-rameters for run-up. Cyclically each slave receives a message with the appropriate data (parameters, or configuration data, or I/O data, etc.) from the master and in turn responds with an appropriate mes-sage (I/O data, or diagnosis information, etc.). If needed the master class 1 uses a configured addi-tional time within one cycle to read or write data sets from or to one of the slaves. If the total cycle time expired after this operation he will start another main cycle. Subsequently he passes a token to an-other master (here a master class 2) that in turn uses the configured time for acyclic access to read or write data sets from or to one of the slaves.

The slave to slaves communication (DxB = Data eXchange Broadcast) of version DP-V2 just adds the possibility for slaves (“Subscriber”) to receive the response message of another slave (“Publisher”)

that this one sends to his master.

PROFIBUSDP-Master

Publisher(z.B. Lichtgitter)

Slave

DP Slave2

PROFIBUSDP-Master

PROFIBUS DPMaster class 1

PROFIBUS DPMaster class 2


Slave

DP Slave1


Slave

DP Slave3

Token

Cycle n+1: Slave1 Slave2 Slave3 Slave3


Acyclic accessof master class 1/2

Cycle n: Slave1 Slave2 Slave3 Slave2 (Master class 1)

(Master class 2)

Figure 5-3 Basic PROFIBUS DP communication




During run-up of a slave the basic finite state machine of Figure 5-4 applies. After Power_On the slave remains within the state “Wait on Parameterization” until a parameterization message arrived. The master can ask for diagnosis information during this time frame via an appropriate message (Slave_Diag). After a successful parameterization the master class 1 sends the actual configuration the slave shall compare with his local configuration. Again, the master can ask for diagnosis informa-tion during this time frame. After a successful configuration check the slave will be in cyclic data ex-change mode.

Power_On

Wait onParameterization

Wait onConfiguration

DataExchange

Optional:- set slave address- get slave diagnosis

Optional: - check configuration- get slave diagnosis

Parameterization ok

Configuration ok

"Multiplex":Diagnosis telegraminstead of process datain case of fault

Slave fault or timeout

Configuration not ok

Figure 5-4 Run-up state chart of a slave

While in cyclic data exchange mode the slave may indicate the incident of diagnosis information to his master within his response message via the function code inside the “Frame Control” (Figure 5-5).

S S S S S S

Standard Data Exchange Message

SD LE LEr SD DA(27=0)

SA(27=0) FC FCS ED

68H ... ... 68H .... .... ... ..... 16H

Synctime

33 Tbit

Protocol Data Unit(I/O Data)

1.......244 Bytes

Tbit = Clock-Bit = 1 / BaudrateSD = Start Delimiter (here SD2, var. data length)LE = Length of Process DataLEr = Repetition of Length; no check in FCSDA = Destination Address SA = Source AddressFC = Frame Control (Message type)

LE

Data Unit = I/O Data, max. 244 BytesFCS = Frame Checking Sequence

(across data within LE)ED = End DelimiterSB = Start-BitZB0...7 = Character-BitPB = (even) Parity BitEB = Stop-Bit

SB ZB0

ZB1

ZB2

ZB3

ZB4

ZB5

ZB6

ZB7

PB EB

1 Cell = 11 Bit

Figure 5-5 Message structure for cyclic data exchange

The “Frame Control” octet within a PROFIBUS DP message structure comprises a 4-bit “Function Code”. A slave indicates “diagnosis” via altering the bits of the function code (flags) in a certain man-ner depending on the type of message [1]. The master class 1 in turn sends a diagnosis request (Slave_Diag) to the slave within the next regular cycle (Figure 5-6).



Slave_Diag Message

DSAP = Destination Service Access PointSSAP = Source Service Access Point

SSSSSS SSSSSS

SDLELErSDDA(27=1)

SA(27=1)FCFCSED

68H......68H................16H

Synctime

33 Tbit

D-SAP

S-SAP

3EH(62)

3CH(60)

S S S S S S

Slave_Diag Response Message

SD LE LEr SD DA(27=1)

SA(27=1) FC FCS ED

68H ... ... 68H .... .... ... ..... 16H

Synctime

33 Tbit

Protocol Data Unit(Diagnosis Information)

1.......242 Bytes

D-SAP

S-SAP

3EH(62)

3CH(60)

Figure 5-6 Exchange of diagnosis information

The master uses special service access points (DSAP = 60, SSAP = 62) to address the corresponding services (Figure 5-7). The usage of service access point addresses is indicated through the MSB of the destination and source addresses (DA, 27=1; SA, 27=1). The slave in turn responds with a diagno-sis message that contains at least a standard block of 6 octets. It may contain a device dependant extended diagnosis information that uses one or several of the appropriate diagnosis structures de-scribed in this document.



60

59

57

56

55

Get_CfgRD_Inp

RD_OutpSet_Slave_Add

MS0cyclic,

connection baseddata exchange

Slav

e_Diag

MS0connectionless DP-

Functions

MS1connection based,acyclic services,

implicit connectionvia MSZY_C1

Initiate,

Read, Write

, Abort *)

50

40

MS2connection based,

acyclic services

MS2connections to additional DP-master class 2 SAPs 41..48 (recommended range)

Layer-2Service

Access Points

6262

Set_

Prm

NIL

Chk

_Cfg

62 NIL61

Dat

a_Ex

chan

ge62

58

Glo

bal_

Con

trol

51

51

Rea

d,W

rite

*)

Ala

rm_A

ck

DP-MasterClass 1

(e.g. PLC)

Client Client

Server

MMMaster-Master-Communication

DP-Slave

DP-Master Class 2

(e.g. PC)

54

41

Get_Master_Diag, Download, Upload,Act_Param, Start_Seq,Abort

54

CS

MS3connectionless DP-

Functions

Set_Time

*) Embedded within Read/Write Services:- Load Region (with states; e.g. Up/Download)- Function Invocation (with states; e.g. Start, Stop,

Reset)- Call Mechanism (stateless; e.g. I&M functions)

49

Server

Connection based: cyclic run-up or initiateConnectionless: no previous run-up or initiate

connection-less

Figure 5-7 Communication services of PROFIBUS DP

Figure 5-7 demonstrates how the Slave_Diag service (60) is embedded within the other services of PROFIBUS DP. It is connectionless and can be used anytime by masters. For the alarm acknowledge (Alarm_Ack) the destination service address (51) can be used, optionally (50). More details about the communication services can be found in [1] and in IEC 61158-5, table 398. Diagnosis options within masters and slaves can be defined via GSD files. Details to be found in [8].

Figure 5-8 contains a sequence chart showing the chronology of the concerned standard and diagno-sis messages. When a slave discovers a fault while in data exchange mode it changes the function code in its response message to "high priority". During the next regular bus cycle the master in turn sends a "Slave_Diag" request that is answered with a "Slave_Diag" response. The slave indicates the availability of individual diagnosis information (module status, channel related diagnosis, etc.) via Diag.Ext_Diag = 1. Once the master was able to "catch" the diagnosis information it returns to the standard cyclic data exchange mode. It is good slave design practice to notify the master about the termination of the diagnosis incident. For that purpose the slave commences with a "high priority" re-sponse. The master answers with a "Slave_Diag" request that is followed by a "Slave_Diag" response with Diag.Ext_Diag = 0.



Sequence chart: Master Slave

Data exchange response

Data exchange request

Slave_Diag response (Diag.Ext_Diag = 1)

Slave_Diag request

1 Cycle

MS0(NIL, 60)

Data exchange response (Function Code = high priority!)

Data exchange requestSlave fault

comes



Faultgone

Slave_Diag response (Diag.Ext_Diag = 0)

Slave_Diag request





Figure 5-8 Basic diagnosis communication mechanism

5.3 Alarm communication Figure 5-9 demonstrates how the acyclic services extend the basic diagnosis communication mecha-nism with acyclic write and read services to transmit the alarm and event information (optionally time stamped) to the host application and how they finalize the sequence with an optional Alarm_Ack mes-sage. The sequence of an alarm request and alarm response is standardized via the master state ma-chine. The content of its message PDUs is described in chapter 9.3. For details see [4].

If required, the master/host application has to provide the (optional) additional acknowledgement of an alarm for example in form of a MS1 Write Service. It is not part of the alarm state machine within the master.

It should be noted that it is the responsibility of the host application and the slave designer to define the content of the optional and acyclic "Alarm_Acknowledgement" message.



Sequence Chart:

Slave-Application

Host-Application

MS0(NIL, 60)

MS1(51)

Fault

Master Slave



Slave_Diag response (with alarm)

Slave_Diag request

1 Cycle

Alarm_Acknowledgement (optional)

Slave faultcomes



Alert

Ack



Alarm_Ack request (write record)

Alarm_Ack response (read record)Response

request

response

acknowledgeAck

Figure 5-9 Alarm communication mechanism

5.4 Diagnosis data structure

The previous chapters were dealing with the general concepts of diagnosis information and the ways they are transmitted between host, master, slave and slave technology. The following chapters will explain the different diagnosis “blocks” in detail. Figure 5-10 shows the recommended structure of di-agnosis messages for simple slaves. In contrast toFigure 4-4 the Figure 5-10 contains some more in-formation on the internal structures for orientation purposes.

For Profile Working Groups the IEC 61158 standard describes several possibilities within the individ-ual diagnosis types (usually marked with "manufacturer specific" or "profile specific") to define specific coding for device families in order to facilitate programming efforts and to avoid confusion of the cus-tomer.




(6 octets)


(6 octets)





aaaaa000Type IRD, lengthOctet 6Octet 5Octet 4Octet 3Octet 2Octet 1

cbcbcbcc000000

Module StatusBlock


Module StatusBlock


Channel Related DiagnosisBlock per affected channel

(3 octets per block)

Channel Related DiagnosisBlock per affected channel

(3 octets per block) Channel type, error typeChannel numberType, identifier / moduleChannel type, error typeChannel numberType CRD, identifier no.

SpecifierSlotStatus type: ModuleType DRD, length

bb

LSBMSB

.......

Figure 5-10 Recommended structure of a diagnosis message

In the following the combination and structuring of the different diagnosis possibilities is presented.

5.4.1 Standard Diagnosis

The format of this part of the diagnosis data is defined within the PROFIBUS standards (IEC 61158). It consists of 6 octets that cannot be influenced by the field device designer. The diagnosis information is related to the communication layer and covers run-up diagnosis scenarios such as the device identi-fication, communication mode information (FREEZE, SYNC), readiness, availabilities, watchdogs, parameterization and configuration faults. For details see IEC 61158-6, 6.2.3.1 to 6.2.3.5.

It should be noted that bit 7 in octet 3 (the “Ext_Diag_Overflow” flag) can be used by the slave to indi-cate more diagnosis information then fits into the actual diagnosis message length. This length is pre-defined in the GSD file of the slave. The surplus diagnosis information will be lost.



Octet 1 0

Diag.Station_Non_Existent: (1) = Slave doesn't exist.This bit to be set by the master itself.

Diag.Station_Not_Ready: (1) = Slave not ready for data exchange.

Diag.Cfg_Fault: (1) = Slave has mismatching confi-guration data.

Diag.Ext_Diag: (0) = Slave sends standard diagnosisdata only (6 bytes). Optionally with extended diagnosis without faults ( warning or "fault going"). (1) = Slave indicates serious faults, usually with extended diagnosis data ( "fault coming").

Diag.Not_Supported: (1) = Slave doesn't supportthe required function.

Diag.Invalid_Slave_Response: (0) = Set by slave.(1) = Set by master in case of fault.

Diag.Prm_Fault: (1) = Slave got wrong parameterization.

Diag.Master_Lock: (1) = Slave has been parameterizedby another master. This bit to be set by the master itself.

Octet 2 0

Diag.Prm_Req: (1) = Slave requests parameterization.Thereupon the master starts a new run-up for that slave.

Diag.Stat_Diag: (1) = Slave not able to provide validdiagnosis data. Master repeats diagnosis requests while in Data Exchange mode until this bit is set (0). *) DP: (1) = shall always be set

Diag.WD_On: (1) = Slave reports exceeded watchdog time

Diag.Freeze_Mode: (1) = Slave is in FREEZE mode.

Diag.Sync_Mode: (1) = Slave is in SYNC mode.

reserved

Diag.Deactivated: (1) = Diagnosis deactivated.This bit to be set by the master itself.

*) Diag.Stat_Diag: This behavior only is valid within the start-up phase of a slave

(Continued on next page)



Octet 3 0

Diag.Ext_Diag_Overflow: (1) = Slave has more diagnosisdata than fit into the buffer.

reserved

Octet 4 0

Diag_Master_Add: Address of the master that has para-meterized the slave (0 – 125). If the slave has not yet been parameterized, it sends (255). Not allowed are (126-254).Data type: Unsigned8

Octet 5 0

Ident_Number: High byte of the slave's ident number thatis to be provided by the PROFIBUS business office.Octet 5 + 6: Data type: Unsigned16

Octet 6 0

Ident_Number: Low byte of the slave's ident number thatis to be provided by the PROFIBUS business office

Follows: Extended Diagnosis

Standard Diagnosis

In principle, the order of the following extended diagnosis structures may be chosen freely. However, as the diagnosis information has to be processed within a controller it is good engineering practice to recommend a certain sequence in order to save programming efforts (chapter 4.1). The following chapters present the individual diagnosis types or "blocks" in the recommended sequence.

5.4.2 Identifier_Related_Diagnosis

This diagnosis information is related to the configuration identifier that characterizes the data structure for the cyclic data exchange. It usually corresponds to modules of a slave. One bit per (configuration) identifier (module) indicates via a “1” the presence of diagnosis data. The length is limited to 32 oc-tets. Deployment within modular or virtual modular slaves is highly recommended.

A "warning" (= diagnosis information that does not require immediate maintenance) does not set an "Identifier_Diagnosis_Entry".



00 11Octet n 0

Block_Length: Number of octets of the followingExtended Diagnosis block including this header octet

Extended Diagnosis Identifier Related Diagnosis (Example)Standard Diagnosis

Header

Selection: (1) = Identifier Related Diagnosis

00 00Octet n+1 0

Identifier_Diagnosis_Entry_1: For each Identifier (= module) withinthe configuration of the slave a single bit is assigned here inan ascending manner.(0) Identifier 1 has no diagnosis data(1) Identifier 1 has diagnosis data

Padding Bits: only 6 Identifier Bytes are configured in this example. The remaining "padding bits" shall be filled with 0

Identifier_Diagnosis_Data_Array

Identifier_Diagnosis_Entry_2: see "_Entry_1"





Octet number "n" depends on the diagnosis data before this block. If "Identifier Related Diagnosis" followsthe standard diagnosis block, n will become 7.

5.4.3 Module_Status

This method uses the status model type of diagnosis (chapter 9.2). Therefore in the GSD file of these devices "DPV1" = 1 shall be set. Two enumerated bits per module indicate:

00 Module ok; data valid 01 Module correct; data invalid due to faults (e.g. line break) 10 Wrong module; data invalid 11 No module; data invalid

In case there are not enough modules to fill an octet completely, the remaining “padding bits” shall be filled with “0”.



00 00Octet n 0

Block_Length: Number of octets of the following Extended Diagnosis block including this header octet (max 59)

11 00 00 00 00 00 11 00Octet n+1 0

Status_Type: (2) Modul_Status

00 00 00 00 00 00 00 00Octet n+3 0

Status_Specifier: (0) no further differentiation

Extended Diagnosis Modul_Status (Example)Standard Diagnosis

Header

Selection: (0) = Device Related Diagnosis (DPV1=1!)

Identifier: (1) = Status

00 00 00 00 00 00 00 00Octet n+2 0

Slot_Number: Data type: Unsigned8; Range: (0)

Reserved: (0) Shall be set.

00 00Octet n+4…n+65 0

Modul_Status_Entry_1:(0) Module ok, data valid(1) Module correct, data invalid due to fault (e.g. wire break)(2) Wrong module in use, data invalid(3) No module in use, data invalid

Modul_Status_Entry_2: see "...Entry_1"

Modul_Status_Entry_3: see "...Entry_1"

Padding Bits: only 3 modules are configured in this example.The remaining "padding bits" shall be filled with 0

Modul_Status_Array

5.4.4 Channel_Related_Diagnosis

The “Channel_Related_Diagnosis” informs about failures and errors of channels within modules thus detailing previously described diagnosis types such as “Identifier_Related_Diagnosis” and “Mod-ule_Status”. Each channel out of order can be represented by 3 octets.

32 failure and error types are possible whereof types 0 to 9 are predefined and 10 to 15 are reserved. A slave device manufacturer may define the types 16 to 31 via GSD entries [8]. The keywords are:

• Channel_Diag • Channel_Diag_Help

Via “Channel_Diag” a text of 32 characters can be defined per channel that characterizes a certain failure or error. Via “Channel_Diag_Help” a text of 256 characters may be associated that provides hints about remedial measures to fix the problem (chapter 7.2.1).



11 00Octet n 0

Identifier_Number: Range (0-63); (Identifier corresponds to module)

Extended Diagnosis Channel Related DiagnosisStandard Diagnosis

Header

Selection: (2) = Channel Related Diagnosis

Octet n+1 0

Channel_Number: Range (0-63)

Channel

Input_Output_Selection: (0) reserved(1) Input(2) Output(3) Input and output

Octet n+2 0

Error_Type: Range (0-31)(0) reserved(1) Short circuit(2) Undervoltage(3) Overvoltage(4) Overload(5) Overtemperature(6) Line break(7) Upper limit value exceeded(8) Lower limit value underrun(9) Error(10-15) reserved 1)

(16-31) manufacturer specific (Definition via GSD entries)

Type_of_Diagnosis

Channel_Type: (0) unspecific, may be used for any type(1) bit(2) 2 bit(3) 4 bit(4) octet(5) word(6) 2 words(7) reserved

1) Profile "RIO for PA" (No. 3.132) assigned "10" to "simulation active". This needs approval by PNO advisory board

5.4.5 Diagnosis Alarm

The “Diagnosis Alarm” belongs to the “alarm model” type (chapter 9.1). Diagnosis alarms may occur alone or in combination with the previously mentioned diagnosis types. Typically, complex and/or spe-cial slave devices such as diagnosis repeaters are predestinated for the “Diagnosis Alarm”.

A slave device manufacturer may define the Alarm_Data_Description via entries in the GSD file. Two possibilities exist and they are defined in [8]. One uses single bits that can be associated with a diag-nosis text and a help text similar to the “Channel_Related_Diagnosis”. The keywords are “X_Unit_Diag_Bit” and X_Unit_Diag_Bit_Help.

The other uses enumerated areas of bits and associates a diagnosis text and a help text to each bit combination. The keywords here are “X_Unit_Diag_Area”, “X_Value”, “X_Value_Help”, and “X_Unit_Diag_Area_End”. Chapter 7.2.2 reveals some more details on how to encrypt these GSD en-tries.




Diagnosis alarms require extraordinary support from the master or host as described in chapter 5.3. As not all the PROFIBUS host systems on the market are providing this feature the designer of a slave device may consider implementing a "switch" between the intended diagnosis-alarm type and a status-message type as an option (chapter 9.2). Thus the structure and content of the diagnosis information can be the same. However, the user of the device can select the diagnosis type according to the sys-tem in use via user-defined-parameters within the GSD of the device.

5.5 DxB Link Status Within IEC 61158 only the diagnosis for link table based slave to slaves communication is specified. However, the PROFIBUS community prefers and is recommending the publisher subscriber table- based slave to slaves communication. The "DxB Subscriber Status" explicitly is not defined yet. The "DxB Link Status" shall be used instead. Please contact the PNO business office if more diagnosis cases need to be distinguished and defined.

00 00Octet n 0


00 00 00 00 00 00 00 11Octet n+1 0

Alarm_Type:(1) Diagnosis_Alarm

00 00 00 00 00 00

Octet n+3 0

Alarm_Specifier: (0) no further differentiation(1) Fault occured and slot is not ok(2) Fault disappeared and slot is ok(3) One Fault disappeared and slot is not ok

Extended DiagnosisStandard Diagnosis

Diagnosis Alarm

Header

Selection: (00) = Device Related Diagnosis (DPV1!)

Identifier: (0) = Alarm

Octet n+2 0

Slot_Number: Range 0-254.

Additional_Acknowledge: (0) Slave requires no additionalacknowledge to notify operator

Sequence_Number: (0) "type mode" with one active alarm(recommended)

Octet n+4… 0Alarm_Data_Description:(Definition via GSD entries)

1. Several Alarms possible after the Standard Diagnosis (first 6 octets)2. For each module only one alarm of one type allowed3. Alarms only to be used in case of "DPV1=1" slaves (GSD setting)4. Total length of alarms shall not exceed 59 octets.



00 00Octet n 0


11 00 00 00 00 00 11 11Octet n+1 0

Status_Type: (3) DxB_Link_Satus

00 00 00 00 00 00Octet n+5 0


Extended Diagnosis DxB_Link_StatusStandard Diagnosis

Header



Octet n+4 0

Publisher_Address: data type: Unsigned8; Range 0-125.

Link_Error: (0) No error or unspecific(1) Wrong length; the length of the Input Data of the Publisher does not

align with the value of Input_Data_Length_Publisher of the related DxB_Link_Entry

00 00 00 00 00 00 00 00Octet n+2 0

Slot_Number: Range: 0

00 00 00 00 00 00Octet n+3 0

Status_Specifier: (0) no further differentiation(1) Status appeared(2) Status disappeared


Link_Status: (0) DxB-Link not active; no subscription of the Publisher has been

performed during the last monitoring period (Twd). The Subscriber may use Link_Error for detailed information

(1) DxB-Link active; at least one subscription of the Publisher has been performed during the last monitoring period (Twd)

Publisher Status (from this subscriber's view)

5.6 Time stamped Alarms and Events Especially within the process industries time stamped diagnosis information such as alarms and events are required. These features depend heavily on the availability of system wide clock time syn-chronization. Thus they become slowly widely accepted. Up to now the profile "PA Devices" does not support this type of diagnosis [9]. Details of time stamped alarms and events are defined within [4].



00 00Octet n 0


00Octet n+1 0

Alarm_Type:(1) Diagnosis_Alarm (not defined for time-stamped use)(2) Time-stamped Process_Alarm(3) Pull_Alarm (not defined for time-stamped use)(4) Plug_Alarm (not defined for time-stamped use)(5) Time-stamped Status_Alarm (State change)(6) Time-stamped Update_Alarm(32) Time-stamped Event(33) Time-stamped Diagnosis_Alarm

Octet n+3 0

Alarm_Specifier: (0) no further differentiation(1) Incident appeared (slot not necessarily defect)(2) Incident disappeared and slot is ok(3) One incident disappeared, others remain

Extended Diagnosis: Time-stamped Alarms and Events (defined in "Time Stamp" [4])Standard Diagnosis

Header



0


Additional_Acknowledge: (1) Slave requires additionalacknowledge to notify operator (in case of event only)

Sequence_Number: (1-31) Identification of one of several alarmsin "sequence mode". (0) in "type mode" with one active alarm

Octet n+2

(Continued on next page)



Octet n+4 0State_Of_Timestamp_Mechanism

Manufacturer specific (default = 0)

Buf_Ov (Buffer Overrun): (1) all internal buffers full; time stampprocess halted; information lost

Res (Restarted): (1) Time stamping restarted. May cause a restartwithin the host application, e.g. with redundant slaves after switch.

0

Index: Range according to a profile. Points to the alarm or event data structure within the indicated Slot_Number.

Octet n+5

0Octet n+6

Num_Elements: Number of elements within the Data_Set_Typeof the time-stamped alarm or event (no octets!)

0Octet n+7

Data_Set_Type (of alarm or event): Description of the data structure to be read from the slave buffer (see separate table)

0Octet n+8

High Byte of the profile identification for time-stamped alarms: (see below)

0Octet n+9

Low Byte of the profile identification for time-stamped alarms: (0) reserved(1) "PROFIBUS PA Profile for Process Control Devices"(2-9) reserved for the above profile

Data_Set_Type Table: Type No Time-stamped alarm type (TS) Name of structures DS-ID [4]

0 TS Event Reserved -

1 TS Event Data set composition of signal and exception types -

2 TS Event Trend_Float DS 46

3 TS Event Trend_Discrete DS 47

4 TS Event Trend_Bit_String DS 48

5 - 9 TS Event Reserved for other TS events -

10 TS Process alarm Alarm_Float DS 39

11 TS Process alarm Alarm_Discrete DS 40

12 TS Process alarm Alarm_Integer DS 86

13 – 19 TS Process alarm Reserved for other TS process alarms -

20 TS Update alarm Alarm_Update DS 41

21 - 29 TS Update alarm Reserved for other TS update alarms -

30 TS Status alarm Alarm_Mode_Change DS 87

31 TS Status alarm Alarm_Simulation DS 88

32 TS Status alarm Alarm_Fail_Safe (default values, not safety!) DS 89



33 TS Status alarm Alarm_Access_Protection DS 90

34 TS Status alarm Alarm_Sampling_Information DS 95

35 TS Status alarm Alarm_Sampling_State DS 96

36 – 39 TS Status alarm Reserved for other TS status alarms -

40 TS Diagnosis alarm Alarm_Diagnosis DS 91

41 TS Diagnosis alarm Alarm_Extended_Diagnosis DS 92

42 TS Diagnosis alarm Alarm_Checkback DS 93

43 TS Diagnosis alarm Alarm_Defect_Class DS 94

44 TS Diagnosis alarm Alarm_Sampling_Diagnosis DS 95 (?)

45 – 49 TS Diagnosis alarm Reserved for other TS diagnosis alarms -

50 –127 Reserved

128 – 249 Manufacturer specific

250 Not used

251 None

252 Unknown

253 Special



6 MS2 Diagnosis

See IEC 61158-5 und – 6.



7 Diagnosis configuration techniques (GSD) The definition of the diagnosis information for a particular slave and corresponding message texts are entered in the engineering systems via GSD (General Station Description) files.

7.1 General configuration of PROFIBUS segments using GSD files

A PROFIBUS DP segment is an application specific collection of master and slave devices, which are connected to it, known as communication configuration. The segment consists of a master class 1 and its related slaves and optional master class 2 devices. Each segment needs to be configured because the structure of the cyclic data between master class1 and its slaves as well as the baud rate, device addresses and special communication timing parameters need to be adjusted according to the proper-ties of the devices. The task of configuration is supported by a configuration tool, which is usually pro-vided by the master class 1 device manufacturer. This configuration tool reads the parameters and the permitted value ranges of a particular device out of its GSD file. Every device is supplied with such a GSD file. With the help of the GSD file and the configuration tool the user is able to generate a possi-ble or the optimal communication configuration of the segment.

The abbreviation GSD stands for General Station Description. The GSD language describes the communication features and the cyclic data types and structures of simple devices such as binary and analogue I/O. Communication parameters are supported baud rates, protocol timing parameters and the support of PROFIBUS services and functions (e.g. remote station address assignment).

Simple I/O devices (also known as Remote I/O or Electronic Terminal) are mainly modular. A basic slave device with power supply and a central communication unit has several slots for modules with different signal types (analogue, binary) and arrangements (e.g. 2, 4, 8, 16 channels). According to the chosen modules, a different set of data has to be transferred in the cyclic transfer between the PROFIBUS DP master and the slave devices. In other words, every module contributes with a specific set of data to the cyclic message. Due to the GSD language that provides an unambiguously and manufacturer independent description of the modules, the configuration tools of PROFIBUS DP mas-ter devices (mainly PLC) can integrate all PROFIBUS DP conformant modular devices. This is the second main task of the GSD description.

The GSD file consists of a list of keywords accompanied by their value assignments for each feature of the PROFIBUS DP protocol that can be adjusted to the individual needs. Several GSD file samples can be downloaded from the Internet (www.profibus.com).

Modules are represented in the GSD file by the keyword “Module“. Between the “Module” and the “End_Module” keyword, the declaration of the contribution of the module to the cyclic data message is specified in terms of binary codes, the so-called “Identifier Bytes”. Each module has a name, which is displayed on the screen of the configuration tool within a library window. If the module is chosen, the range and the default value of variables can be configured through the variable declaration possibility of the GSD file. The completed collection of parameter data is stored within the master class 1 and transmitted to the slave via the so-called “Set_Prm” service (Figure 5-7). The selected “Identifier Bytes” will be concatenated to the configuration string, which is transferred from the master to the slave during the start-up of the slave after power-on via the so-called “Chk_Cfg” service (Figure 5-7).

7.2 Diagnosis in the GSD file

Diagnosis and diagnosis help is dedicated to operators or the maintenance staff for urgent interactions of maintenance tasks. Diagnosis information is usually coded as bits in the diagnosis message PDU. The operators and the maintenance staff need readable texts to take corrective actions. The standard predefined diagnosis information can already be decoded within the appropriate tools, because they are standardized for the entire PROFIBUS DP system. Profile specific and manufacturer specific diag-nosis need individual sources for the texts. This source is the GSD file.

7.2.1 Text and help for channel related diagnosis As already mentioned in chapter 5.4.4 the keywords are: “Channel_Diag” and “Channel_Diag_Help”. Following a sample coding for type 16 and type 17 that shows the principle:



……. Channel_Diag (16) = “Too many read retries” Channel_Diag_Help (16) = “Increase retry parameter or clean up the lens of the sensor” Channel_Diag (17) = “Read signal too low” Channel_Diag_Help (17) = “Double the gain factor within the subunit detection” …….

The diagnosis texts may consist of 32 characters. Data type is Visible-String. The help texts may con-sist of 256 characters. Data type is Visible-String.

7.2.2 Text and help for diagnosis alarms Figure 7-1 shows the principle how the Alarm_Data_Description may be defined via keywords within a GSD file. It is possible to define a series of single bits and associate each a diagnosis text and a help text. In order to allocate the bits to the texts each bit cell is counted from relative octet 2. Thus the first bit cell to define is number 24.

It is also possible to group and enumerate bits and thus associate each number a diagnosis text and a help text. In Figure 7-1 the bit cells 50 to 55 are grouped to an enumerated area of 6 bits, which allows 63 different bit area numbers to be assigned a diagnosis text and a help text.

0

77 66 55 44 33 22 11 00

1515 1414 1313 1212 1111 1010 99 88

2323 2222 2121 2020 1919 1818 1717 1616

3131 3030 2929 2828 2727 2727 2525 2424

3939 3838 3737 3636 3535 3434 3333 3232

1234567

Header

Relative octet

1

2

3

4

5

6

4747 4646 4545 4444 4343 4242 4141 4040

5555 5454 5353 5252 5151 5050 4949 4848

7

8

Bit

"Diagnosis Alarm" type (1)

9

Slot_Number

Alarm_Specifier

Alarm_Data_Description

nn Single bit definitions: X_Unit_Diag_Bit (n) X_Unit_Diag_Bit_Help (n)

Legend:

mm Bit area definitions: X_Unit_Diag_Area(enumerated) X_Value ()

X_Value_Help () X_Unit_Diag_Area_End

Figure 7-1 Alarm data description in a GSD file

Following an example based on Figure 7-1:


…… UnitDiagType = 1 ; Diagnosis Alarm type X_Unit_Diag_Bit (24) = “Jabber detected” X_Unit_Diag_Bit_Help (24) = “Check spanning tree conflicts” X_Unit_Diag_Bit (25) = “Reflection detected” X_Unit_Diag_Bit_Help (25) = “Check termination impedance/resistor” …… …… X_Unit_Diag_Area = 50 – 55 X_Value (1) = “PROFIpoint comm error 1” X_Value_Help (1) = “Check PROFIpoint channel 1”



X_Value (2) = “PROFIpoint comm error 2” X_Value_Help (2) = “Check PROFIpoint channel 2” X_Value (3) = “PROFIpoint overload” X_Value_Help (3) = “Short circuit? Wrong sensor type?” …… X_Unit_Diag_Area_End EndUnitDiagType ….. Again, the diagnosis texts may consist of 32 characters. Data type is Visible-String. The help texts may consist of 256 characters. Data type is Visible-String.

7.3 GSD tool set

Manufacturers are obliged to supply their slave devices with an appropriate GSD file. It is highly rec-ommended for manufacturers to certify the device at one of our test and certification centers where the GSD files are checked during the tests. The GSD file is using ASCII text as transfer syntax. The PNO offers a special GSD editor, which supports the user during the GSD development (Figure 7-2). The user chooses the features of the device from the superset of all the existing PROFIBUS DP features and keywords. The editor generates the syntactically correct GSD ASCII file. This file is not compiled.

Figure 7-2 GSD editor screenshot

The configuration tools are using these GSD files to present the specified device features to a user. The user accepts or modifies the proposed configuration parameters. The result of this configuration session is a set of parameters and configuration data, which are loaded into the PLC that hosts a PROFIBUS DP master class 1 (Figure 7-3).



GSD files

PROFIBUS DP

Controller Master class 1

Field deviceSlave

PCMaster class 2

GSD editor

Configuration Tool

Prm, Cfg Prm, Cfg

Figure 7-3 Tools and handling of GSD files

The handling of GSD is very simple and needs no specific training. It matches exactly the needs of the majority of the factory automation devices where no parameterization at runtime is required. Sample GSD files can be downloaded from the PROFIBUS web page www.profibus.com.

8 Migration to PROFINET IO The Diagnosis model of PROFINET IO is based on the DP-V1 level (alarms) of PROFIBUS DP. Thus migration from DP-V0 to DP-V1 to PROFINET IO is possible. However, it will not be possible to hold the increased total amount of diagnosis information of the system within the IO-controller (Mas-ter/Host). Thus slight modifications in system behavior will occur. The following statements are provid-ing a short introduction in the diagnosis features of PROFINET IO:

• An actual diagnosis incident of a slave is transmitted in short form via a diagnosis alarm

• The alarm will carry standardized channel related diagnosis data. The number of possible standardized channel faults is increased dramatically to meet the requirements. In addition manufacturer specific extensions are possible.

• The slave device holds the complete diagnosis information within a buffer that can be re-trieved asynchronously by the IO-controller or by an engineering device or alike.





(6 octets)


(6 octets)





Diagnosis AlarmsOne or more blocks


Diagnosis AlarmsOne or more blocks


Module StatusBlock


Module StatusBlock






Status MessageOne or more blocks


Status MessageOne or more blocks


DP-V0 Slave,DP-V1 Slave without alarms

DP-V1 Slave with alarms

Figure 8-1 Overview on the recommended diagnosis types and the migration

9 Appendix

Basic structures of the diagnosis types "Alarm" and "Status" are following within the next two chapters (See chapter 5.1). The diagnosis type "Revision Number" is added for completeness even if its usage is not recommended due to limited significance.

9.1 General structure of the diagnosis type "Alarm model"

This definition comprises e.g. "Diagnosis Alarm" and "Time-stamped Diagnosis Alarms" described ear-lier in this document. For this type of diagnosis the parameter "DPV1" =1 shall be set within the GSD file. The counting of octets depends on the preceding diagnosis information.



00 00Octet n 0


00Octet n+1 0

Alarm_Type:(0) reserved(1) Diagnosis_Alarm (usual system reaction: STOP)(2) Process_Alarm(3) Pull_Alarm(4) Plug_Alarm(5) Status_Alarm (State changes)(6) Update_Alarm(7-31) reserved(32) used for: Time-stamped Event (acccording [4])(33) used for:Time-stamped Diagnosis_Alarm (according [4])(34-126) manufacturer specific (usual system reaction: No STOP)(127) reserved

Octet n+3 0


Extended Diagnosis Alarm (Format for all the Diagnosis structures of the "Alarm model")Standard Diagnosis

Header



Octet n+2 0


Additional_Acknowledge: (1) Slave requires additionalacknowledge to notify operator, (0) No acknowledge

Sequence_Number: (1-32) Identification of one of several alarmsin "sequence mode". (0) in "type mode" with one active alarm(recommended)

Octet n+4…n+59 0Alarm_Data_Description:to be defined by profile working groups (e.g. "PA Devices [9] or"Time Stamp" [4]) or manufacturer specific (via GSD entries)

1. Several Alarm structures possible after the Standard Diagnosis (first 6 octets)2. For each module only one alarm structure of one type allowed3. Alarm structures only to be used in case of "DPV1=1" slaves (GSD setting)

(usual system reaction: No STOP)

9.2 General structure of the diagnosis type "Status model"

This definition comprises e.g. "Module Status" and "DxB Link Status" described earlier in this docu-ment.



00 00Octet n 0

Block_Length: Number of octets of the followingExtended Diagnosis block including this header octet

11Octet n+1 0

Status_Type:(0) reserved(1) Status_Message(2) Modul_Status(3) DxB_Link_Status(4-29) reserved(30) PrmCmdAck(31) Red_Status(7-31) reserved(32-125) manufacturer specific(126) used for Profile "PA Devices" [9](127) reserved

00 00 00 00 00 00Octet n+3 0

Status_Specifier: (0) no further differentiation(1) Status appeared(2) Status disappeared(3) reserved

Extended Diagnosis Status (Format for all the Diagnosis structures of the "Status model")Standard Diagnosis

Header



Octet n+2 0

Slot_Number: Data type: Unsigned8; Range 0-254.


Octet n+4…n+59 0Status_Data_Description:Depending on Status model type or to be defined by profile working groups or manufacturer specific (via GSD entries)

1. Several Status structures possible after the Standard Diagnosis (first 6 octets)2. A Status structure shall not exceed a total length of 59 octets3. Status structures only to be used in case of "DPV1=1" slaves (GSD setting)

Special care should be taken in the design phase of a device with "Status appeared" and "Status disappeared".The following rules may be helpful:• Default value for "Status appeared" and "Status disappeared" is "0"• Each and every new status incident to be indicated with "Status appeared" = "1" regardless of whether there

was one before or has gone another ("Status appears" has higher priority than "Status disappears")• In cases one or more status incidents of several are gone and one is still remaining "Status disappeared" will

be set "1"• When all the status incidents are gone, "Status appeared" and "Status disappeared" are set "0" (default)

9.3 General structure of the Alarm Acknowledgements


Chapter 5.3 is introducing the acyclic acknowledgement of diagnosis alarms. The data structure of the Alarm_Ack request and the successful (positive) Alarm_Ack response is as follows:



00 11 00 11 11 11 00 00Octet 1 0

Function_Code: Request and positive response (28)

00Octet 3 0

Alarm_Type: according to the diagnosis message

Octet 4 0


Function_Num for "Alarm_Ack" request and positive response (5CH)

PDU_Identifier: DP-PDU = (2)


Octet 2 0

Slot_Number: according to the diagnosis message

Additional_Acknowledge: (1) Slave requires additionalacknowledge to notify operator, (0) No acknowledge

Sequence_Number: (1-32) Identification of one of several alarmsin "sequence mode". (0) in "type mode" with one active alarm(recommended)

DLPDU_Selector: (0) request DLPDU or positive response DLPDU(1) error or negative response DLPDU

The data structure of the unsuccessful (negative) Alarm_Ack response is as follows:



11 11 00 11 11 11 00 00Octet 1 0

Error_Code: Request and positive response (28)

Octet 3 0

Error_Code: see table below

Function_Num for "Alarm_Ack" error or negative response (DCH)

PDU_Identifier: DP-PDU = (2)

Error_Class: see table below

Octet 2 0

Error_Decode:(0-127) reserved(128) DPV1; the octets Error_Code_1 and 2 are coded

as defined in IEC 61158 (see below)(129-253) reserved(254-255) the octets Error_Code_1 and 2 are profile specific

DLPDU_Selector: (0) request DLPDU or positive response DLPDU(1) error or negative response DLPDU

Error_Code_1

Octet 3 0

Error_Code_2: manufacturer specific (Unsigned8)

Error Class (decimal)

Meaning Error Code (decimal)

Remarks

0 to 9 Not specified Not specified *) 10 Application 0 = read error

1 = write error 2 = module failure 3 to 6 = not specified *) 7 = busy 8 = version conflict 9 = feature not supported 10 to 15 = User specific

*) "Not specified" values are used to serve legacy codes and are intended to be passed unchanged to the appli-cation.

11 Access 0 = invalid index 1 = write length error 2 = invalid slot 3 = type conflict 4 = invalid area 5 = state conflict 6 = access denied 7 = invalid range 8 = invalid parameter 9 = invalid type 10= backup 11 to 15 = User specific

12 Resource 0 = read constrain conflict 1 = write constrain conflict 2 = resource busy 3 = resource unavailable 4 to 7 = not specified *) 8 to 15 = User specific

13 to 15 User specific



10 Literature

[1] M. Popp, "The New Rapid Way to PROFIBUS DP", November 2002, PNO Order No. 4.072

[2] Ron Mitchell, "PROFIBUS: A Pocket Guide", ISA, October 2003, ISBN 155617862X

[3] PROFIBUS Profile "Remote I/O for Process Automation", V1.0, May 2003, Order No. 3.132

[4] PROFIBUS Guideline "Time Stamps", V1.0, July 2001, Order No. 2.192

[5] PROFIBUS Guideline "Specification Slave Redundancy", V1.1, December 2003, Order No. 2.212

[6] NE 044: "Standardization of Status Indicators on PCT Instruments with the Help of Light Emitting Diodes", February 2003, NAMUR (www.namur.de)

[7] NA 064: "Status Signals of Field Instruments", July 2002, NAMUR (www.namur.de)

[8] PROFIBUS Guideline "Specification for PROFIBUS Device Description and Device Integration, Volume 1: GSD V5.0", August 2003, Order No. 2.122

[9] PROFIBUS Profile “PROFIBUS PA Profile for Process Control Devices”, V 3.0, October 1999, Order No. 3.042

[10] NE 091: “Requirements for Online Plant Asset Management Systems“, August 2001, NAMUR (www.namur.de)

[11] PROFIBUS Profile Guidelines, Part 1 “Identification & Maintenance Functions”, V1.1, May 2003, Order No. 3.502

[12] PROFIBUS Guideline “PROFIBUS Communication and Proxy Function Blocks according to IEC 61131-3”, V1.2, July 2001, Order No. 2.182

[13] J. Weigmann, G. Kilian, "Decentralization with PROFIBUS DP/DPV1, 2nd edition 2003, ISBN 3-89578-218-1


http://www.namur.de/




© Copyright by: PROFIBUS Nutzerorganisation e.V. Haid-und-Neu-Str. 7 D-76131 Karlsruhe Germany Phone: ++49 (0) 721 / 96 58 590 Fax: ++49 (0) 721 / 96 58 589 E-mail: [email protected] http://www.profibus.com



PROFIBUS Profile Guidelines, Part 3 - 3+-+Profibus+Guidelines+3.522+... · PROFIBUS DP standards,...

Documents

Transcript of PROFIBUS Profile Guidelines, Part 3 - 3+-+Profibus+Guidelines+3.522+... · PROFIBUS DP standards,...