FlexContainer, Container and SDT in oneM2M

When should we use < flexContainer > instead of < container >? I saw a few use case examples of < flexContainer>, they used < flexContainer > for SDT Device. Is the < flexContainer> used for SDT Devices only?

Imagine, we create a < container> and it is designed to hold the values of a temperature sensor. The actual values of the device are stored in < contentInstance >'s and the temperature type (Celsius or Fahrenheit) is defined by the semantic descriptor field of the < container> resource. However, we could also define the value and its type in the [customAttribute] field of a < flexContainer >. So, in this situation, why should I define the data type in the semantic descriptor field of < container >, or why should I use < container > instead of < flexContainer >?

SDTs are defined for some devices in the TS-0023 document. If a manufacturer of a device does not have SDT defined and if we want to use that device how can we create an SDT/XML file for it?

The <flexContainer> is different from the normal <container> resource in many ways:

• A <container> resource does not store actual values in the resource itself. Child-resources of <container>, ie. <contentInstance> or further <container> resources, do. In contrast, a <flexContainer> specialisation holds the actual values itself.
• A <flexContainer> itself cannot directly be instantiated, it only is the logical basis for further specialisations (very much like a base class in OOP). It defines a number of attributes that support these specialisations, for example the containerDefinition attribute contains an identifier that defines the actual type of a particular <flexContainer> resource. A <flexContainer> specialisation then specifies a well-defined structure that may contain a rather complex structure of data points. The mentioned Devices and ModuleClasses from TS-0023 are such specialisations, e.g. the temperature. These specialisations have a well-defined structure with semantics, constraints etc.
• A big advantage of a <flexContainer> is that it can be updated, while <contentInstance>'s in a <container> can only be added or deleted. This also means that, if an application only needs the current status of a device and is not interested in older data values, a single <flexContainer> specialisation is (more or less) everything that application needs.
• All the data points contained in a <flexContainer> specialisation are read and written at the same time. In some cases this reduces a lot of communication overhead and reduces the chance of race conditions when reading or writing many data points.

To the SDT: The Smart Device Template is a specification method to define "Lego" blocks of functionalities, so-called "ModuleClasses". These ModuleClasses can then be taken in order to construct prototypical "Devices". The mentioned oneM2M specification "TS-0023 : Home Appliances Information Model and Mapping" specifies a number of these ModuleClasses and Devices as well as the mapping to the <flexContainer> specialisations. That means that for the definition of a "temperature" functionality/ModuleClass there is a oneM2M <hd:temperature> resource available.

When you want to create a new Device definition using the SDT then I would suggest that you first look at the list of already defined ModuleClasses and Devices in TS-0023. If the functionality you need is not available then you can define your own ModuleClass and Device by writing your own SDT file.

The SDT definition is available at https://git.onem2m.org/MAS/SDT.

The latest version of the SDT for the ModuleClasses and Devices defined in TS-0023 is available at https://git.onem2m.org/MAS/Home-Appliances.

A tool to generate the necessary XSD from your SDT definition can be found at https://github.com/Homegateway/SDTTool.

Two more notes:

• Whether a CSE allows for self-defined <flexContainer> specialisations depends on the CSE implementation and policies.
• As of this writing (April 2019) oneM2M works on a new version of the SDT that supports, for example, product definitions, better inheritance, and further semantic support. oneM2M also works on a new version of the TS-0023 specification to support cross-domain IoT scenarios and devices, and not only the home domain.