Sensors

A sensor measures a physical or chemical condition and converts it into a readable signal. While this may sound similar to a Peripheral, the key difference is the nature of the signal being produced. A peripheral produces a digital binary signal (on or off); a sensor produces a continuous signal.

In essence, the peripheral will detect something, whereas the sensor will tell you to what degree something is sensed, such as how warm it is. As such, sensors bring value in physical security by providing additional insight for alarm operators and end-customers.

Functionality

YourSixOS features integration with native sensors and with Modbus RTU sensors. A native sensor runs directly on the device itself, such as temperature on the AXIS D6310. A Modbus sensor runs on a Modbus RTU server, externally wired to the gateway device, such as the AXIS A9210.

YourSixOS features the following functionality for sensors regardless of hardware deployment:

• Threshold alerting: one upper and one lower threshold can be defined.
• Events for logs and notifications, used for threshold alerting and health monitoring purposes. For more information on logging and alerting, see the event concept.
• Gauge and time-series visualization in user applications and Inspect:
  • Users can observe the latest reading using the gauge or inspect historical values using the time-series diagram, e.g. for trend-analysis and incident investigations.
  • Alarm operators can react to alarms and draw conclusions based on measured values, e.g. confirm there's a fire outbreak by checking the adjacent temperature sensor.
  • Resolution of stored time series can be configured.

In addition to the above hardware-agnostic functionality, YourSixOS also features basic health and tampering monitoring of individual Modbus RTU servers, allowing alarm operators to react on disconnected Modbus RTU servers.

Hardware support

YourSixOS supports native sensors and Modbus RTU gateways from Axis Communications, see the supported devices list.

YourSix and Axis support the Modbus implementation described in the Modbus section. As Modbus is a standardized protocol, albeit with its nuances, we aim to support what's described in this document rather than a committed set of Modbus servers. We do however provide a brief list of Modbus servers that we actively test with, listed in the verified Modbus list.

Modbus

Modbus sensors run on Modbus RTU servers that are connected to a Modbus gateway. The topology is depicted in the diagram below:

YourSixOS makes a distinction between server and sensor. As many manufacturers make Modbus servers that can sense multiple metrics, such as Temperature and Relative Humidity in the same server, YourSixOS follows the terminology of servers and sensors as described in the diagram above.

INFO

Some manufacturers use the word sensor in their marketing to describe their entire server products.

Value types

One server may have multiple sensors. In Modbus terms, the sensor is one or a set of Modbus registers that provide a value. The value types supported by YourSixOS are the following:

• Integer 16-bit
• Integer 32-bit
• Floating point 32-bit

For integer types, both signed and unsigned are supported. For 32-bit types, all four possible byte orders are supported.

All value types can be scaled and offset, allowing for linear function conversion, such as:

• Sensors reporting decimal values as integers (e.g. 224 meaning 22.4)
• Celsius to Fahrenheit
• 4-20mA or 1-5V conversion into physical metrics

Protocol

The AXIS A92-series supports Modbus RTU.

Modbus RTU runs on top of the RS485 serial bus protocol, in which the following settings are supported:

• Baud rate (9600, 19200, 38400, 57600, 115200)
• Parity (none, odd and even)
• Stop bits (1 or 2)

In addition to the serial bus settings, YourSixOS also supports defining a poll interval per connected Modbus RTU server. The poll interval controls how often the Modbus RTU server's sensors are being scraped by the gateway. A low interval means higher resolution (more data points per time unit) and more responsive threshold alerts.

WARNING

If a low poll interval is desired, baud rate may have to be increased and good quality sensors should be used to allow the entire poll cycle to be completed within one interval time.

Limitations

• The number of Modbus servers on the same bus is limited to 8 servers.
• The AXIS A9910 is not supported.

Storage

Sensor value readings are stored as time series in the YourSixOS cloud.

The resolution of the time series is defined by the configurable storage interval. The storage interval controls how often the sensor uploads value readings to the cloud. Storage interval is configured per sensor. A higher storage interval means a lower resolution of the time series.

Sensor time series are retained for 90 days.

INFO

Changing the storage interval does not change the responsiveness of threshold alerting. Threshold alerting happens as soon as the sensor is polled or updated.

Flow and logics

The diagram below depicts the flow of a sensor reading and how logics are applied to every reading:

Applied usage examples

Collecting sensor data, such as temperature or battery levels, can provide great insights in traditional security deployments in buildings. As an alarm operator is investigating an incident in real time, or for a local branch manager who is investigating an incident in retrospect, the extra insight from sensors can help prioritize alarms and actions, as well as aid appropriate conclusions e.g. in privacy sensitive areas.

Consider the following examples:

• A smoke detector peripheral going off as a sensor is registering increased temperature. The temperature diagram produced by the sensor gives the operator a clearer indication of fire.
• A temperature sensor, configured with a threshold, is alerting for low temperature. As the branch manager or central station operator inspects the alert, the window is identified as open. They can also see that power usage at the site is increasing in correlation with the decreasing temperature. An idle guard is dispatched to go close the window.
• A sound pressure sensor installed in a sensitive area is crossing its configured threshold. Roughly, at the same time, a panic button is pressed. The correlation indicates that the button was actually pressed in distress.

In addition to traditional security, there are a number of safety and health-related situations that can be helped with sensors:

• Notify local manager when there are unsustainable levels of CO2 in conference rooms and gyms.
• With VOC and NOx sensors in bathrooms, odors can be identified and cleaning can be done accordingly.
• Power meters and water meters in combination with access control can help analyze utilization behaviours.
• Soil moisture sensors to monitor and alert when expensive plants need watering.
• Light intensity sensors to identify broken lights that need replacement.

INFO

Using adjacency groups, evidence material from sensors, peripherals, barriers and cameras can be correlated and inspected altogether, providing holistic situational insight.

Since authorization can be performed on individual sensors, it is possible to install the A9210 in a central location of a building and let it serve multiple different tenants. Each tenant may then be authorized access only to their respective peripherals.

Similarly, for native sensors, such as the D6310, access can be restricted on a per-sensor basis. For example: letting unprivileged users only see a subset of the available sensors of the D6310.

Architectural summary

A sensor is a type of security thing that is hosted by a supported device. One device may serve multiple sensors.

Authorization is performed on individual sensors or a parent resource such as the device.