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.
Difference between revisions of "IoT/M2MIWG/Machine-to-machine model"
< IoT
(New page: {{:DocumentationGuidelines/DraftHeader}}) |
m (Webmaster.eclipse.org moved page Iot/M2MIWG/Machine-to-machine model to IoT/M2MIWG/Machine-to-machine model) |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | {{warning|This page gather initial food for thoughts about an M2M model. A more accurate version is accessible [[Machine-to-Machine/M2MIWG/M2M_meta-model|here]]}} | ||
+ | |||
{{:DocumentationGuidelines/DraftHeader}} | {{:DocumentationGuidelines/DraftHeader}} | ||
+ | |||
+ | = Requirements = | ||
+ | |||
+ | == Tree structure == | ||
+ | |||
+ | * REST-like resource model | ||
+ | * ease the management of access rights | ||
+ | * improved extensibility | ||
+ | |||
+ | == Core model + extensions == | ||
+ | * CORE | ||
+ | ** Application State | ||
+ | *** Data | ||
+ | *** Events | ||
+ | *** Commands | ||
+ | *** Settings? | ||
+ | ** Communication capabilities | ||
+ | * Extensions | ||
+ | ** Validation | ||
+ | *** enum | ||
+ | *** min/max | ||
+ | *** length | ||
+ | *** see JSR-303??? / "Built-in constraint definitions" in particular | ||
+ | *** see XSD Restrictions? | ||
+ | ** Units | ||
+ | ** Access rights | ||
+ | ** Archiving policy? | ||
+ | ** Logical grouping/tagging | ||
+ | *** useless at development time? | ||
+ | ** i18n | ||
+ | ** Monitoring | ||
+ | *** define a prefered way to update resource tree | ||
+ | ** Rules | ||
+ | *** Use it for monitoring? | ||
+ | *** Use it to react to commands? | ||
+ | *** Drools? | ||
+ | ** Notification | ||
+ | ** "Local" communication protocol? | ||
+ | *** use openHAB binding mechanism??? | ||
+ | ** Web Service/REST mapping??? | ||
+ | |||
+ | = Open questions = | ||
+ | |||
+ | * Versioning? | ||
+ | * Is there really a difference between settings and data? | ||
+ | * Is a path a valid way to identify data/events/commands...? (vs UUID or anything else) | ||
+ | |||
+ | = Examples = | ||
+ | |||
+ | == Application model == | ||
+ | |||
+ | <source lang="lua"> | ||
+ | -- author: Benjamin Cabé | ||
+ | -- revision: 1.0 | ||
+ | Application "HomeAutomation" | ||
+ | |||
+ | |||
+ | CommunicationCapabilities { | ||
+ | ????? | ||
+ | } | ||
+ | |||
+ | |||
+ | Data { | ||
+ | Rooms | ||
+ | Room1 | ||
+ | TempSensor1 | ||
+ | value (int) | ||
+ | batteryLevel (int) | ||
+ | macAddress (string) | ||
+ | Curtain1 | ||
+ | position (int) | ||
+ | macAddress (string) | ||
+ | Room2 | ||
+ | TempSensor1 (WavenisTemperatureSensor) | ||
+ | } | ||
+ | |||
+ | Events { | ||
+ | TemperatureTooHot | ||
+ | Intrusion, ACK | ||
+ | } | ||
+ | |||
+ | Settings { | ||
+ | ???? | ||
+ | } | ||
+ | |||
+ | Commands { | ||
+ | ToggleCurtains(OPEN=default|CLOSE) | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | == typedef model == | ||
+ | |||
+ | <source lang="lua"> | ||
+ | -- author: Benjamin Cabé | ||
+ | -- revision 1.0 | ||
+ | include 'tcpip' | ||
+ | |||
+ | Type "WavenisSensor" { | ||
+ | serialNumber: string, | ||
+ | macAddress: tcpip.MacAddress, | ||
+ | batteryLevel: float, | ||
+ | [...] | ||
+ | } | ||
+ | |||
+ | Type "WavenisTemperatureSensor" extends "WavenisSensor"{ | ||
+ | temperature: float | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | |||
+ | == rules model == | ||
+ | |||
+ | <source lang="lua"> | ||
+ | -- author: Benjamin Cabé | ||
+ | -- revision 1.0 | ||
+ | Rules for application "HomeAutomation" v1.0 | ||
+ | |||
+ | rule "trigger TemperatureTooHot" | ||
+ | when | ||
+ | (Rooms/Room1/TempSensor1 + Rooms/Room2/TempSensor1) / 2 > 25.0 | ||
+ | then | ||
+ | TemperatureTooHot() | ||
+ | end | ||
+ | </source> | ||
+ | |||
+ | |||
+ | |||
+ | == i18n model == | ||
+ | |||
+ | <source lang="lua"> | ||
+ | -- author: Benjamin Cabé | ||
+ | -- revision 1.0 | ||
+ | i18n for application "HomeAutomation" v1.0 | ||
+ | |||
+ | en: | ||
+ | Data/Rooms=House rooms | ||
+ | Data/Rooms/Room1=Living Room | ||
+ | Data/Rooms/Room1/TempSensor1=Temperature | ||
+ | [...] | ||
+ | |||
+ | fr_FR: | ||
+ | Data/Rooms=Pièces de la maison | ||
+ | Data/Rooms/Room1=Salon | ||
+ | Data/Rooms/Room1/TempSensor1=Température | ||
+ | [...] | ||
+ | </source> |
Latest revision as of 10:18, 4 February 2014
Contents
Requirements
Tree structure
- REST-like resource model
- ease the management of access rights
- improved extensibility
Core model + extensions
- CORE
- Application State
- Data
- Events
- Commands
- Settings?
- Communication capabilities
- Application State
- Extensions
- Validation
- enum
- min/max
- length
- see JSR-303??? / "Built-in constraint definitions" in particular
- see XSD Restrictions?
- Units
- Access rights
- Archiving policy?
- Logical grouping/tagging
- useless at development time?
- i18n
- Monitoring
- define a prefered way to update resource tree
- Rules
- Use it for monitoring?
- Use it to react to commands?
- Drools?
- Notification
- "Local" communication protocol?
- use openHAB binding mechanism???
- Web Service/REST mapping???
- Validation
Open questions
- Versioning?
- Is there really a difference between settings and data?
- Is a path a valid way to identify data/events/commands...? (vs UUID or anything else)
Examples
Application model
-- author: Benjamin Cabé -- revision: 1.0 Application "HomeAutomation" CommunicationCapabilities { ????? } Data { Rooms Room1 TempSensor1 value (int) batteryLevel (int) macAddress (string) Curtain1 position (int) macAddress (string) Room2 TempSensor1 (WavenisTemperatureSensor) } Events { TemperatureTooHot Intrusion, ACK } Settings { ???? } Commands { ToggleCurtains(OPEN=default|CLOSE) }
typedef model
-- author: Benjamin Cabé -- revision 1.0 include 'tcpip' Type "WavenisSensor" { serialNumber: string, macAddress: tcpip.MacAddress, batteryLevel: float, [...] } Type "WavenisTemperatureSensor" extends "WavenisSensor"{ temperature: float }
rules model
-- author: Benjamin Cabé -- revision 1.0 Rules for application "HomeAutomation" v1.0 rule "trigger TemperatureTooHot" when (Rooms/Room1/TempSensor1 + Rooms/Room2/TempSensor1) / 2 > 25.0 then TemperatureTooHot() end
i18n model
-- author: Benjamin Cabé -- revision 1.0 i18n for application "HomeAutomation" v1.0 en: Data/Rooms=House rooms Data/Rooms/Room1=Living Room Data/Rooms/Room1/TempSensor1=Temperature [...] fr_FR: Data/Rooms=Pièces de la maison Data/Rooms/Room1=Salon Data/Rooms/Room1/TempSensor1=Température [...]