Logical Containers

This page explains what physical and logical containers are, how datapoints are imported into SIWENOID, and how logical containers allow engineers to reorganise the imported datapoint structure for daily operation.

A physical container represents a security control panel that SIWENOID communicates with. Each physical container corresponds to one real panel on the site — for example a Siemens fire alarm control unit, a Bosch intrusion panel, a Hikvision video recorder, or any other supported system.

When a physical container is created, the engineer sets the basic connection parameters: the panel's IP address, protocol, and other vendor-specific settings. The physical container then becomes the root node for all datapoints imported from that panel.

The datapoints configured inside a control panel — detectors, zones, inputs, outputs, cameras — must be imported into SIWENOID before they can be monitored or controlled. SIWENOID supports two methods depending on the panel type:

File-based import (most common)
The engineer exports a configuration file from the vendor's own tool (for example a .sibx XML file from the Siemens configuration tool, or a CSV or TXT file from other vendors). This file contains the complete datapoint structure of the panel. In SIWENOID, go to File → Settings → Physical Structure, select the physical container, and click Import metafile to load the file.

SIWENOID reads the file and builds a tree structure of nodes under the physical container node — mirroring exactly the section, zone, and detector hierarchy that exists in the panel. Once the import is complete, SIWENOID is ready to operate: signals from the panel appear in the Signal Log and commands can be sent to the panel.

Online browsing (some panel types)
For certain panel types such as SPC intrusion panels, datapoints can be fetched directly over a live network connection. The engineer browses the panel's datapoint list online and imports them into SIWENOID. This requires the panel to be fully commissioned and reachable on the network. File-based import has the advantage that it can be done in the office before the physical panel is installed on site.

Whenever the panel configuration changes — new detectors are added, zones are modified, or devices are removed — the export-import process should be repeated to keep the SIWENOID database synchronised with the panel. For file-based systems, re-import the updated export file. For online systems, re-browse and re-import the updated datapoint list.

After import, the physical tree reflects the hardware structure of the panel — sections, zones, and detectors are organised exactly as the vendor tool configured them. This is technically correct but rarely matches how a building is used or how operators need to work.

Logical containers allow the engineer to create a parallel, user-defined structure that organises datapoints in a way that is meaningful for the site — by floor, by area, by function, by tenant, or by any other grouping that makes sense. A logical container is a freely named folder that can hold any selection of datapoints from anywhere in the physical tree.

An important property visible in the screenshot above: every datapoint always knows which physical container it originates from. The PHYSICAL CONTAINER field in the information panel on the right shows “Demo FAC” even when the datapoint is being viewed inside a logical container. This means datapoints can always be moved back to their original physical location, and no information about the physical origin is ever lost.

Physical trees reflect hardware — not how a building is used or how operators think about a site. Logical containers bridge this gap. Common use cases include:

• By floor or area — grouping all detectors on the second floor of a building into a single logical container called “Floor 2”, even if those detectors belong to three different physical panels.
• By function — grouping all output relays that control door locks into a container called “Access control outputs”, regardless of which panel or subsystem they belong to.
• By operator responsibility — grouping all datapoints in a server room into a container called “Server Room” so that the IT team's operator account can be given object permissions scoped to exactly that container.
• For map organisation — creating a logical container that corresponds to one map view, so that a workspace panel showing that container gives the operator a filtered signal log for exactly the area displayed on the adjacent map.
• For reporting — grouping datapoints by business unit, tenant, or zone to make filtered event log exports straightforward.

1. Open the Datapoint Hierarchy tab.
2. Right-click the root node at the top of the tree.
3. Select New container from the context menu.

1. Enter a name for the container. Choose a name that clearly identifies what the group represents.
2. The new logical container appears immediately under the root and is ready to receive datapoints.

To populate a logical container, drag any node from the physical tree and drop it onto the logical container node. A single datapoint can be added to multiple logical containers without conflict — the datapoint is not duplicated, both the physical tree and all logical containers refer to the same underlying point.

To remove a datapoint from a logical container, right-click the datapoint inside the logical container and select Remove from container. The datapoint remains in the physical tree and in any other logical containers it belongs to.

Logical containers can be nested. A logical container can contain both datapoints and other logical containers, allowing a multi-level hierarchy such as Building → Floor → Room.

All logical containers can also be managed centrally from the main menu. Navigate to File → Settings → Logical Containers.

From this screen the engineer can:

• Rename a container — click the container name and enter a new name. Renaming does not affect the datapoints within it or any object permissions assigned to it.
• Delete a container — removes the container and its logical organisation. The datapoints that were members are not deleted — they remain in the physical tree and in any other logical containers they belong to. Object permissions scoped to the deleted container should be reviewed.
• Create a new container — click the Add button (plus icon) as an alternative to the right-click method in the hierarchy.

Logical containers are one of the primary tools for implementing object-level access control in SIWENOID v2. On the Object Permissions configuration screen, permissions can be scoped to a specific logical container, granting or denying a user's ability to see and interact with exactly the datapoints in that container.

Before configuring object permissions, the engineer should plan and create the logical container structure that reflects the permission boundaries required — for example, one container per floor, one per tenant, or one per security zone.

• Logical containers exist only within SIWENOID v2. They have no representation in the connected physical security systems and do not affect how panels or devices operate.
• The logical tree is fully editable at any time. Reorganising logical containers during live operation does not affect system monitoring or event processing.
• When the SIWENOID v2 database is backed up, all logical container definitions and their datapoint memberships are included in the backup.

—

Prev ← Creating Forced Actions Next → Treatment Editing