Resource model

This article aims to explain the resource model available in YourSixOS and how resources relate to each other, what their intended abstraction is and how they may be utilized.

Organization

The top most resource type is the Organization. An organization is essentially a customer account. One can also think of the organization as a global security system, acting as a collection of security components, such as sites, devices, identities, credentials, users etc.

The organization does not share any data with other organizations. Every child resource can only be accessed by child resources of that organization. For example; a user can only access devices within his/her organization. There is no way to move a child resource from one organization to another organization.

Directly under an organization, the following resource types reside:

• Sites
• Users
• PACS resources (identities, rules, schedules, groups etc.)
• Event resources (rules etc.)
• Third-party integrations (shared email addresses, webhooks)

Site

Sites are geographically defined collections of devices, things and alarm groups. They are intended to be abstracting one regional location, e.g. a building or similar.

Directly under a site, the following resources types reside:

• Devices
• Alarm groups

Device

A device is a connected network device. The device must be supported by YourSixOS to be connected. YourSixOS only supports Axis devices.

The device may be standalone; meaning that it comes with native built-in security features, such as a camera, a speaker, or a radar. It may also be modular, meaning that it acts as a hub for speakers, cameras, peripherals or barriers, hereafter referred to as things.

If a device is modular, the device is also a collection of things.

Thing

A thing is a physical security component connected physically to a device, when the device is acting as a hub. Examples of things are:

• Barriers
• Peripherals (I/O)
• Sensors

Things are used in the same way as a standalone device. They provide events and evidence data, and can be consumed in many different ways, including The Matrix.

Alarm group

An alarm group is a special type of collection resource that sits under the site but is not part of the onion model described above. The alarm group is optional.

An alarm group is a collection of devices and things, acting as an optional filter for events and other similar concepts. The alarm group has two entities related to it:

• Schedules
• A state declaring whether the alarm group should follow the tied schedule, or if the alarm group should be overridden to forcefully armed or forcefully disarmed.

The purpose of an alarm group is to be able to filter events from its member devices and things, based of the alarm group's active status (whether the alarm group is within the schedule or forcefully armed). This is to be used, for example, when replicating a traditional alarm zone, where a central station should only receive notifications when relevant. See the events concept for more information on events, notifications and central stations.

WARNING

If a device and its child things are members of separate alarm groups, the alarm group will inherently differ between events emitted by the thing versus events emitted by the parent device. This is important to consider when filtering for events, for example when setting up event notifications.

Peripheral state source

An alarm group can be configured to source its armed-state from an input peripheral. This is typically used when an alarm panel is deployed alongside with YourSixOS and the alarm panel is used as the source-of-truth for armed-state.

In order to do so, setup an input peripheral that is wired to an output of the alarm panel and configure the alarm group to follow the state of said input peripheral.

Adjacency group

An adjacency group is a special type of collection resource that sits under the site but is not part of the onion model described above. The adjacency group is optional.

An adjacency group is a collection of devices and things, that declares which devices and things that are installed physically nearby each other. It is used in our applications, such as in Matrix and in Inspect to render ad-hoc grid views of adjacent things and devices when investigating an event.

The end goal is to present and display relevant evidence material when investigating an event:

• In real time: e.g. a central station reacting to an alarm or user tapping a push notification.
• In retrospect: e.g. a user using the forensic log search to find a specific event, and traversing into Matrix to inspect the event in detail.

In addition to presenting and displaying relevant evidence material, adjacency groups are also used to render live controls for adjacent things that feature an action, e.g:

• Control adjacent output peripherals
• Control adjacent barriers
• Perform callouts on adjacent speakers

INFO

An adjacency group does not impact what a user has access to. An adjacency group only declares what's installed physically close to each other.