Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "IoT/M2MIWG/M2M meta-model"

< IoT
(New page: {{:DocumentationGuidelines/DraftHeader}} = Functional requirements = * The M2M application meta-model MUST allow the description of the different parts an M2M application is made of. **...)
 
m (Webmaster.eclipse.org moved page Iot/M2MIWG/M2M meta-model to IoT/M2MIWG/M2M meta-model)
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{:DocumentationGuidelines/DraftHeader}}
+
{{:DocumentationGuidelines/DraftHeader}}  
  
 +
= General purpose of an M2M application meta-model  =
  
= Functional requirements =
+
The M2M Industry Working Group aims at identifying the concepts that not only are the core of M2M/IoT systems, but are also often hindering the growth of M2M market. In order to ease the development of such solutions (by providing tools to scaffold embedded applications, to simulate devices, to get production-ready software packages...), as well as their operation (how to provide consistent data storage mechanisms, how to deal with device management, ...), it is important to be able to model the following concepts:
  
* The M2M application meta-model MUST allow the description of the different parts an M2M application is made of.
+
== Configuration (?) capabilities  ==
** It MUST allow the description of the data that can be exchanged between a device and a server.
+
** It MUST allow to declare the components that an application provides.
+
** It MUST allow to declare the components that an application requires.
+
** It SHOULD allow to indicate the binary files the application is made of.
+
* The M2M application meta-model
+
  
== Device Management ==
+
The description of the variables and events an element of the system manipulates, as well as the actions (services) that can be invoked on it.
  
* The M2M application meta-model MUST allow the description of the Device Management operations supported by a given system.
+
*Rationale:
 +
**At development time, configuration capabilities can be used to generate parts or the totality of embedded applications, simulate them, ...
 +
**At runtime, configuration capabilities can be used to configure components of the M2M chain (e.g. server side UI), to maintain backward compatibility between different versions of an application, ...
  
== Data ==
+
== Communication capabilities  ==
+
* The M2M application meta-model SHOULD allow to structure data elements hierarchically.
+
* The M2M application meta-model MUST allow to associate a type to data elements.
+
* The M2M application meta-model MUST support the following primitive types: string, integer, double, date, boolean, byte array.
+
* The M2M application meta-model SHOULD allow to define constraints for the data, such as: range, max length, ... 
+
* The M2M application meta-model SHOULD allow to indicate the protocol to use when exchanging a given data element
+
  
== Binary packages ==
+
The description of the different communication channels a given element of the system exposes to others, or depends on for its communication needs.
  
 +
*Rationale:
 +
**At development time, communication capabilities can be used to facillitate simulation of communication scenarios, estimate bandwidth (together w/ configuration capabilities), ...
 +
**At runtime, communication capabilities can be used to help configuring the communication stack of the gateway, choose the best suited channel for a given use case, ...
  
 +
<br>
  
= Non-functional requirements =
+
= Terminology  =
  
* It SHOULD be possible to split an M2M model instance into several pieces to ease maintenance, re-use...
+
*ACL: Access Control List. List of permissions attached to an object, specifying which entity of a system is granted access to it.
 +
*Software package: A binary file containing software and metadata that can be sent to an M2M device to update one of its software components
 +
 
 +
= Functional requirements  =
 +
 
 +
*The M2M application meta-model MUST allow the description of the different parts an M2M application is made of.
 +
**It MUST allow the description of the data that can be exchanged between a device and a server.
 +
**It MUST allow the description of the device management capabilities provided by an M2M application.
 +
**It MUST allow the description of the different components an M2M application is made of.
 +
 
 +
== Data Management  ==
 +
 
 +
*The M2M application meta-model SHOULD allow hierarchical structuring of data elements.
 +
*The M2M application meta-model MUST allow a type to be associated with data elements.
 +
*The M2M application meta-model MUST support the following primitive types: string, integer, double, date, boolean, byte array.
 +
*The M2M application meta-model SHOULD allow definition of constraints for the data, such as: range, max length, ...
 +
*The M2M application meta-model SHOULD allow indication of the protocol to use when exchanging a given data element.
 +
*The M2M application meta-model SHOULD allow association of configuration parameters to protocols
 +
*The M2M application meta-model SHOULD allow association of an history policy (keep all, keep last, keep on change...) to a data element.
 +
*The M2M application meta-model SHOULD allow association of ACLs to data elements.
 +
*The M2M application meta-model SHOULD allow specification of commands that can be sent by a server to a device.
 +
*The M2M application meta-model SHOULD allow specification of the set of events that can be sent by a device to a server.
 +
 
 +
== Device Management  ==
 +
 
 +
*The M2M application meta-model MUST allow the description of the Device Management operations supported by a given system.
 +
*The M2M application meta-model SHOULD allow to indicate the binary files the application is made of.
 +
 
 +
== Application Lifecyle Management  ==
 +
 
 +
*The M2M application meta-model SHOULD allow to specify which application container is managing an application
 +
*The M2M application meta-model SHOULD allow to specify dependencies towards capabilities of the underlying device the application is to be deployed on.
 +
*The M2M application meta-model SHOULD allow to validate a software package
 +
 
 +
<br>
 +
 
 +
= Non-functional requirements  =
 +
 
 +
*It MUST be possible to edit an M2M model instance using a standard text editor.
 +
*It SHOULD be possible to provide graphical visualization of an M2M model instance.
 +
*It SHOULD be possible to split an M2M model instance into several pieces to ease maintenance and reuse.
 +
 
 +
<br>
 +
 
 +
= Work in Progress  =
 +
 
 +
We are in the process of implementing the M2M meta-model using EMF, and the source code is available in the Git repository of the Koneki project: http://git.eclipse.org/c/koneki/org.eclipse.koneki.models.git/
 +
 
 +
== 'Things' meta-model  ==
 +
 
 +
This meta-model allows one to describe what Things a system is made of, what are the data held/manipulated by these Things, and what kind of actions can be performed on these things.
 +
 
 +
This meta-model allows one to define reusable elements such as Things, or extended primitive types, that are part of what we call an Universe. A 'Location' universe can for example contain the definitions of the different data structures that can be used to store a Location&nbsp;; likewise, an 'AcmeSensors' universe could be dedicated to the definition of the capabilities of sensors, or classes of sensor, sold by the Acme company.
 +
 
 +
=== Main model  ===
 +
 
 +
[[Image:Things diagram.png]]
 +
 
 +
=== Type system  ===
 +
 
 +
[[Image:Things types diagram.png]]

Latest revision as of 10:18, 4 February 2014

Warning2.png
Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.


General purpose of an M2M application meta-model

The M2M Industry Working Group aims at identifying the concepts that not only are the core of M2M/IoT systems, but are also often hindering the growth of M2M market. In order to ease the development of such solutions (by providing tools to scaffold embedded applications, to simulate devices, to get production-ready software packages...), as well as their operation (how to provide consistent data storage mechanisms, how to deal with device management, ...), it is important to be able to model the following concepts:

Configuration (?) capabilities

The description of the variables and events an element of the system manipulates, as well as the actions (services) that can be invoked on it.

  • Rationale:
    • At development time, configuration capabilities can be used to generate parts or the totality of embedded applications, simulate them, ...
    • At runtime, configuration capabilities can be used to configure components of the M2M chain (e.g. server side UI), to maintain backward compatibility between different versions of an application, ...

Communication capabilities

The description of the different communication channels a given element of the system exposes to others, or depends on for its communication needs.

  • Rationale:
    • At development time, communication capabilities can be used to facillitate simulation of communication scenarios, estimate bandwidth (together w/ configuration capabilities), ...
    • At runtime, communication capabilities can be used to help configuring the communication stack of the gateway, choose the best suited channel for a given use case, ...


Terminology

  • ACL: Access Control List. List of permissions attached to an object, specifying which entity of a system is granted access to it.
  • Software package: A binary file containing software and metadata that can be sent to an M2M device to update one of its software components

Functional requirements

  • The M2M application meta-model MUST allow the description of the different parts an M2M application is made of.
    • It MUST allow the description of the data that can be exchanged between a device and a server.
    • It MUST allow the description of the device management capabilities provided by an M2M application.
    • It MUST allow the description of the different components an M2M application is made of.

Data Management

  • The M2M application meta-model SHOULD allow hierarchical structuring of data elements.
  • The M2M application meta-model MUST allow a type to be associated with data elements.
  • The M2M application meta-model MUST support the following primitive types: string, integer, double, date, boolean, byte array.
  • The M2M application meta-model SHOULD allow definition of constraints for the data, such as: range, max length, ...
  • The M2M application meta-model SHOULD allow indication of the protocol to use when exchanging a given data element.
  • The M2M application meta-model SHOULD allow association of configuration parameters to protocols
  • The M2M application meta-model SHOULD allow association of an history policy (keep all, keep last, keep on change...) to a data element.
  • The M2M application meta-model SHOULD allow association of ACLs to data elements.
  • The M2M application meta-model SHOULD allow specification of commands that can be sent by a server to a device.
  • The M2M application meta-model SHOULD allow specification of the set of events that can be sent by a device to a server.

Device Management

  • The M2M application meta-model MUST allow the description of the Device Management operations supported by a given system.
  • The M2M application meta-model SHOULD allow to indicate the binary files the application is made of.

Application Lifecyle Management

  • The M2M application meta-model SHOULD allow to specify which application container is managing an application
  • The M2M application meta-model SHOULD allow to specify dependencies towards capabilities of the underlying device the application is to be deployed on.
  • The M2M application meta-model SHOULD allow to validate a software package


Non-functional requirements

  • It MUST be possible to edit an M2M model instance using a standard text editor.
  • It SHOULD be possible to provide graphical visualization of an M2M model instance.
  • It SHOULD be possible to split an M2M model instance into several pieces to ease maintenance and reuse.


Work in Progress

We are in the process of implementing the M2M meta-model using EMF, and the source code is available in the Git repository of the Koneki project: http://git.eclipse.org/c/koneki/org.eclipse.koneki.models.git/

'Things' meta-model

This meta-model allows one to describe what Things a system is made of, what are the data held/manipulated by these Things, and what kind of actions can be performed on these things.

This meta-model allows one to define reusable elements such as Things, or extended primitive types, that are part of what we call an Universe. A 'Location' universe can for example contain the definitions of the different data structures that can be used to store a Location ; likewise, an 'AcmeSensors' universe could be dedicated to the definition of the capabilities of sensors, or classes of sensor, sold by the Acme company.

Main model

Things diagram.png

Type system

Things types diagram.png

Back to the top