Difference between revisions of "Concepts"

From Senfi Docs
Jump to: navigation, search
 
(31 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Concepts ==
+
<translate>
This page is an overview of Senfi.
+
<!--T:1-->
 +
This page provides an overview of Senfi concepts.
  
=== Measurement, Metric, Tag ===
+
=== Measurement, Metric, Tag === <!--T:2-->
 
==== Measurement ====
 
==== Measurement ====
Senfi deals with data in a [https://en.wikipedia.org/wiki/Time_series time series]. Each sample or record in this time series consists of:
+
Senfi deals with data in a [https://en.wikipedia.org/wiki/Time_series time series]. Each record in this time series consists of:
* a timestamp indicating when the data was sampled
+
* a timestamp indicating when the data was sampled (in milliseconds)
* a set of tags
+
* a fixed set of tags
* a set of metrics
+
* a fixed set of metrics
  
A measurement is composed of multiple samples.  
+
<!--T:3-->
==== Metric ====
+
All these records are kept in a dataset called a ''measurement''.
 +
 
 +
==== Metric ==== <!--T:4-->
 
A metric is a discrete reading or unit of data. It can be produced/measured by sensors, equipment, or complex systems. An example of a metric is temperature (eg. 37). A metric may or may not have units associated (eg. degrees Celsius).
 
A metric is a discrete reading or unit of data. It can be produced/measured by sensors, equipment, or complex systems. An example of a metric is temperature (eg. 37). A metric may or may not have units associated (eg. degrees Celsius).
==== Tag ====
 
A tag is an attribute of the sample. It is usually used as a way to identify where is the metrics are taken from (eg. device ID). It is also useful for filtering (eg. select all samples from this region).
 
  
 +
==== Tag ==== <!--T:5-->
 +
A tag is an attribute of the sample. It is usually used as a way to identify where is the metrics are taken from (eg. device ID). It is also useful for labelling the data being sent, in order to perform operations on the data later, eg. filtering.
 +
 +
==== Example ==== <!--T:6-->
 +
Say you have a smart weighing scale at home. One possible way to represent the time series data for the device is as follows:
 +
; Measurement: Smart Weighing Scale
 +
; Measurement code: <tt><tvar|measurement_code>iot_weighingscale_v1</></tt>
 +
; Data:</translate>
 +
{| class="wikitable"
 +
! tm_source
 +
! class="metric" | weight_kg
 +
|-
 +
| xxxxxxxxxxxxx || 70.1
 +
|-
 +
| xxxxxxxxxxxxx || 70.4
 +
|-
 +
| xxxxxxxxxxxxx || 69.4
 +
|}
 +
<translate>
 +
<!--T:7-->
 +
<tt><tvar|tm_source>tm_source</></tt> represents when the reading was taken. In this case, <tt><tvar|weight_kg>weight_kg</></tt> is the '''metric''', and is sent everytime a weight is taken.
 +
 +
<!--T:8-->
 +
This is well and good, but what if there is another person who's using the weighing scale? One way to distinguish them apart is by adding an additional field, or '''tag''', called <tt><tvar|person>person</></tt>:</translate>
 +
{| class="wikitable"
 +
! tm_source
 +
! class="tag" | person
 +
! class="metric" | weight_kg
 +
|-
 +
| xxxxxxxxxxxxx || Sam || 70.1
 +
|-
 +
| xxxxxxxxxxxxx || Susan || 55.2
 +
|-
 +
| xxxxxxxxxxxxx || Sam || 70.4
 +
|}
 +
<translate>
 +
<!--T:9-->
 +
Much better. But what if there are multiple weighing scales in the house? We can tell them apart by adding another tag:</translate>
 +
{| class="wikitable"
 +
! tm_source
 +
! class="tag" | room
 +
! class="tag" | person
 +
! class="metric" | weight_kg
 +
|-
 +
| xxxxxxxxxxxxx || bathroom || Sam || 70.1
 +
|-
 +
| xxxxxxxxxxxxx || kitchen || Susan || 55.2
 +
|-
 +
| xxxxxxxxxxxxx || kitchen || Sam || 70.4
 +
|}
 +
<translate>
 +
<!--T:10-->
 +
So we end up with a measurement that has 2 tags (room, person) and 1 metric (weight_kg).
  
=== Sensor ===
+
<!--T:11-->
 +
A more complete example can be as follows:</translate>
 +
{| class="wikitable"
 +
! tm_source
 +
! class="tag" | site_id
 +
! class="tag" | room
 +
! class="tag" | person
 +
! class="metric" | weight_kg
 +
! class="metric" | bodyfat
 +
! class="metric" | battery_level
 +
|-
 +
| xxxxxxxxxxxxx || 1547 || bathroom || Sam || 70.1 || 19.1 || 99
 +
|-
 +
| xxxxxxxxxxxxx || 1547 || kitchen || Susan || 55.2 || 15.3 || 54
 +
|-
 +
| xxxxxxxxxxxxx || 1547 || kitchen || Sam || 70.4 || 19.2 || 49
 +
|}
 +
<translate>
 +
<!--T:12-->
 +
This example is admittedly contrived, but it serves as an example of how data can be modelled in Senfi.
 +
</translate>
 +
<div class="important"><translate><!--T:13--> Note: <tt><tvar|site_id>site_id</></tt> is a required tag and will be explained below, under [[Concepts#Site|Site]]</translate></div>
 +
<translate>
 +
=== Asset === <!--T:14-->
 
Unlike applications like Prometheus or InfluxDB which deals purely with temporal data in a time series, Senfi associates such data with physical objects in the real world.  
 
Unlike applications like Prometheus or InfluxDB which deals purely with temporal data in a time series, Senfi associates such data with physical objects in the real world.  
  
A sensor in Senfi represents a physical object/system of interest. A sensor may produce one or more measurements, or it may not produce any measurements. There are 3 types of sensors in Senfi:
+
<!--T:15-->
; Managed sensors: Sensors that produces at least one measurement
+
An asset in Senfi represents a physical object/system of interest. An asset may produce one or more measurements, or it may not produce any measurements. Read more about assets [[Asset|here]].
; Specialized sensors: Sensors with special behaviour, eg. lift controller
 
; Unmanaged sensors: Sensors that does not produce measurement
 
  
=== Site ===
+
=== Site === <!--T:16-->
 
A site represents a place whereby sensors are physically located. A site usually comprise of '''one or more''' buildings.
 
A site represents a place whereby sensors are physically located. A site usually comprise of '''one or more''' buildings.
A site in Senfi has a geographical location and usually a 3D representation. Users may choose to use the CMS to trace out the building outline and generate a quick 3D building, or they can also upload a 3D model that represents details of the building.
+
A site in Senfi has a geographical location and usually a 3D representation. Users may choose to use the CMS to trace out the building outline and generate a quick 3D building, or they can also upload a 3D building modelled using modelling software such as Autodesk 3DS Max, SketchUp etc.
 +
</translate>
 +
[[File:Sample generated building.png|thumb|600px|center|<translate><!--T:17--> Sample building generated from building outline</translate>|link=]]
 +
[[File:Sample bespoke building.png|thumb|600px|center|<translate><!--T:18--> Sample building modelled using 3D software</translate>|link=]]
 +
<translate>
 +
<!--T:19-->
 +
<tt><tvar|site_id>site_id</></tt> is a unique integer associated with a particular site. It is used as a tag when sending measurements to Senfi, so that Senfi can tell which site the incoming measurement is meant for.
 +
 
 +
=== Rule, Alert === <!--T:20-->
 +
In an operating environment such as a smart building, it is important that organizations are able to keep track and be aware of what is going on in and around their assets. The way to do that is through monitoring and alerting.
 +
 
 +
<!--T:21-->
 +
Sensors produce measurements which contain data in the form of metrics and tags. Senfi provides multiple ways for users to monitor metric and tag values for conditions which require attention - such as abnormally high values, or when a combination of values indicates something is down - and to take action when it happens.
 +
 
 +
==== Rule ==== <!--T:22-->
 +
User can make use of Senfi's flexible rule engine to be alerted of abnormality in the system they are monitoring.
 +
 
 +
<!--T:23-->
 +
A '''rule''' in Senfi comprises of:
 +
* Inputs
 +
* Conditions
 +
* Output
 +
* Actions
 +
* Rule execution options
 +
 
 +
==== Example ==== <!--T:24-->
 +
Using our Smart Weighing Scale measurement from earlier, we can form one simple rule as follows:
 +
* Input: <tt><tvar|battery_level>iot_weighingscale_v1.battery_level</></tt>
 +
* Condition: < 20
 +
* Action: ''Email reminder to replace battery''
 +
* Rule execution option: Immediately (means evaluate this rule whenever there is any incoming measurement)
 +
 
 +
=== Computed measurement === <!--T:25-->
 +
Frequently, incoming metrics represent raw values that are read from the sensing device (eg. door open status, door closed status). To be able to derive better insights and to formulate more complex rules, it is useful to be able to calculate new metrics that are ''derived'' from the raw metrics. We refer to these metrics as '''derived metrics'''. The set of derived metrics and associated tags form the '''computed measurement'''.
 +
 
 +
<!--T:26-->
 +
Similar to measurement, a computed measurement comprises of:
 +
* timestamp
 +
* tags
 +
* metrics (derived)
 +
 
 +
<!--T:27-->
 +
Following from the above example, a computed measurement could compute the duration that a door remains opened by taking the timestamp between a door open and door closed metric.
 +
 
 +
=== Organization, User, Access Group === <!--T:28-->
 +
An organization represents the entity (eg. company, individual) that is responsible for managing the account that uses Senfi. An organization comprises at least one user with Administrator role. Users with Administrator role are able to manage other users, including user account creation/deletion, user roles etc.
  
=== Rule, Alert ===
+
<!--T:29-->
=== Computed measurement ===
+
Think of access group as a subset of the assets under the organization. Users can be placed into access groups to have access to those assets. Currently assets that can be assigned to an access group are:
=== Organization, User, Access Group ===
+
* user
 +
* site
 +
* rule
 +
</translate>
 +
<span class="right"><translate><!--T:30--> [[Getting_started|Next: Getting Started]]</translate></span>

Latest revision as of 12:09, 9 December 2020

This page provides an overview of Senfi concepts.

Measurement, Metric, Tag

Measurement

Senfi deals with data in a time series. Each record in this time series consists of:

  • a timestamp indicating when the data was sampled (in milliseconds)
  • a fixed set of tags
  • a fixed set of metrics

All these records are kept in a dataset called a measurement.

Metric

A metric is a discrete reading or unit of data. It can be produced/measured by sensors, equipment, or complex systems. An example of a metric is temperature (eg. 37). A metric may or may not have units associated (eg. degrees Celsius).

Tag

A tag is an attribute of the sample. It is usually used as a way to identify where is the metrics are taken from (eg. device ID). It is also useful for labelling the data being sent, in order to perform operations on the data later, eg. filtering.

Example

Say you have a smart weighing scale at home. One possible way to represent the time series data for the device is as follows:

Measurement
Smart Weighing Scale
Measurement code
iot_weighingscale_v1
Data
tm_source weight_kg
xxxxxxxxxxxxx 70.1
xxxxxxxxxxxxx 70.4
xxxxxxxxxxxxx 69.4

tm_source represents when the reading was taken. In this case, weight_kg is the metric, and is sent everytime a weight is taken.

This is well and good, but what if there is another person who's using the weighing scale? One way to distinguish them apart is by adding an additional field, or tag, called person:

tm_source person weight_kg
xxxxxxxxxxxxx Sam 70.1
xxxxxxxxxxxxx Susan 55.2
xxxxxxxxxxxxx Sam 70.4

Much better. But what if there are multiple weighing scales in the house? We can tell them apart by adding another tag:

tm_source room person weight_kg
xxxxxxxxxxxxx bathroom Sam 70.1
xxxxxxxxxxxxx kitchen Susan 55.2
xxxxxxxxxxxxx kitchen Sam 70.4

So we end up with a measurement that has 2 tags (room, person) and 1 metric (weight_kg).

A more complete example can be as follows:

tm_source site_id room person weight_kg bodyfat battery_level
xxxxxxxxxxxxx 1547 bathroom Sam 70.1 19.1 99
xxxxxxxxxxxxx 1547 kitchen Susan 55.2 15.3 54
xxxxxxxxxxxxx 1547 kitchen Sam 70.4 19.2 49

This example is admittedly contrived, but it serves as an example of how data can be modelled in Senfi.

Note: site_id is a required tag and will be explained below, under Site

Asset

Unlike applications like Prometheus or InfluxDB which deals purely with temporal data in a time series, Senfi associates such data with physical objects in the real world.

An asset in Senfi represents a physical object/system of interest. An asset may produce one or more measurements, or it may not produce any measurements. Read more about assets here.

Site

A site represents a place whereby sensors are physically located. A site usually comprise of one or more buildings. A site in Senfi has a geographical location and usually a 3D representation. Users may choose to use the CMS to trace out the building outline and generate a quick 3D building, or they can also upload a 3D building modelled using modelling software such as Autodesk 3DS Max, SketchUp etc.

Sample building generated from building outline
Sample building modelled using 3D software

site_id is a unique integer associated with a particular site. It is used as a tag when sending measurements to Senfi, so that Senfi can tell which site the incoming measurement is meant for.

Rule, Alert

In an operating environment such as a smart building, it is important that organizations are able to keep track and be aware of what is going on in and around their assets. The way to do that is through monitoring and alerting.

Sensors produce measurements which contain data in the form of metrics and tags. Senfi provides multiple ways for users to monitor metric and tag values for conditions which require attention - such as abnormally high values, or when a combination of values indicates something is down - and to take action when it happens.

Rule

User can make use of Senfi's flexible rule engine to be alerted of abnormality in the system they are monitoring.

A rule in Senfi comprises of:

  • Inputs
  • Conditions
  • Output
  • Actions
  • Rule execution options

Example

Using our Smart Weighing Scale measurement from earlier, we can form one simple rule as follows:

  • Input: iot_weighingscale_v1.battery_level
  • Condition: < 20
  • Action: Email reminder to replace battery
  • Rule execution option: Immediately (means evaluate this rule whenever there is any incoming measurement)

Computed measurement

Frequently, incoming metrics represent raw values that are read from the sensing device (eg. door open status, door closed status). To be able to derive better insights and to formulate more complex rules, it is useful to be able to calculate new metrics that are derived from the raw metrics. We refer to these metrics as derived metrics. The set of derived metrics and associated tags form the computed measurement.

Similar to measurement, a computed measurement comprises of:

  • timestamp
  • tags
  • metrics (derived)

Following from the above example, a computed measurement could compute the duration that a door remains opened by taking the timestamp between a door open and door closed metric.

Organization, User, Access Group

An organization represents the entity (eg. company, individual) that is responsible for managing the account that uses Senfi. An organization comprises at least one user with Administrator role. Users with Administrator role are able to manage other users, including user account creation/deletion, user roles etc.

Think of access group as a subset of the assets under the organization. Users can be placed into access groups to have access to those assets. Currently assets that can be assigned to an access group are:

  • user
  • site
  • rule

Next: Getting Started