Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Unide » Support for raw IO-Link process data(Extend PPMP to support a hex-coded string in the series array)
Support for raw IO-Link process data [message #1755668] Mon, 06 March 2017 17:19 Go to next message
Joachim Stilz is currently offline Joachim StilzFriend
Messages: 5
Registered: March 2017
Junior Member
Extend PPMP to support a hex-coded string in the series array

A PPMP measurement message is intended to contain several measurement values of a sensor (or many sensors in a machine).

If you configure suitable intervals for measurement and reporting you will see one or more entries in the series array of your PPMP measurement message (see example below). The current PPMP specification allows only single precision float values as values of this array. This suits for many values like bool, (smaller) integers and (of course) floats.

The problem is that IO-Link sensors normally do have many process data items and do not deliver any description for the value together with the process data. This information is not avaliable on the point where the PPMP measurement message is created at first.

Aggregators could parse IODDs, that contain a description of the process data values and generate more meaningful PPMP measurement messages out of more primitive ones. IODDs for different sensors can be retrieved by the the IODDfinder [1].

Regarding this fact, I suggest to extend the PPMP measurement message specification to deal with raw IO-Link process data. The raw data can be delivered as a string that represents the process data with hex numbers (see example below).
A comment in the JSON indicates the part of the message that is not conform to the current state of the PPMP specification yet.

The IO-Link specification [2] allows a variable length of process data with a maximum length of 32 bytes.
It would be the most efficient and convenient way to deliver only as much bytes as stated by the process data length of the IO-Link sensor. This value is avaliable over the Direct Parameter page 1 [3] of the IO-Link sensor .
If the process data length is not divisible by 8, the string is padded with a zero to achieve byte alignment. The least significant byte (LSB) is represented by the two last digits of the string.

Example
{
  "content-spec": "urn:spec://eclipse.org/unide/measurement-message#v2",
  "device": {
    "deviceID": "00:19:31:AB:CD:EF/0",
    "metaData": {
      "iolApplicationSpecificTag": "blabla",
      "iolDeviceId": "123456",
      "iolProductName": "<Product Name of the sensor>",
      "iolVendorId": "888"
    }
  },
  "measurements": [
    {
      "ts": "2017-03-06T12:01:30.834Z",
      "series": {
        "$_time": [
          189,
          677,
          1167,
          1660
        ],
        "iolProcessData": [    
          "0x1AB62F",            /* strings are not allowed in the */
          "0x1A459E",            /* current state of the PPMP specification */
          "0x1AB07D",
          "0x1AB38C"
        ]
      }
    }
  ]
}


What do you think about this suggestion? Is it possible to realize this in the PPM (Production Performance Manager)? Can it be done in a much better way?
I look forward to receive some feedback!


[1] ioddfinder.io-link.com/#/
[2] io-link.com/share/Downloads/Spec-Interface/IOL-Interface-Spec_10002_V112_Jul13.pdf#page=164
[3] io-link.com/share/Downloads/Spec-Interface/IOL-Interface-Spec_10002_V112_Jul13.pdf#page=214

[Updated on: Thu, 09 March 2017 14:11]

Report message to a moderator

Re: Support for raw IO-Link process data [message #1755788 is a reply to message #1755668] Wed, 08 March 2017 08:40 Go to previous messageGo to next message
Markus Rentschler is currently offline Markus RentschlerFriend
Messages: 3
Registered: March 2017
Junior Member
I would like to add some information regarding the IODD. This a device description file that every IO-Link device comes with. It uses standardized sematics, allowing an application to interpret the content of the raw process data. With PPMP, the application can identify the IO-Link-Device via iolVendorId and and iolDeviceId. With this information, the IODD related to that device can be downloaded manually via WEB-GUI or via REST-API from the publicly accessible "IODDfinder", a cloud-based service provided by the IO-Link-Community (ioddfinder.io-link.com/#/).

Re: Support for raw IO-Link process data [message #1755809 is a reply to message #1755668] Wed, 08 March 2017 11:01 Go to previous messageGo to next message
Markus Rentschler is currently offline Markus RentschlerFriend
Messages: 3
Registered: March 2017
Junior Member
Tutorials for the IODDfinder can be found here:

IODD Management:

download.cluetec.de/ioddfinder/ioddfinder_tutorial_en_iodd_management.mp4

API Documentation:

download.cluetec.de/ioddfinder/ioddfinder_tutorial_en_api_docs.mp4
Re: Support for raw IO-Link process data [message #1756468 is a reply to message #1755809] Fri, 17 March 2017 12:27 Go to previous messageGo to next message
Joachim Stilz is currently offline Joachim StilzFriend
Messages: 5
Registered: March 2017
Junior Member
On the Bosch Connected Experience (BCX17) I did not use the opportunity to talk in detail about the modification of the PPM server of the unide project.
We want to have a prototypical implementation for the support of multiple datatypes in the series-field, especially for a string.
Who is the developer who will integrate poll requests, do further development and give support for the unide server?
Re: Support for raw IO-Link process data [message #1756515 is a reply to message #1756468] Sat, 18 March 2017 11:25 Go to previous messageGo to next message
Axel Meinhardt is currently offline Axel MeinhardtFriend
Messages: 5
Registered: August 2016
Junior Member
Thanks for the suggestion!
I understand the main objective of the request is to transmit binary data in the message rather than describing process characteristics (process id, program, phases, final/special values). Is it?

We have chosen JSON as serialization format because it is, in our opinion, the best compromise of a structured, human readable, widely adopted and compact format. It doesn't support binary data types, though. We should still consider adding such fields.
Instead of including an 32 octed in hex array with '0x' prepended every time, I would prefer a plain base64 string, following google protobuf mappings. I know base64 is not very efficient. But as this type is generic, it could even be used to add a picture to the machine message metaData.

Having in mind to not putting much restrictions on the communication channel and the used programing language for the marshaller, we could point out options on how to serialize to more efficient (but less understandable) formats.
There are so many different ways of encoding binary data (mimetype encoding, BSON, protobuf or Colfer...). I like the continous development, supported languages and documentation of protobuf, although it might not necessarly be the most efficient.
Re: Support for raw IO-Link process data [message #1757811 is a reply to message #1756515] Mon, 20 March 2017 08:39 Go to previous messageGo to next message
Markus Rentschler is currently offline Markus RentschlerFriend
Messages: 3
Registered: March 2017
Junior Member
Axel Meinhardt wrote on Sat, 18 March 2017 11:25

Instead of including an 32 octed in hex array with '0x' prepended every time, I would prefer a plain base64 string, following google protobuf mappings. ...as this type is generic, it could even be used to add a picture to the machine message metaData.


I believe this is a very good idea and we should go that way.

Best Regards,
Markus
icon1.gif  Re: Support for raw IO-Link process data [message #1758079 is a reply to message #1757811] Thu, 23 March 2017 10:51 Go to previous messageGo to next message
Joachim Stilz is currently offline Joachim StilzFriend
Messages: 5
Registered: March 2017
Junior Member
Here is a suggestion, how the measurement-message#v3 could look like.

I extended the UML diagram of the measurement message to support multiple datatypes for the series array. The yellow marked texts were added or changed.

index.php/fa/28847/0/

The changed part is:

  • The data type of the values list in the series array. It was float and is now DataType.

The added parts are ...

  • an enumeration DataType that contains all possible data types for the values list in the series array.
  • a map that describes for each column of the object series which datatype the elements do have.


An example of the new message format (reporting the process data of an IO-Link sensor and a temperature value) could look like the following example. (In reality the temperature sensor should not be in the same message because it has an own deviceID. But to demonstrate the Map of Datatypes I did so.)
{
  "content-spec": "urn:spec://eclipse.org/unide/measurement-message#v3",
  "device": {
    "deviceID": "00:19:31:AB:CD:EF/0",
    "metaData": {
      "iolApplicationSpecificTag": "blabla",
      "iolDeviceId": "123456",
      "iolProductName": "<Product Name of the sensor>",
      "iolVendorId": "888"
    }
  },
  "measurements": [
    {
      "ts": "2017-03-06T12:01:30.834Z",
      "datatypes": {
        "iolProcessData": "BASE64",
        "temperature": "NUMBER"
      },
      "series": {
        "$_time": [
          189,
          677,
          1167,
          1660
        ],
        "iolProcessData": [
          "ASNFZ8KJwqvDjcOv",
          "wonCq8ONw68BI0Vn",
          "wpMSw6vDusOIw5U7Qg==",
          "w77DnMK6wph2VDIQ"
        ],
        "temperature": [
          22.5,
          22.51,
          22.5,
          22.49
        ]
      }
    }
  ]
}




The different datatypes that should be supported have to be discussed in greater detail.

  • A STRING datatype is manybe not needed at all?
  • The number datatype would be the number of JSON. Each implementation of PPMP will (hopefully) use a JSON library and so dealing with the number format of JSON should not be a problem.
    But there is also the possibility to define many datatypes such as uint8_t, int32_t and so on but I think this is not useful because you have to regard minimum and maximum sizes in this case.


What do you think about this suggestion?

Re: Support for raw IO-Link process data [message #1758173 is a reply to message #1758079] Fri, 24 March 2017 09:34 Go to previous messageGo to next message
Henryk Fischer is currently offline Henryk FischerFriend
Messages: 3
Registered: March 2017
Junior Member
Hi,

looks interesting. In this thread are the requirements for metaData of measurements described. Maybe we can have a combination of both, so that the DataTypes are part of the metaData block.

How about this:

{
  "ts": "...",
  "series": {
    "$_time": [ ... ],
    "temperature": [ ... ],
    "pressure": [ ... ]
  },
  "metaData": {
     "temperature": {
       "unit": "Fahrenheit",
       "gradient": "1.8",
       "offset": "32",
       "dataType": "NUMBER"
    },
     "pressure": {
	"dataType": "BASE64"
    }
  }
}
Re: Support for raw IO-Link process data [message #1758286 is a reply to message #1758173] Mon, 27 March 2017 08:02 Go to previous message
Joachim Stilz is currently offline Joachim StilzFriend
Messages: 5
Registered: March 2017
Junior Member
Yes, looks good.
Next Topic:Meta data for PPMP measurement messages
Goto Forum:
  


Current Time: Sat Sep 22 10:40:55 GMT 2018

Powered by FUDForum. Page generated in 0.01988 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top