1、 ETSI TR 118 517 V2.0.0 (2016-09) oneM2M; Home Domain Abstract Information Model (oneM2M TR-0017 version 2.0.0) TECHNICAL REPORT ETSI ETSI TR 118 517 V2.0.0 (2016-09) 2oneM2M TR-0017 version 2.0.0Reference DTR/oneM2M-000017 Keywords IoT, M2M ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex
2、 - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search The present document may
3、 be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in pr
4、int, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of
5、this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be repr
6、oduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restricti
7、on extend to reproduction in all media. European Telecommunications Standards Institute 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its
8、Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TR 118 517 V2.0.0 (2016-09) 3oneM2M TR-0017 version 2.0.0Contents Intellectual Property Rights 5g3Foreword . 5g31 Scope 6g32 References 6g32.1 Normative refere
9、nces . 6g32.2 Informative references 6g33 Abbreviations . 7g34 Conventions 7g35 Home Domain Abstract Information Model 8g35.1 Anaysis of Abstract Information Models . 8g35.1.1 AllJoyn (AllSeen Alliance) . 8g35.1.2 HomeKit (Apple Inc.) . 8g35.1.3 SmartHome Device Template (HGI) 9g35.1.3.1 Introductio
10、n . 9g35.1.3.2 Definitions . 11g35.1.3.3 Overview. 11g35.1.3.4 Structure 11g35.1.3.5 “Domain“ element . 12g35.1.3.6 “Device“ and “SubDevice“ element . 13g35.1.3.7 “Module“ element(s) . 13g35.1.3.8 “ModuleClass“ element(s) . 13g35.1.3.9 “Property“ Elements 14g35.1.3.10 “ModuleClass“ - “DataPoint“ ele
11、ment 14g35.1.3.11 “ModuleClass“ - “Actions“ element 14g35.1.3.12 “Module Class“ - “Action“ - “Args“ 15g35.1.3.13 “ModuleClass“ - “Event“ element . 15g35.1.3.14 “Doc“ element . 15g35.1.3.15 “DataType“ element 15g35.1.3.16 “DataType“ - “unitOfMeasure“ . 16g35.1.3.17 “DataType“ - “TypeChoice“ Element .
12、 16g35.1.3.18 “DataType“ - “SimpleType“ Element . 17g35.1.3.19 “DataType“ - “Constraint“ Element 17g35.1.3.20 “DataType“ - “Array“ Element 17g35.1.3.21 “DataType“ - “StructType“ Element . 17g35.1.3.22 A very simple SDT example . 18g35.1.4 ECHONET/ECHONET Lite (ECHONET Consortium) . 20g35.1.5 OIC (Op
13、en Interconnect Consortium). 21g35.2 Design Principle of Abstract Information Model . 22g35.2.1 Introduction. 22g35.2.2 Design Principle: Approach 1 . 22g35.2.3 Design Principle: Approach 2 . 23g35.2.4 Design Principle: Approach 3 . 24g35.2.5 Design Principle: Approach 4 . 25g35.3 Define Abstract an
14、d Describe Specific Abstract Information Model . 26g35.3.1 Abstract Information Model: Approach 1 . 26g35.3.1.1 Introduction . 26g35.3.1.2 Washer 27g35.3.1.3 Refrigerator . 27g35.3.1.4 Smart Meter. 28g35.3.2 Abstract Information Model: Approach 2 . 28g35.3.2.0 Overview . 28g35.3.2.1 Washer 30g35.3.3
15、 Abstract Information Model: Approach 3 . 30g35.3.3.1 Introduction . 30g3ETSI ETSI TR 118 517 V2.0.0 (2016-09) 4oneM2M TR-0017 version 2.0.05.3.3.2 Device Information Model 30g35.3.3.3 Service Information Model . 31g35.3.4 Abstract Information Model: Approach 4 . 32g35.3.4.0 Introduction . 32g35.3.4
16、.1 ModuleClasses 32g35.3.4.2 Device Information Model 33g36 Representation in the oneM2M System . 33g36.1 Introduction 33g36.2 Approach 1: Representation Using Dedicated Resource Types . 34g36.2.1 New Resource Type appliance . 34g36.2.1.0 Introduction . 34g36.2.1.1 one-level 34g36.2.1.2 two-level 40
17、g36.3 Approach 2: Existing Resource Type container/contentInstance . 45g36.3.1 Introduction. 45g36.4 Comparison of potential solutions 48g37 Conclusions 48g3History 49g3ETSI ETSI TR 118 517 V2.0.0 (2016-09) 5oneM2M TR-0017 version 2.0.0Intellectual Property Rights IPRs essential or potentially essen
18、tial to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notifi
19、ed to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to
20、 the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Partnership Project oneM2M (oneM2M). ETSI ETSI TR 118 517 V2.0.
21、0 (2016-09) 6oneM2M TR-0017 version 2.0.01 Scope The present document allows application developers to describe the status of devices as resources on oneM2M-based platform in various ways. Thus different application developers can create different resource trees even when they build the same kinds o
22、f applications. Moreover when handling the same kinds of devices from different vendors on M2M platforms, application developers may create disunited resource trees without common information model. In order to solve such issues, the present document intends to provide the common and unified APIs on
23、 one M2M platform for the home domain by defining an abstract information model for the home domain devices such as TV, refrigerator, air conditioner, smart meter, and lighting equipment. The definition of the abstract information model will be based on data models that currently exist in the home d
24、omain. The home domain abstract information model does not intend to define the interworking function between the oneM2M system and protocols of the data models from which the abstract data model is defined. Also, the present document intends to define how the developed abstract information model fo
25、r a device could be represented in the CSEs of the oneM2M system. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specifi
26、c references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at https:/docbox.etsi.org/Reference/. NOTE: While any hyperlinks included in this clause were vali
27、d at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document. Not applicable. 2.2 Informative references References are either specific (identified by date of publication and/or edition numb
28、er or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETS
29、I cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 oneM2M Drafting Rules. NOTE: Available at http:/www.onem2m.org/images/files/oneM2M-Draf
30、ting-Rules.pdf. i.2 ETSI TS 118 111: “Definitions and Acronyms (oneM2M TS-0011)“. i.3 AllJoyn System Description version 14.06, September 26th, 2014. i.4 Home Appliances 2) modularity for functions and device types; 3) make it easy for developers to create unified APIs; 4) be independent of underlyi
31、ng home-area network technologies; 5) enable extendibility of the system in place without service interruption; 6) allow a pass-through mechanism to enable use of proprietary or technology-specific functions. The SDT approach is to define re-usable basic functions (or services) (labelled “ModuleClas
32、s“ in figure 5.1.3.1-1) which can represent the typical functions found in many home automation systems, such as “on/off“, “dim a lamp“, “receive events from binary sensor“, “read data from sensor“, etc. Each ModuleClass is composed of a (small) number of actions, datapoint read/write operations, or
33、 asynchronous events. For example, an “on/off“ ModuleClass would consist perhaps of just one Action, but a “ReadKeypad“ Action might have a number of possible events, each with some data value and (usually) a sequence-ID or timestamp start/stop to indicate when and how long each key was pressed. ETS
34、I ETSI TR 118 517 V2.0.0 (2016-09) 10oneM2M TR-0017 version 2.0.0CBAFigure 5.1.3.1-1: SmartHome Device Template (XSD) for a generic device (simplification of draft, under discussion with SDOs) The SDT represents the device models introduced in figure 5.1.3.1-1 by using an XSD schema to allow formal
35、checking of compliance for XML device descriptions of specific appliances. The modularity goal in the XSD schema is achieved with re-usable XSD fragments (“ModuleClass“ in figure 5.1.3.1-1). Complex devices or appliances can then be described by an appropriate set or collection of the agreed XSD fra
36、gments (ModuleClasses), as indicated in figure 5.1.3.1-1, which also shows an optional DeviceInfo XSD fragment to allow recording of static information such as device manufacturer name, device firmware version, etc. Note that the SDT concept of ModuleClasses is similar to the HomeKit concept of “ser
37、vices“. HGI has discussed with many SDOs to validate the concept. Consultation with various industry fora continues, to determine an appropriate set of commonly used ModuleClasses, which however allows extensions. SDT is designed to take into account the list of “services“ compiled by the SAREF proj
38、ect. The SDT supports the use of a set of templates for generic devices or appliances (e.g. for a dimmable lamp, a basic washing machine, etc., which would be specific instances of the “Device“ object shown in figure 5.1.3.1-2) which form the basis of APIs used by application developers. These templ
39、ates can also be referenced by manufacturers creating XML documents to describe their specific products. For example, the SDT enables specification of a generic washing machine template, with on/off, set-wash-temperature, pause and a few other commands, which could be referenced by a manufacturer as
40、 the schema for a XML description of a basic model washing machine. The SDT allows for vendor-specific additional commands (ModuleClasses) to suit specific product types. An example of how three different generic devices/appliances might be modelled using 4 different ModuleClasses is shown in figure
41、 5.1.3.1-2. Data values (DataPoints) which might need to be read/written during operation of the devices are shown as the lowest grouping in the figure (DataPoints/Characteristics). Figure 5.1.3.1-2: SmartHome Template for 3 examples of generic devices ETSI ETSI TR 118 517 V2.0.0 (2016-09) 11oneM2M
42、TR-0017 version 2.0.0Figure 5.1.3.4-1 showing the SDT structure in more detail is shown in clause 5.1.3.4. It is sufficiently flexible to allow representation of e.g. the SAREF ontology or the future OneM2M ontology. 5.1.3.2 Definitions This clause provides an overview about the SDT 3.0 definitions
43、and element hierarchy. Terms to be described in detail in this clause are: Table 5.1.3.2-1: Definitions of SDT Elements Term Definition Domain Unique name, or “wrapper“ which acts like a namespace, set by the organization creating the SDT, allowing reference to a package of definitions for the conta
44、ined ModuleClasses and device definitions. Can be referenced when extending ModuleClasses. It has two possible uses: to select the scope of a technology domain, or to set the scope of a use case domain (like Home, SmartGrid, etc.). Device Physical, addressable, identifiable appliance/sensor/actuator
45、. Sub-Device A device (usually one of several) which may be embedded in a Device and/or is addressed via another Device. ModuleClass Specification of a single service with one or more service methods, the involved abstracted data model and related events. The expectation is that each separate servic
46、e which may be used in many kinds of Devices (like PowerON/OFF, Open/Close, etc.) will be described by a ModuleClass which can be re-used in many Device definitions. Module Instantiation of a ModuleClass for a specific Device or SubDevice. 5.1.3.3 Overview Various details about recommended structure
47、 for SDTs are described in the next clauses. The key point to keep in mind is that HGI sought a compromise between, at the one extreme, complete flexibility (which could describe any device, of any complexity) and, at the other extreme, a rigid structure which could be 100 % validated and lead to va
48、lidated software APIs. A major decision, facilitating validation of code and signalling, was to describe services (functionality) of devices in terms of ModuleClasses made up of combinations of three kinds of elements: a) DataPoints which can be read/written; b) Actions which consist of more complex
49、 sequences of operations; c) Events which can be signalled (“published“) by devices asynchronously. This structure shown in figure 5.1.3.3-1 and is given in more detail in figure 5.1.3.4-1. Figure 5.1.3.3-1: Diagram describing device functionality in terms of Actions, DataPoints, Events 5.1.3.4 Structure The following UML diagram presents an overview of the structure (elements) of every SDT which is conformant with these guidelines. As implied in the above descriptions, there can be many different choices of the details of a SDT, each one optimized for a particular
