sensorconnect

The microservice sensorconnect automatically detects ifm gateways in the specified network and reads out their sensor values in the highest possible data frequency (or the chosen data frequency). It provides plug-and-play access to IO-Link sensors connected to ifm gateways. Digital input mode is also supported. A typical setup contains multiple sensors connected via LAN to your server infrastructure. The sensorconnect microservice constantly monitors a given IP range for gateways. Once a gateway is found, it automatically starts requesting, receiving and processing sensor data in short intervals. The received data is preprocessed based on a database including thousands of sensor definitions. And because we strongly believe in open industry standards, sensorconnect brings the data via MQTT or Kafka to your preferred software solutions (for example, features of the United Manufacturing Hub or the cloud).

Underlying functionality

Sensorconnect downloads relevant IODD files automatically after installation from the IODDfinder webpage. If an unknown server is connected later, sensorconnect will automatically download the file. We will also provide a folder to manually deposit IODD-files, if the automatic download doesn’t work (e.g. no internet connection).

REST API POST requests from sensorconnect to the gateways

Sensorconnect scans the IP range for new ifm gateways (used to connect the IO-Link devices to). To do that, sensorconnect iterates through all the possible IP addresses in the specified IP address range (“http://"+url, payload, timeout=0.1). It stores the IP addresses with the product codes and the individual serial numbers.

Scanning with the following payload: (Information send during a POST request to the ifm gateways)

{
  "code":"request",
  "cid":-1, // The cid (Client ID) can be chosen.
  "adr":"/getdatamulti",
  "data":{
    "datatosend":[
      "/deviceinfo/serialnumber/","/deviceinfo/productcode/"
      ]
    }
}

Example answer from gateway

{
    "cid": 24,
    "data": {
        "/deviceinfo/serialnumber/": {
            "code": 200,
            "data": "000201610192"
        },
        "/deviceinfo/productcode/": {
            "code": 200,
            "data": "AL1350"
        }
    },
    "code": 200
}

All port modes of the connected gateways are requested. Depending on the productcode, the total number of ports on the gateway can be determined and iterated through.

Requesting port modes with following payload: (information sent during a POST request to the ifm gateways)

{
  "code":"request",
  "cid":-1,
  "adr":"/getdatamulti",
  "data":{
    "datatosend":[
      "/iolinkmaster/port[1]/mode",
      "/iolinkmaster/port<i>/mode" //looping through all ports on gateway
      ]
    }
}

Example answer from gateway

{
    "cid": -1,
    "data": {
        "/iolinkmaster/port[1]/mode": {
            "code": 200,
            "data": 3
        },
        "/iolinkmaster/port[2]/mode": {
            "code": 200,
            "data": 3
        }
    }
}

If the mode == 1: port_mode = “DI” (Digital Input)

If the mode == 2: port_mode = “DO” (Digital Output)

If the mode == 3: port_mode = “IO_Link”

All values of accessible ports are requested as fast as possible (ifm gateways act as a bottleneck).

Requesting IO_Link port values with following payload: (information sent during a POST request to the ifm gateways)

{
  "code":"request",
  "cid":-1,
  "adr":"/getdatamulti",
  "data":{
    "datatosend":[
      "/iolinkmaster/port[1]/iolinkdevice/deviceid",
      "/iolinkmaster/port[1]/iolinkdevice/pdin",
      "/iolinkmaster/port[1]/iolinkdevice/vendorid",
      "/iolinkmaster/port[1]/pin2in",
      "/iolinkmaster/port[<i>]/iolinkdevice/deviceid",//looping through all connected ports on gateway
      "/iolinkmaster/port[<i>]/iolinkdevice/pdin",
      "/iolinkmaster/port[<i>]/iolinkdevice/vendorid",
      "/iolinkmaster/port[<i>]/pin2in"
      ]
  }
}

Example answer from gateway

{
    "cid": -1,
    "data": {
        "/iolinkmaster/port[1]/iolinkdevice/deviceid": {
            "code": 200,
            "data": 278531
        },
        "/iolinkmaster/port[1]/iolinkdevice/pdin": {
            "code": 200,
            "data": "0101" // This string contains the actual data from the sensor. In this example it is the data of a buttonbar. The value changes when one button is pressed. Interpreting this value automatically relies heavily on the IODD file of the specific sensor (information about which partition of the string holds what value (type, value name etc.)).
        },
        "/iolinkmaster/port[1]/iolinkdevice/vendorid": {
            "code": 200,
            "data": 42
        },
        "/iolinkmaster/port[1]/pin2in": {
            "code": 200,
            "data": 0
        }
    },
    "code": 200
}

IODD file management

Based on the vendorid and the deviceid (extracted out of the received data from the ifm gateway), sensorconnect looks in its persistent storage if an IODD file is available. If there is no IODD file stored in the specific sensor, it tries to download a file online and saves it. If this also is not possible, sensorconnect doesn’t preprocess the pdin data entry and forwards it as is.

Data interpretation (key:pdin) with IODD files

The IODD files are in xml format and often contain multiple thousand You can find extensive documentation on the (IO-Link website)[https://io-link.com/en/Download/Download.php]. Especially relevant areas of the IODD files are for our use case:

• IODevice/DocumentInfo/version: version of IODD files.
• IODevice/ProfileBody/DeviceIdentity: deviceid, vendorid, etc.
• IODevice/DeviceFunction/ProcessDataCollection/ProcessData/ProcessDataIn: contains information about the data structure received from the sensor. Datatypes and data references are given.
• IODevice/DeviceFunction/DatatypeCollection: if used, contains datatypes references by the ProcessDataCollection.
• IODevice/ExternalTextCollection: contains translation for textIDs

Digital input data management

The gateways are also able to receive digital input data (not IO-Link). This data is also requested and forwarded.

Data delivery to MQTT or Kafka

For delivery of the data, sensorconnect converts the data into a JSON containing the preprocessed data, timestamps, serialnumbers etc. and sends in via MQTT to the MQTT broker or via Kafka to the Kafka broker. You can change the environment variables to choose your preferred protocol.

Environment variables