| {"name":"Version-3-final","content":"<p>Version 3 of the Production Performance Management Protocol (Production Performance Management Protocol) has been finalized!<br>\nThanks to CONTACT Software, Balluff GmbH, Bosch Plant Blaichach and Bosch Connected Industry for their proposals, ideas and patience.<br>\nThe major improvements in Version 3 include consistent structure and naming, context for measurements and better extensibility.</p>\n<h1>Easy validation</h1>\n<p>Did you know that you can easily validate your payload against the published online version of Production Performance Management Protocol? For example, <a href=\"https://www.jsonschemavalidator.net/\">jsonschemavalidator.net</a> provides an online validation frontend. Just use your payload as JSON input and the respective github link to the Production Performance Management Protocol specification as a <code>$ref</code> in the schema. For example:</p>\n<pre class=\"language-json\"><code class=\"language-json\"><span class=\"token punctuation\">{</span>\n <span class=\"token property\">\"$ref\"</span><span class=\"token operator\">:</span> <span class=\"token string\">\"https://raw.githubusercontent.com/eclipse/unide/master/ppmp/ppmp-schema/src/main/resources/org/eclipse/iot/unide/ppmp/v3/process_schema.json\"</span>\n<span class=\"token punctuation\">}</span>\n</code></pre>\n<h1>Changes</h1>\n<h2>General</h2>\n<ul>\n<li><code>content-spec</code> is now "urn:spec://eclipse.org/unide/< type >-message#<strong>v3</strong>"</li>\n<li><code>mode</code> and <code>state</code> are introduced in <code>device</code> and replace v2's <code>operationalMode</code>, which was found to not clearly differentiate the functional mode and technical state.</li>\n<li>A common <code>id</code> is 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 honored by the receiving party as context information. Where v2's <code>metaData</code> had to be key/String pairs, <code>additionalData</code> can also be complex JSON objects.</li>\n<li>In addition to <code>additionalData</code>, it is possible to include completely undefined keys in most places, in order to introduce custom or future keys. With it, it's e.g. possible to define and test currently meaningless 'window' key as an extension to limits.</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<h2><code>messages</code></h2>\n<ul>\n<li>Messages can have a <code>state</code> to indicate if this alert newly appeared (<code>NEW</code>) or disappeared (<code>ENDED</code>). Together with a common <code>code</code>, it is now possible e.g. to correlate events like "<em>pressure too high</em>" and "<em>pressure not too high anymore</em>".</li>\n<li>What was before <code>type</code> has now been renamed to <code>source</code> to indicate if the message comes from the <code>DEVICE</code> itself or from the general infrastructure <code>TECHNICAL_INFO</code>.</li>\n<li>The <code>type</code> in v3 indicates the debug level of the message (<code>INFO</code>, <code>WARNING</code>, <code>ERROR</code>, <code>UNKNOWN</code>) and complements <code>severity</code> for describing urgency and relevance of a message.</li>\n</ul>\n<h2><code>measurements</code></h2>\n<ul>\n<li>The optional <code>context</code> section contains 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 <values> of a series have.</li>\n<li>The <code>unit</code> key can be used to describe the unit of measurement. There are different understandings and standardizations 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<li>Each entry in <code>limits</code> can be constant or an array of values. If constant, it applies to all corresponding measurements in <code>series</code>. If an array of the same length than the corresponding <code>series</code> is provided, each entry limits the measurement at the respective position. 'null' can be used to skip a limit for an individual measurement.</li>\n</ul>\n</li>\n<li><code>series</code> can contain other than numeric measurements if <code>context.type</code> contains any of 'BASE64', 'BOOLEAN', 'NUMBER', 'STRING', 'REF' or 'OTHER', the corresponding measurement in series 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>time</code> field replaces the v2 <code>$_time</code> field, which is difficult to represent in some programming languages. Note that time is not an Integer anymore but a JSON number, to allow sub-millisecond values.</li>\n</ul>\n<h2><code>processes</code></h2>\n<ul>\n<li>No more <code>shutoffValues</code> and <code>shutoffPhase</code><br>\n<code>shutoffValues</code> can be expressed as <code>specialValues</code> with a meaningful name, <code>shutoffPhase</code> is the measurement with the latest timestamp <code>ts</code>.</li>\n<li>Same improvements in measurements</li>\n</ul>\n","url":"/blog/2019/11/26/Version-3-final","title":"Protocol v3 final","date":"2019-11-26T00:00:00.000Z","tags":["v3"],"prev":{"url":"/blog/2019/3/1/Version-3","title":"Protocol Version 3 release candidate"}} |