Difference between revisions of "Concepts"
(→Site) |
|||
(31 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | + | <translate> | |
− | This page | + | <!--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 | + | 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 |
− | + | <!--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 ==== <!--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). | ||
− | === | + | <!--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. | ||
− | + | <!--T:15--> | |
− | + | 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]]. | |
− | |||
− | |||
− | === 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 | + | 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. | ||
− | + | <!--T:29--> | |
− | + | 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 | ||
+ | </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.
Contents
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.
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.
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