HOW TO: Create an IOT Device Model

It’s necessary to make a preliminary analysis to understand what you need in order to define what should (or should not) be included in the device model.

First, you need to know if the dataset is only static or if it has also some dynamic fields that can change in the future (and with what rate):

  • The static case is the easiest, such as the collection of POI data: the data does not change over time but remains the same once set
    • In this case you will only have to follow the Device/s Creation in Snap4City and IoTApp – Static Data sections of this manual
  • The dynamic case is more interesting as a non-regular dataset can have both static and dynamic info
    • In this case the whole manual will help you manage both aspects

Afterwards it’s important to have a general overview of the dataset so that you can write a schematic of the model. The idea is to compile two tables: one in which there is the general information of the devices, the other in which are reported the attributes (variables / values) that the devices must have. In this way it will be much easier to create the IoT model and furthermore the tables can be used in the future to get an immediate idea of what has been done.

General info table:

Name

 

Device Type

 

Kind

 

Producer

 

Frequency

 

 

  • Name: an indicative prefix of the Device Model so that the name of each device begins with that prefix (e.g. “[deviceID]” -> “FlorenceAirQuality_[deviceID]” where deviceID is a string that identifies the single device). This field will be useful during devices creation. By entering this prefix, it will be possible to identify the model to which it belongs simply by its name
  • Device Type: what is the working scope of the devices? Air Quality, Weather, ...
  • Kind: will the devices be sensors or actuators?
  • Producer: where does the data come from?
  • Frequency: how often will the sensor data be updated?

Values (attributes) table:

Value Description

Value Name

Value Type

Data Type

Value Unit

Notes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Observation time

dateObserved

timestamp

time

s

 

 

 

 

 

 

 

 

N.B.: each row corresponds to a dataset value. In the table above, dateObserved has been inserted as an example, in reality this value is mandatory in every model

  • Value Description: a brief description of the value. It must not be inserted in the model, but it is useful for you (e.g. for future uses)
  • Value Name: what name do you want to give to the value in the model? Consider using a camelCase style
  • Value Type: what is the working scope of the value? When you create the model, it will be possible to choose only from a predetermined list. For now, enter a free text and when you have created the IoT Model, replace the one you wrote with one of the choices proposed by the platform. If the value type you want isn't listed, contact the Snap4City team to get it added
  • Data Type: what type is the value, in computer programming? Float, integer, string, …?
  • Value Unit: what unit of measure does the value have? If it doesn't have one (e.g. a string), enter a dash - . When you create the model, it will be possible to choose only from a predetermined list. For now, enter a free text and when you have created the IoT Model, replace the one you wrote with one of the choices proposed by the platform. If the value unit you want isn't listed, contact the Snap4City team to get it added
  • Notes: Any notes that may be helpful in the future to justify certain choices or to remember something additional. They must not be inserted in the model

 

Path in Snap4City: “MENU > IOT Directory and Devices > IoT Devices Models > New Model

Type of user:  Tool admin

Guidelines to create the model:

  • General Info Tab:
    • Name: model name in upper camel case style (e.g. FlorenceAirQuality)
    • Description: short description of the model
    • Device Type: kind of device sensors in upper camel case style. The name must not relate to ontology. E.g. AirQuality, TerrainSensor, SoilHumidity, etc.
    • Kind: sensor or actuator
    • Producer: name of the sensor’s producer
    • Frequency: time (in seconds) to update the sensors data in the IoTApp
    • Healthiness Criteria: Refresh rate (default value)
    • Healthiness Value: same value as frequency (default value)
    • Key Generation: Automatically generated (default value)
    • Edge-Gateway Type: void (default value)
  • IoT Broker Tab:
    • ContextBroker: choose the broker according to the Organization
    • Protocol: ngsi (default value)
    • Format: json (default value)
  • Values Tab:
    This is the core of the model. Remember that the association with one of the ontology classes depends on the value type.
    • Value Name: name of the variable in camel case style (e.g. batteryLevel)
    • Data Type: type of data in computer programming
    • Value Type: kind of data, ontologically
    • Editable: false (default value)
    • Value Unit: unit of measurement of the variable
    • Healthiness Criteria: Refresh rate (default value)
    • Healthiness_Value: time (in seconds) to update the variable in the IoTApp
      WARNING:  Value Type = timestamp there can be only one for each model (and Device) and must be associated with the Value Name: dateObserved, mandatory in each model (see below). If other dates are present, they must be put as datetime.
      If data types, value types, value units are not enough, contact snap4city@disit.org
      dateObserved: it must contain the measurement date of each sensor connected to the device and must have the following characteristics in the model:
  • Value Name: dateObserved
  • Data Type: time
  • Value Type: timestamp
  • Value Unit: s

Example:

Florence Charging Stations (open data municipality of Florence) – Florence organization

General Info Tab:

IoT Broker Tab:

Values Tab: