Skip to content

PROFINET Device Service Component

The PROFINET Device Service component acts as an IO Controller, communicating with IO devices using PROFINET Real-Time (PN-RT).

It supports the following key features:

  • Receive alarms
  • Log alarms
  • Read IO data
  • Write IO data

The device service can be configured to communicate with IO Devices in the following ways:

  • Connected to an existing IO controller on the network, which is configured as an I-device. The IO controller transfers data from its IO devices to the device service, and the device service transfers data to the IO controller to pass to its IO devices
  • Directly connected to the IO devices

Note

IOTech recommends that you connect IO devices using an existing IO controller.

System requirements for PROFINET Device Service

You must use the Totally Integrated Automation (TIA) portal version 16 to install the hardware support package and configure the PN driver component.

Install the Hardware Support Package

To install the hardware support package, complete the following steps in the TIA portal:

  1. Navigate to the project view
  2. Select Options > Support Packages
  3. Retrieve the PN Driver V2.2 (HSP0307) support package
  4. Add the package to the Local Support Packages list
  5. Select the HSP_V16_0307_001_Other_PNDriver_22.isp16 support package
  6. Select Install

Configure the PN Driver Component

To configure the PN Driver component, complete the following steps in the TIA portal:

  1. Navigate to the catalog
  2. Add PROFINET/Ethernet > PROFINET Driver > 6ES7195-3AA00-0YA0 to the project
  3. Navigate to the Network view
  4. Select PN Driver Station
  5. Navigate to the Device view
  6. From the catalog, select Communications Modules > PROFINET/Ethernet > Interface Submodules > Linux Native
  7. Complete the hardware configuration as normal
  8. Compile the project
  9. Export the XML hardware configuration file, which is used by the PROFINET Device Service

Preparing the Network Interface

IOTech recommends that you have a dedicated network interface that is used only for PROFINET communication. Some changes must be made to the settings for this interface. To prepare the PROFINET interface, complete the following steps:

  1. Disable the Dynamic Host Configuration Protocol (DHCP). To do this, add the following line to the /etc/network/interfaces file:

    iface <interface_name> inet manual

  2. Disable the Address Resolution Protocol (ARP). To do this, add the following line to the /etc/sysctl.d/pn_arp.conf file:

    net.ipv4.conf.<interface_name>.arp_ignore=8

  3. Remove the IP address. To do this, enter the following command in a terminal on the host machine:

    ip addr flush dev <interface_name>

  4. Prevent duplicated packages. This can be done in the host machine's terminal using the following commands, where <interface_name> is the name of your interface:

    sudo tc qdisc add dev <interface_name> handle ffff: ingress

    sudo tc filter add dev <interface_name> parent ffff: matchall skip_hw action drop

  5. Configure the Linux stack for use with PROFINET. To do this, ensure that the lower port limit is more than or equal to 49152.

    sudo sysctl -w net.ipv4.ip_local_port_range="49152 60999"

    If the device service does not finish initialization, but has not failed, complete the following steps:

    1. Stop the device service
    2. Reset the interface
    3. Make any changes to the PROFINET interface, as described in the steps above, that have not persisted

PROFINET Device Service Configuration

Note

The components required for running PROFINET (and all other device services) are contained in Device Service Component Configuration. Please refer to this page to ensure the appropriate components are assigned before continuing.

With those components assigned, there are also the following PROFINET Driver options that can be used to configure the service:

PROFINET Driver Options

Driver Field Description
NetworkInterface The name of the network interface operated by the device service
ProfinetConfigurationFile The path to the PROFINET XML hardware configuration file, which was generated using TIA Portal V16

For further information on the hardware configuration file, see Hardware Configuration File

A template of the PROFINET Device Service configuration file is provided below where the driver options have been set to demonstrate their usage:

{
  "Library": "libxrt-profinet-device-service.so",
  "Factory": "xrt_profinet_device_service_factory",
  "Name": "profinet",
  "TelemetryTopic": "xrt/devices/profinet/telemetry",
  "RequestTopic": "xrt/devices/profinet/request",
  "ReplyTopic": "xrt/devices/profinet/reply",
  "DiscoveryTopic": "xrt/devices/profinet/discovery",
  "ProfileDir": "deployment/profiles",
  "StateDir": "deployment/state",
  "Scheduler": "sched",
  "Logger": "logger",
  "ThreadPool": "pool",
  "Bus": "bus",
  "Driver": {
    "ProfinetConfigurationFile": "config/nethat_profinet_config.xml",
    "NetworkInterface": "eno1"
  }
}

PROFINET Device Profile

Details on general profile usage can be found on the Device Profiles page.

The device profile represents an individual module, as described in a PROFINET General Station Description (GSD) file, which typically corresponds to a physical device.

Reading I Data

To create an I Data resource, the offset in bytes for a modules data item must be calculated.

The data items are located in the IOData, Input and DataItem tags of the General Station Description Markup Language (GSDML) file, as shown in the following example file:

<ModuleItem ID="AI 4xI 2-/4-wire ST" ModuleIdentNumber="0x00004A41">
    <ModuleInfo CategoryRef="AI Module" SubCategory1Ref="AI 4xI 2-/4-wire ST">
        <Name TextId="AI 4xI 2-/4-wire ST AI4" />
        <InfoText TextId="Info_AI 4xI 2-/4-wire ST AI4" />
        <OrderNumber Value="6ES7 134-6GD00-0BA1" />
        <SoftwareRelease Value="V1.0" />
    </ModuleInfo>
    <VirtualSubmoduleList>
        <VirtualSubmoduleItem ID="AI 4xI 2-/4-wire ST_01" 
                              SubmoduleIdentNumber="0x00000004" 
                              FixedInSubslots="1" 
                              Writeable_IM_Records="1 2 3" 
                              MayIssueProcessAlarm="false">
            <IOData>
                <Input>
                    <DataItem DataType="Integer16" UseAsBits="false" TextId="I-channel 0"
                    />
                    <DataItem DataType="Integer16" UseAsBits="false" TextId="I-channel 1"
                    />
                    <DataItem DataType="Integer16" UseAsBits="false" TextId="I-channel 2"
                    />
                    <DataItem DataType="Integer16" UseAsBits="false" TextId="I-channel 3"
                    />
                </Input>
            </IOData>

The first item has an offset of zero (0), the offset of subsequent items is based on the size, in bytes of the preceding data items. For example, a data item with a DataType of Integer8 occupies one byte, and a data item with a DataType of Unsigned32 occupies four bytes. The I-offset attribute for each resource must be set to the appropriate byte offset.

The size of the data type is used to determine the length of data that is read for each device resource data type. For Float types this may be over-ridden to a smaller size.

Individual data bits may be read by using a bool-typed device resource, you must specify both the byte offset and the bit address.

This is defined in the device profile using the following format, where <byte offset> is the byte offset and <bit address> is the bit address for bool device resources:

{
  "name": "<I data resource name>",
  "description": "<description of resource>",
  "attributes": {
    "I-offset": <byte offset>,
    "I-offset-bits": <bit address>
  },
  "properties": {
    "valueType": "bool",
    "readWrite": "R"
  }
}

For example, based on the GSDML file above, a suitable profile would be as follows:

{
  "name": "AI 4xU/I 2-wire ST",
  "model": "AI 4xU/I 2-wire ST V1.0",
  "description": "Analog input module AI4 x U/I 2-wire ST; 16-bit, common mode voltage 10V;configurable diagnostics;supports PROFIenergy ",
  "labels": [],
  "deviceResources": [
  {
    "description": "I-channel 0",
    "properties": {
      "valueType": "int16",
      "readWrite": "R"
    },
    "name": "I-channel 0",
    "attributes": {
      "I-offset": 0
    }
  },
  {
    "description": "I-channel 1",
    "properties": {
      "valueType": "int16",
      "readWrite": "R"
    },
    "name": "I-channel 1",
    "attributes": {
      "I-offset": 2
    }
  },
  {
    "description": "I-channel 2",
    "properties": {
      "valueType": "int16",
      "readWrite": "R"
    },
    "name": "I-channel 2",
    "attributes": {
      "I-offset": 4
    }
  },
  {
    "description": "I-channel 3",
    "properties": {
      "valueType": "int16",
      "readWrite": "R"
    },
    "name": "I-channel 3",
    "attributes": {
      "I-offset": 6
    }
  }]
}

Writing Q Data

To create a Q Data resource, the byte offset must be calculated for the data items in the IOData, Input and DataItem tags of the GSDML file.

For each resource, you must set the Q-offset attribute to the appropriate byte offset.

The size of the data type is used to determine the length of data that is written for each device resource data type. For Float types this may be over-ridden to a smaller size.

Data Types

The PROFINET Device Service supports the following data types:

  • Bool (read-only)
  • Int8, Int16, Int32, Int64
  • UInt8, UInt16, UInt32, UInt64
  • Float32, Float64

For the floating-point types, unsigned integer data is read from the device and converted into a float value.

Device Commands

See the Device Profiles page for details on how to define device commands for grouping device resources for fewer requests.

PROFINET Device Provisioning

To provision devices, the base addresses for each device must be determined. The base addresses are defined in the Element XML tag with AID attributes in the Siemens TIA Portal-generated PROFINET configuration file. The following AID attribute settings contain the information required:

AID Description
"6" Base I address for a device

Specified using an I-base protocol field
"7" Size of the I address transfer area

If set to zero (0), no output is provided
"8" Base Q address for a device

Specified using a Q-base protocol field
"9" Size of the Q address transfer area

If set to zero (0), no output is provided

For example, the following extract from a PROFINET XML configuration file defines a device with a AID of "8" (Q-base) set to 1 :

<Object Name="AQ 4xU/I ST_1">
  <ClassRID>7</ClassRID>
  <Key AID="1">4</Key>
  <Object Name="AQ 4xU/I ST_1">
    <ClassRID>10</ClassRID>
    <Key AID="2">1</Key>
    <Variable Name="LADDR">
      <AID>10</AID>
      <Value Datatype="Scalar" Valuetype="UINT16">285</Value>
    </Variable>
    <Variable Name="DataRecordsConf">
      <AID>11</AID>
      <Value Datatype="SparseArray" Valuetype="BLOB">
        <Field Key="128" Length="26">0006010200000000010000000000030200000000030200000000</Field>
        <Field Key="243" Length="4">01000000</Field>
      </Value>
    </Variable>
    <Variable Name="DataRecordsTransferSequence">
      <AID>14</AID>
      <Value Datatype="Scalar" Valuetype="BLOB" Length="0" />
    </Variable>
    <Variable Name="IOmapping">
      <AID>5</AID>
      <Value Datatype="Scalar" Valuetype="STRUCT">
        <Element AID="6" Datatype="Scalar" Valuetype="UINT32">0</Element>
        <Element AID="7" Datatype="Scalar" Valuetype="UINT16">0</Element>
        <Element AID="8" Datatype="Scalar" Valuetype="UINT32">1</Element>
        <Element AID="9" Datatype="Scalar" Valuetype="UINT16">8</Element>
      </Value>
    </Variable>
  </Object>

The following extract shows some example device configurations:

{
  "DI 8x24VDC ST_1": {
    "protocols": {
      "Profinet": {
        "I-base": 0
      }
    },
    "profile": "DI 8x24VDC ST"
  },
  "DQ 8x24VDC/0.5A ST_1": {
    "protocols": {
      "Profinet": {
        "Q-base": 0
      }
    },
    "profile": "DQ 8x24VDC/0.5A ST"
  },
  "AI 4xU/I 2-wire ST_1": {
    "protocols": {
      "Profinet": {
        "I-base": 1
      }
    },
    "profile": "AI 4xU/I 2-wire ST"
  },
  "AQ 4xU/I ST_1": {
    "protocols": {
      "Profinet": {
        "Q-base": 1
      }
    },
    "profile": "AQ 4xU/I ST"
  }
}

PROFINET Device Service Interaction

For information on how to dynamically execute reads, writes, setting up schedules, triggering device discovery and much more, please refer to the MQTT API Guide.

For interactive examples of the PROFINET Device Services refer to PROFINET Xrt Example.

Alarm Types

An alarm is triggered automatically when the conditions are met for triggering that alarm, as described in the table below. A notification is sent if a NotificationTopic has been configured, otherwise the triggering of the alarm is logged in the device service log.

The following table describes the PROFINET alarm types:

Alarm Type Description
PNIO_ALARM_DIAGNOSTIC Indicates appearing or disappearing items for one or more channels
PNIO_ALARM_PROCESS Indicates that an event has occurred outside of the device

For example, a temperature limit was exceeded
PNIO_ALARM_PULL Indicates that a module or sub-module has been pulled
PNIO_ALARM_PLUG Indicates that a module or sub-module has been plugged in
PNIO_ALARM_STATUS Indicates that the status in a module or sub-module has changed
PNIO_ALARM_UPDATE Indicates that the parameters in a module or sub-module have changed
PNIO_ALARM_REDUNDANCY Indicates a change to a redundant AR pair
PNIO_ALARM_CONTROLLED_BY_SUPERVISOR Indicates that the control of an IO device has been taken over by a supervisor
PNIO_ALARM_RELEASED_BY_SUPERVISOR Indicates that the control of the IO device has been released
PNIO_ALARM_PLUG_WRONG Indicates that an incorrect module or sub-module is plugged in instead of the required module or sub-module
PNIO_ALARM_RETURN_OF_SUBMODULE Indicates one of the following:
  • A device has supplied valid data again for a particular input element
  • An output element can process the received data again
PNIO_ALARM_DIAGNOSTIC_DISAPPEARS Indicates detailed disappearing items
PNIO_ALARM_MCR_MISMATCH Indicates that the multicast cognitive radio (CR) has had a problem
PNIO_ALARM_PORT_DATA_CHANGED Indicates a change of port data

For example, a link is up or down
PNIO_ALARM_SYNC_DATA_CHANGED Indicates a change to the clock synchronization
PNIO_ALARM_ISOCHRONE_MODE_PROBLEM Indicates a problem with isochronous applications
PNIO_ALARM_NETWORK_COMPONENT_PROBLEM Indicates a problem with the network components

For example, frames have been dropped due to a resource bottleneck
PNIO_ALARM_TIME_DATA_CHANGED Indicates a change in the time synchronization
PNIO_ALARM_DFP_PROBLEM Indicates a problem occurred during the dynamic frame packing operation
PNIO_ALARM_MRPD_PROBLEM Indicates a problem during a Media Redundancy for Planned Duplication (MRPD) operation
PNIO_ALARM_MULTIPLE_INTERFACE Indicates an inconsistent setting of parameters, which affects more than one interface
PNIO_ALARM_UPLOAD_AND_STORAGE Used in connection with Upload and Storage display
PNIO_ALARM_PULL_MODULE Indicates that a module has been pulled
PNIO_ALARM_DEV_FAILURE Indicates the release of an application relationship (AR) with the IO device
PNIO_ALARM_DEV_RETURN Indicates that an AR is established with the IO device

Note

Some of these alarms might never be triggered, as they are part of the PN-IRT mode.

In addition, notifications or logs are generated when certain PROFINET events occur, as shown in the following table:

Event Type Description Additional included information
PNIO_CBE_MODE_IND Indicates that the local operating mode has changed The new mode - OFFLINE, CLEAR or OPERATE
PNIO_CBE_DEV_ACT_CONF Indicates that the status of the connection to a device has changed Whether the device has been activated or deactivated
PNIO_CBE_PRM_IOSYS_CONF Indicates that IO system has been reconfigured The outcome of the reconfiguration - all devices activated, all devices deactivated, or the reconfiguration failed

Run the PROFINET Device Service

Run Natively with Edge Xrt

To run the PROFINET Device Service natively with Edge Xrt, complete the following steps:

  1. Provide the Edge Xrt executable with the capability to create raw sockets using the following command:

    sudo setcap cap_net_admin,cap_net_raw,cap_sys_nice=eip xrt

  2. The Edge Xrt executable will now run with privileges, so the LD_LIBRARY_PATH environment variable will not be effective. Instead the system linker must be configured to provide the required libraries. Create a file to provide the path to the Edge Xrt shared libraries:

    sudo sh -c 'echo /opt/iotech/xrt/lib/ > /etc/ld.so.conf.d/libxrt-profinet-device-service.conf'

  3. Reload and cache the latest shared libraries using the following command:

    sudo ldconfig

  4. Ensure that the device profiles are in the config folder and the environment variables for the device service are correctly set. For further information on device profiles, see PROFINET Device Profile.

  5. Finish running the device service using the steps on the Run Device Services page.

Run with Xrt Docker Container

Find details on how to run PROFINET Device service in a docker container at Run PROFINET Docker.