| {"name":"Version-3","content":"<p>After a long discussion phase, the Production Performance Management Protocol version 3 is finally linked on the specification page. Special thanks to <a href=\"https://github.com/bgusach\">bgusach</a>, <a href=\"https://github.com/bf-bryants\">bf-bryants</a>, <a href=\"https://github.com/muelsen\">muelsen</a> and <a href=\"https://github.com/alaendle\">alaendle</a> for their contributions <a href=\"https://github.com/eclipse/unide/issues\">via github issues</a>!</p>\n<h1>The most important changes</h1>\n<ul>\n<li><code>context</code> section in <code>measurements</code><br>\nThe optional context section ccontains information on how to interpret the measurements. This includes\n<ul>\n<li>the field '<code>type</code>' (Number, String or Boolean value) indicates which format the <code><values></code> of a <code>series</code> have.</li>\n<li>The <code>unit</code> key can be used to describe the unit of measurement. There are different understandings and standarizations for units ('C' stands for Coulomb, not Celsius), like <a href=\"https://en.wikipedia.org/wiki/International_System_of_Units\">International System of Units</a>, <a href=\"https://tools.ietf.org/html/draft-ietf-core-senml-14#section-12.1\">SenML</a>, <a href=\"https://www.iso.org/obp/ui/#iso:std:iso:80000:-1:ed-1:v1:en\">ISO 80000-1:2009</a>, etc.. The <code>unit</code> key here is a string without further restriction. If that is needed, it can be specified via an URI in <code>namespace</code>.</li>\n<li><code>namespace</code> may contain an URI to identify further detail on the values in this measurement section. This can be a description of units, lengths or naming conventions for measurement points, but also a reference to a semantic model.</li>\n</ul>\n</li>\n<li><code>series</code> can contain other than numeric measurements<br>\nif <code>context.type</code> contains any of 'BASE64', 'BOOLEAN', 'NUMBER', 'STRING', 'REF' or 'OTHER', the corresponding measurement in <code>series</code> are represented in this type ('REF', 'OTHER' and 'BASE64' are Strings). This way for example, even small base64 encoded binary data, as send from iolink devices, can be included. 'REF' could be used in multipart messages to reference to other sections or even external content.</li>\n<li><code>mode</code> and <code>state</code> are introduced in <code>device</code> and replaces v2's <code>operationalMode</code>, which was found to not clearly diffentiate the functional mode and technical state.</li>\n<li>A common <code>id</code> was used and replaces different spellings in <code>deviceID</code>, <code>partID</code>, <code>program.id</code>.</li>\n<li><code>additionalData</code> in the various sections is used for any kind of not-specified data, that should be included in the telegram. Where v2's <code>metaData</code> had to be key/String pairs, <code>additionalData</code> can also be complex JSON objects.</li>\n<li><code>time</code> field replaces the v2 <code>$_time</code> field, which is difficult to represent in some programming languages. Note that <code>time</code> is not an Integer anymore but a JSON number, to allow sub-millisecond values.</li>\n<li>no more <code>shutoffValues</code> and <code>shutoffPhase</code><br>\n<code>shutoffValues</code> can be expressed as specialValues with a meaningful <code>name</code>, <code>shutoffPhase</code> is the measurement with the latest timestamp <code>ts</code>.</li>\n<li>a common definition.json schema is used for sections that are used in multiple telegrams. With the help of JSON schema 'anyOf', sections inherit and can extend from these base definitions.</li>\n</ul>\n<h1>Next steps</h1>\n<p>The most recent updates and this post should finalize the v3 schema. Vetos with suggestions that find a consensus fairly soon after posting are stil accepted <a href=\"https://github.com/eclipse/unide/issues\">via github issues</a>. Major changes and suggestions should rather be addressed to a v4.</p>\n<p>The bindings and server should be updated to accept and validate v3 as well. After updating further dependencies, creating eclipse CQs and undergoing the release process, everything should be wrapped up in the unide release 0.3.0.</p>\n","url":"/blog/2019/3/1/Version-3","title":"Protocol Version 3 release candidate","date":"2019-03-01T00:00:00.000Z","tags":["v3"],"prev":{"url":"/blog/2018/9/4/Template-for-PPMP-transformation","title":"Use Cases: Template for transformation"},"next":{"url":"/blog/2019/11/26/Version-3-final","title":"Protocol v3 final"}} |