Editor’s note: This article is an excerpt from PROFINETuniversity.com and the PROFINET Developer Workshop offered by the PROFI Interface Center.
Alarms, Diagnostics, Errors… these terms get thrown around a lot when people discuss how to communicate when bad things happen on the network. But what do they really mean? In this article, we’ll take a look at what kind of information is conveyed in alarms, and how you can leverage it as a developer.
Background
PROFINET devices accomplish 99.9% of their communication via the cyclic, real-time communications channel. Data is produced according to a pre-defined format, and it’s sent on a schedule that doesn’t care if the data changes. This is a great way to communicate data that changes constantly, but it imposes a lot of overhead on data that only changes very rarely.
Alarms are really useful for the 0.1% of communication needs that can’t be handled in that pre-defined cyclic format. They’re event-driven, so a PROFINET device will only send them if an event happens that the PROFINET controller needs to know about. For instance, it’d be inefficient to pack information about a redundant power supply’s operating state in to the cyclic channel, so most devices don’t (power supplies fail relatively rarely). But if one of the inputs to that redundant supply goes down, the device can send one alarm to the controller to let it know what’s happened. This keeps the rarely-changing power supply data out of the cyclic channel, saving bandwidth and processing overhead.
This article covers how the content of these alarms is defined and how it’s handled in a typical PROFINET controller. We’ll start by modifying a GSDML file to define alarm content and then see how that data is pulled in to the Engineering Tool. We’ll use a Siemens PLC in this example, but the concepts of how to handle alarms are constant across all PROFINET Controller vendors.
PROFINET Alarm Structure
Before we can talk about the fun stuff, we first need to understand the way PROFINET alarms are put together. Alarms can encode data in two different ways: as either a Diagnostic Alarm or a Process Alarm. We’re going to focus on Diagnostic Alarms in this lab. Within Diagnostic Alarms, there are two formats that are differentiated by their User Structure Identifier (USI), the Standard Format and a User Defined Format. In this exercise, we will only cover the Standard USI Format (0x8000).
Once we can say that the alarm will be a Diagnostic using the Standard Format, there are some options about how to encode the Standard Format Data. At the top level, there are Channel Errors, which can be further differentiated by an Extended Channel Error. Both of those values must be described in the GSDML file for a PLC to process them.
There’s one more layer of detail in a Diagnostic Alarm, though: the “Channel Error Additional Value”. The format of this Additional Value is defined in the GSDML file, but the actual value sent to the PLC will depend on the conditions in the device when the alarm was sent.
For instance, a device may raise a Diagnostic Alarm with:
- A ChannelError “Overheat” (A high-level description of the problem)
- An ExtendedChannelError “Output Transistor 1” (detailed description of the problem)
- An AdditionalValue encoded as a temperature, so the PLC will know how hot Output Transistor 1 got before the device raised the Overheat diagnostic
Defining your Diagnostic Data
The most important part of designing your PROFINET product is to sort out what information needs to be conveyed across which channel. In our earlier example, we saw that sending the status of a redundant power supply that rarely changes state across the cyclic channel is inefficient. It wastes space in the PLC’s input process image and it requires the PLC to constantly check the status of the power supply. That requires application-specific code to be written for each device.
The better solution is to provide that power supply data in an alarm. That way, it’s only transmitted if the power supply changes state and the PLC only processes the data when the alarm is received, much like an interrupt.
In our example code, we’ll use a diagnostic called a “Line Break” or “Wire Break”. This diagnostic is raised when a discrete I/O point detects an open circuit in the field wiring attached to it. While we’ll use the “Line Break” diagnostic as an example, this process will work for any alarm you care to use, or even any alarm you need to define that may be unique to your application.
There are two types of vendor-specific alarms in a GSDML file:
- Channel Errors (contained in the
<ChannelDiagList>
element) - Manufacturer Specific Diagnosis (contained in the
<UnitDiagTypeList>
element)
We mentioned before that we would focus on the Standard Format for diagnostics, so we can gloss over the <UnitDiagTypeList>
element (it requires you to define your own USI format). Instead, we’ll work with the <ChannelDiagList>
element to extend standard diagnostic codes and create some of our own. PI strongly discourages device manufacturers from using their own USI formats, as those formats likely aren’t supported by any Controller vendors.
For a simple example, we can create a new ChannelErrorType by just adding a <ChannelDiagItem>
to the <ChannelDiagList>
as long as the ErrorType is within the Manufacturer Specific range (0x0100 – 0x7FFF).
It’s also possible to extend an existing <SystemDefinedChannelDiagItem>
like the standard “Line Break” Diagnostic by defining a new <ExtChannelDiagItem>
. For instance, the Line Break diagnostic is defined by PI to correspond to ChannelError == 0x0005. PI doesn’t define any ExtChannelError values with that ChannelError, so vendors are free to implement whatever additional diagnostic information they like.
The code snippet below illustrates both of these examples. First, we define a simple Manufacturer-specific diagnostic with a ChannelErrorType of 0x0100 (256 decimal). Later, we extend the standard ChannelErrorType 0x0006 (“Line Break”) with a manufacturer-specific ExtChannelErrorType of 0x0123 (291) and a ExtChannelAddValue.
<ChannelDiagList>
<ChannelDiagItem ErrorType="256">
<Name TextId="TOK_DIAG256"/>
<ExtChannelDiagList>
<!-- vendor specific extended Channel Diagnosis ErrorType=0x0001 -->
<ExtChannelDiagItem ErrorType="1">
<Name TextId="TOK_DIAG256_EXT1"/>
</ExtChannelDiagItem>
</ExtChannelDiagList>
</ChannelDiagItem>
<!-- PROFINET Protocol ChannelError = 0x0006 (Line Break) -->
<SystemDefinedChannelDiagItem ErrorType="6">
<ExtChannelDiagList>
<!-- Vendor-specific ExtChannelDiagnosis to add more specifics to the line break
For instance, we can add a "Maintenance Demanded severity to
ExtChannelErrorType = 0x0123 (291). -->
<ExtChannelDiagItem ErrorType="291" MaintenanceAlarmState="MD">
<Name TextId="IDT_DIAG6_EXT291"/>
<ExtChannelAddValue>
<!-- The device will send four bytes of data that should be decoded as a Float32.
This value can help with troubleshooting the ExtChannelDiagnosis condition. -->
<DataItem Id="1" DataType="Float32"/>
</ExtChannelAddValue>
</ExtChannelDiagItem>
</ExtChannelDiagList>
</SystemDefinedChannelDiagItem>
</ChannelDiagList>
The TextId tags in these alarm descriptions are included later on in the GSDML file:
<ExternalTextList>
<PrimaryLanguage>
<!-- Diagnostic descriptors -->
<Text TextId="TOK_DIAG256" Value="Channel Diagnostic Error Type 256"/>
<Text TextId="TOK_DIAG256_EXT1" Value="Channel Diagnostic Error Type 256 | Extended Channel Diagnostic Error Type 1"/>
<Text TextId="IDT_DIAG6_EXT291" Value="Extended Channel Diagnostic for Channel Diagnostic 'Line Break'"/>
</PrimaryLanguage>
</ExternalTextList>
Viewing Diagnostics in an Engineering System
Some PROFINET Controller vendors bring the diagnostic information from the GSMDL file in to their native diagnostic displays. We used Siemens’ TIA Portal in this example, but Engineering Tools from other vendors may offer the same functions. We generated two versions of the “Line Break” diagnostic – one using the standard ChannelErrorType, and one using the Manufacturer-Specific ExtChannelErrorType we define above.
Without going in to too much detail on how to access the diagnostic information, here’s what the standard “Line Break” looks like to the end user:
The Engineering Tool decodes the diagnostic as a “Wire Break,” and lists the channel that the diagnostic was generated from (in this case, Channel no. 2). When we triggered the new Manufacturer-Specific ExtChannelErrorType from Channel no. 3, it looked a little different:
The Engineering Tool mapped the ExtChannelErrorType transmitted over the wire (0x0123) to the text description from the GSDML file, and saved the end user the headache of manually looking up the diagnostic code in a manual to figure out what broke. It’s a simple enough trick, but it’s one that can save time when minutes count to resolve unplanned downtime.
Putting It All Together
There’s more to this subject to talk about, but we’re running out of space here. Questions like “How is this different from a PROFINET Error?” (proper noun, capital “E”) or “Hey, you only showed me how to see errors, how can I handle them in my PLC’s application?” are a little too complex to handle in this article. For more information, drop us a line at the PROFI Interface Center. We’re always happy to help.