Home » Archived » 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  |
 Joachim Stilz
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 #1756515 is a reply to message #1756468] |
Sat, 18 March 2017 11:25  |
Axel Meinhardt
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 #1758079 is a reply to message #1757811] |
Thu, 23 March 2017 10:51 |
Joachim Stilz
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.
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 |
Henryk Fischer
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"
}
}
}
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 11:48:27 GMT 2024
Powered by FUDForum. Page generated in 0.03721 seconds |
] 
Search
Help
Register
Login
Home
