blog/2019/11/26/Version-3-final/index.html - www.eclipse.org/unide - Git at Google

 <!doctype html>
 <html data-n-head-ssr data-n-head="">
   <head data-n-head="">
     <title data-n-head="true">Eclipse unide - Protocol v3 final</title><meta data-n-head="true" charset="utf-8"><meta data-n-head="true" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="true" data-hid="description" name="description" content="Eclipse Unide: Understand Industry devices"><link data-n-head="true" rel="icon" type="image/x-icon" href="/unide/favicon.ico"><base href="/unide/"><link rel="stylesheet" href="/unide/files/aacbf5835f7143d93ae2.css"><link rel="stylesheet" href="/unide/files/08ee945502042ce842dc.css">
   </head>
   <body data-n-head="">
     <div data-server-rendered="true" id="__nuxt"><!----><div id="__layout"><div><header class="nav-header"><div class="container"><nav class="navbar"><div id="navMenu" class="navbar-menu"><div class="navbar-start"><a href="/unide/" class="navbar-item">
       Home
     </a> <a href="/unide/proposal" class="navbar-item">
       Proposal
     </a> <a href="/unide/specification" class="navbar-item">
       Specification
     </a> <a href="/unide/blog" class="navbar-item is-active">
       Blog Archives
     </a> <a href="/unide/faq" class="navbar-item">
       FAQ
     </a></div></div> <div class="navbar-brand"><div class="navbar-burger burger"><span></span> <span></span> <span></span></div> <a href="/unide/" class="navbar-item nuxt-link-active"><img src="logo.svg"></a></div></nav></div></header> <div class="container"><div class="header clearfix"></div> <div class="columns"><div class="article column is-8"><h1 class="title is-3">
     Protocol v3 final
   </h1> <h2 class="subtitle is-6"><i class="fa fa-calendar"></i>
     11/26/19
   </h2> <div class="content"><div><p>Version 3 of the Production Performance Management Protocol (Production Performance Management Protocol) has been finalized!<br>
 Thanks to CONTACT Software, Balluff GmbH, Bosch Plant Blaichach and Bosch Connected Industry for their proposals, ideas and patience.<br>
 The major improvements in Version 3 include consistent structure and naming, context for measurements and better extensibility.</p>
 <h1>Easy validation</h1>
 <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>
 <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
   <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>
 <span class="token punctuation">}</span>
 </code></pre>
 <h1>Changes</h1>
 <h2>General</h2>
 <ul>
 <li><code>content-spec</code> is now "urn:spec://eclipse.org/unide/&lt; type >-message#<strong>v3</strong>"</li>
 <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>
 <li>A common <code>id</code> is used and replaces different spellings in <code>deviceID</code>, <code>partID</code>, <code>program.id</code>.</li>
 <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>
 <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>
 <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>
 </ul>
 <h2><code>messages</code></h2>
 <ul>
 <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>
 <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>
 <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>
 </ul>
 <h2><code>measurements</code></h2>
 <ul>
 <li>The optional <code>context</code> section contains information on how to interpret the measurements. This includes
 <ul>
 <li>The field <code>type</code> (Number, String or Boolean value) indicates which format the <values> of a series have.</values></li>
 <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>
 <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>
 <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>
 </ul>
 </li>
 <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>
 <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>
 </ul>
 <h2><code>processes</code></h2>
 <ul>
 <li>No more <code>shutoffValues</code> and <code>shutoffPhase</code><br>
 <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>
 <li>Same improvements in measurements</li>
 </ul>
 </div></div> <div class="columns pageNav"><div class="column"><a href="/unide/blog/2019/3/1/Version-3" class="button is-fullwidth"><span class="icon"><i class="fa fa-chevron-left"></i></span> <span>Protocol Version 3 release candidate</span></a></div> <!----></div></div> <div class="sidebar column is-3 is-offset-1"><div class="recentPosts"><h4 class="subtitle is-5">
     Recent Posts
   </h4> <ul><li><a href="/unide/blog/2019/11/26/Version-3-final" class="nuxt-link-exact-active nuxt-link-active">
         Protocol v3 final
       </a></li><li><a href="/unide/blog/2019/3/1/Version-3">
         Protocol Version 3 release candidate
       </a></li><li><a href="/unide/blog/2018/9/4/Template-for-PPMP-transformation">
         Use Cases: Template for transformation
       </a></li><li><a href="/unide/blog/2018/3/26/Release-0.2.0">
         Unide 0.2.0 released
       </a></li><li><a href="/unide/blog/2018/2/13/grinding-machine-scenario">
         Use Cases: Unide and the Eclipse Testbed
       </a></li></ul></div> <div class="blogArchives"><h4 class="subtitle is-5">
     Blog Archives
   </h4> <ul><li><a href="/unide/blog/2019/11" class="nuxt-link-active">
         December 2019
       </a>
       (1)
     </li><li><a href="/unide/blog/2019/3">
         April 2019
       </a>
       (1)
     </li><li><a href="/unide/blog/2018/9">
         October 2018
       </a>
       (1)
     </li><li><a href="/unide/blog/2018/3">
         April 2018
       </a>
       (1)
     </li><li><a href="/unide/blog/2018/2">
         March 2018
       </a>
       (2)
     </li><li><a href="/unide/blog/2018/1">
         February 2018
       </a>
       (1)
     </li><li><a href="/unide/blog/2017/10">
         November 2017
       </a>
       (2)
     </li><li><a href="/unide/blog/2017/6">
         July 2017
       </a>
       (2)
     </li><li><a href="/unide/blog/2017/3">
         April 2017
       </a>
       (1)
     </li><li><a href="/unide/blog/2016/9">
         October 2016
       </a>
       (4)
     </li></ul></div></div></div></div> <footer class="footer"><div class="container"><div class="columns is-mobile is-multiline is-centered"><div class="column is-narrow"><a href="http://www.eclipse.org">Eclipse Foundation</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/privacy.php">Privacy Policy</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/termsofuse.php">Terms of Use</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/copyright.php">Copyright Agent</a></div> <div class="column is-narrow"><a href="https://eclipse.org/security/">Security reports</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/">Legal</a></div></div></div></footer></div></div></div><script>window.__NUXT__={layout:"sidebar",data:[{post:{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 &quot;urn:spec://eclipse.org/unide/&lt; type &gt;-message#<strong>v3</strong>&quot;</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 &quot;<em>pressure too high</em>&quot; and &quot;<em>pressure not too high anymore</em>&quot;.</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:new Date(15747264e5),tags:["v3"],prev:{url:"/blog/2019/3/1/Version-3",title:"Protocol Version 3 release candidate"}}}],error:null,serverRendered:!0}</script><script src="/unide/files/a195a9468a7b0964153f.js" defer></script><script src="/unide/files/2918aa6661dd624eef70.js" defer></script><script src="/unide/files/c01c4654e10f48ab3d43.js" defer></script><script src="/unide/files/7267eda02aa7844877f4.js" defer></script>
   </body>
 </html>
	<!doctype html>
	<html data-n-head-ssr data-n-head="">
	<head data-n-head="">
	<title data-n-head="true">Eclipse unide - Protocol v3 final</title><meta data-n-head="true" charset="utf-8"><meta data-n-head="true" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="true" data-hid="description" name="description" content="Eclipse Unide: Understand Industry devices"><link data-n-head="true" rel="icon" type="image/x-icon" href="/unide/favicon.ico"><base href="/unide/"><link rel="stylesheet" href="/unide/files/aacbf5835f7143d93ae2.css"><link rel="stylesheet" href="/unide/files/08ee945502042ce842dc.css">
	</head>
	<body data-n-head="">
	<div data-server-rendered="true" id="__nuxt"><!----><div id="__layout"><div><header class="nav-header"><div class="container"><nav class="navbar"><div id="navMenu" class="navbar-menu"><div class="navbar-start"><a href="/unide/" class="navbar-item">
	Home
	</a> <a href="/unide/proposal" class="navbar-item">
	Proposal
	</a> <a href="/unide/specification" class="navbar-item">
	Specification
	</a> <a href="/unide/blog" class="navbar-item is-active">
	Blog Archives
	</a> <a href="/unide/faq" class="navbar-item">
	FAQ
	</a></div></div> <div class="navbar-brand"><div class="navbar-burger burger"><span></span> <span></span> <span></span></div> <a href="/unide/" class="navbar-item nuxt-link-active"><img src="logo.svg"></a></div></nav></div></header> <div class="container"><div class="header clearfix"></div> <div class="columns"><div class="article column is-8"><h1 class="title is-3">
	Protocol v3 final
	</h1> <h2 class="subtitle is-6"><i class="fa fa-calendar"></i>
	11/26/19
	</h2> <div class="content"><div><p>Version 3 of the Production Performance Management Protocol (Production Performance Management Protocol) has been finalized!<br>
	Thanks to CONTACT Software, Balluff GmbH, Bosch Plant Blaichach and Bosch Connected Industry for their proposals, ideas and patience.<br>
	The major improvements in Version 3 include consistent structure and naming, context for measurements and better extensibility.</p>
	<h1>Easy validation</h1>
	<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>
	<pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
	<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>
	<span class="token punctuation">}</span>
	</code></pre>
	<h1>Changes</h1>
	<h2>General</h2>
	<ul>
	<li><code>content-spec</code> is now "urn:spec://eclipse.org/unide/< type >-message#<strong>v3</strong>"</li>
	<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>
	<li>A common <code>id</code> is used and replaces different spellings in <code>deviceID</code>, <code>partID</code>, <code>program.id</code>.</li>
	<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>
	<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>
	<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>
	</ul>
	<h2><code>messages</code></h2>
	<ul>
	<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>
	<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>
	<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>
	</ul>
	<h2><code>measurements</code></h2>
	<ul>
	<li>The optional <code>context</code> section contains information on how to interpret the measurements. This includes
	<ul>
	<li>The field <code>type</code> (Number, String or Boolean value) indicates which format the <values> of a series have.</values></li>
	<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>
	<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>
	<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>
	</ul>
	</li>
	<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>
	<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>
	</ul>
	<h2><code>processes</code></h2>
	<ul>
	<li>No more <code>shutoffValues</code> and <code>shutoffPhase</code><br>
	<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>
	<li>Same improvements in measurements</li>
	</ul>
	</div></div> <div class="columns pageNav"><div class="column"><a href="/unide/blog/2019/3/1/Version-3" class="button is-fullwidth"><span class="icon"><i class="fa fa-chevron-left"></i></span> <span>Protocol Version 3 release candidate</span></a></div> <!----></div></div> <div class="sidebar column is-3 is-offset-1"><div class="recentPosts"><h4 class="subtitle is-5">
	Recent Posts
	</h4> <ul><li><a href="/unide/blog/2019/11/26/Version-3-final" class="nuxt-link-exact-active nuxt-link-active">
	Protocol v3 final
	</a></li><li><a href="/unide/blog/2019/3/1/Version-3">
	Protocol Version 3 release candidate
	</a></li><li><a href="/unide/blog/2018/9/4/Template-for-PPMP-transformation">
	Use Cases: Template for transformation
	</a></li><li><a href="/unide/blog/2018/3/26/Release-0.2.0">
	Unide 0.2.0 released
	</a></li><li><a href="/unide/blog/2018/2/13/grinding-machine-scenario">
	Use Cases: Unide and the Eclipse Testbed
	</a></li></ul></div> <div class="blogArchives"><h4 class="subtitle is-5">
	Blog Archives
	</h4> <ul><li><a href="/unide/blog/2019/11" class="nuxt-link-active">
	December 2019
	</a>
	(1)
	</li><li><a href="/unide/blog/2019/3">
	April 2019
	</a>
	(1)
	</li><li><a href="/unide/blog/2018/9">
	October 2018
	</a>
	(1)
	</li><li><a href="/unide/blog/2018/3">
	April 2018
	</a>
	(1)
	</li><li><a href="/unide/blog/2018/2">
	March 2018
	</a>
	(2)
	</li><li><a href="/unide/blog/2018/1">
	February 2018
	</a>
	(1)
	</li><li><a href="/unide/blog/2017/10">
	November 2017
	</a>
	(2)
	</li><li><a href="/unide/blog/2017/6">
	July 2017
	</a>
	(2)
	</li><li><a href="/unide/blog/2017/3">
	April 2017
	</a>
	(1)
	</li><li><a href="/unide/blog/2016/9">
	October 2016
	</a>
	(4)
	</li></ul></div></div></div></div> <footer class="footer"><div class="container"><div class="columns is-mobile is-multiline is-centered"><div class="column is-narrow"><a href="http://www.eclipse.org">Eclipse Foundation</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/privacy.php">Privacy Policy</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/termsofuse.php">Terms of Use</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/copyright.php">Copyright Agent</a></div> <div class="column is-narrow"><a href="https://eclipse.org/security/">Security reports</a></div> <div class="column is-narrow"><a href="http://www.eclipse.org/legal/">Legal</a></div></div></div></footer></div></div></div><script>window.__NUXT__={layout:"sidebar",data:[{post:{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:new Date(15747264e5),tags:["v3"],prev:{url:"/blog/2019/3/1/Version-3",title:"Protocol Version 3 release candidate"}}}],error:null,serverRendered:!0}</script><script src="/unide/files/a195a9468a7b0964153f.js" defer></script><script src="/unide/files/2918aa6661dd624eef70.js" defer></script><script src="/unide/files/c01c4654e10f48ab3d43.js" defer></script><script src="/unide/files/7267eda02aa7844877f4.js" defer></script>
	</body>
	</html>