System Architecture
The Access Control System (ACS) is organized in a hierarchical structure that separates:
- Customers - top-level organizational entities.
- Tenants - logical containers grouping hardware and configuration.
- Hardware - controllers, doors, readers, and other physical devices.
- Logical objects - users, schedules, access rules, alarms, and other operational entities.
Customer
A Customer is the top-level organizational entity within the Access Control System (ACS). Each customer represents an independent client, company, or organization that owns one or more tenants and has a dedicated customer database.
- Defines the administrative and operational boundary for the system.
- Contains all tenants, hardware, logical objects, and agents under its scope.
- Data remains isolated per customer, although the Master DB can coordinate information across multiple customers.
Synonyms / Alternative Terms
Organization, Company, Client, Account, Entity
Example
In a multi-site deployment, “Acme Corporation” could be a customer. It may contain multiple tenants such as its headquarters, regional offices, or separate departments, each with their own hardware and logical configurations.
Tenant
A Tenant is a logical container within a customer’s database that groups together related access control hardware, users, and configuration data. Tenants organize large or multi-site deployments into independent units, such as separate buildings, departments, or divisions, that share the same customer account.
Properties
- Each tenant can have its own set of controllers, doors, readers, cardholders, schedules, and access rules.
- Managed independently by assigned operators (agents).
- Allows the system to be divided into smaller, isolated sections for easier management.
Synonyms / Alternative Terms
Site, Building, Division, Department, Unit, Subdomain
Example
A tenant could represent a single building, site, or division within a customer’s organization, with its own hardware, users, and access settings. Multiple tenants can coexist under one customer.
Notes
- A default tenant is created automatically during system initialization.
- The default tenant serves as the primary environment until additional tenants are added.
ACS Hierarchy Layers
The table below lists the official terms used in the system, along with common synonyms and a brief description of each layer:
| Layer | Official Term | Synonyms / Alternative Terms | Description |
|---|---|---|---|
| 1 | Customer | Organization, Company, Client, Account, Entity | Top-level organizational entity. Owns one or more tenants and has a dedicated customer database. Defines the administrative and operational boundary. |
| 2 | Customer DB | Instance, Schema, Local DB, Data Store | Database dedicated to a single customer. Contains all their tenants, hardware, and logical objects. |
| 2 | Tenant | Site, Building, Division, Department, Unit, Subdomain | Logical container within a customer’s database. Groups related hardware, logical objects, and configuration data. Managed independently by assigned agents. |
| 4 | Hardware Hierarchy | - | Includes controllers, doors, floors, card readers, and other physical devices within a tenant. |
| 5 | Logical Hierarchy | - | Includes agents (operators), cardholders, visitors, schedules, time periods, alarms, and access rules within a tenant. |
| 6 | Master DB | Global DB, System DB, Hub Database, Central Repository | Central database uniting all customer databases. Coordinates global settings, reporting, or potential federated operations. |
| 7 | Agents | Administrators, Operators, System Users, Supervisors, Managers | Users who manage the system, configure tenants and hardware, define access rules, and supervise operations. |
Note on Federation Architecture:
The current ACS design supports centralized customer and tenant management. Future enhancements may introduce a federation architecture, allowing multiple ACS deployments to coordinate while maintaining independent databases. The current hierarchical structure (Master DB > Customers > Tenants > Hardware/Logical objects) is designed to facilitate such an evolution.
Rationale for ACS Base Architecture
The ACS is designed around a hierarchical structure that separates customers, tenants, hardware, and logical objects. This base architecture provides:
- Clear administrative boundaries between customers and their tenants.
- Independent management of hardware and logical objects per tenant.
- Centralized coordination via the Master DB for reporting, global settings, and potential cross-customer operations.
This structure also anticipates future enhancements:
- Federation architecture: Multiple ACS deployments may coordinate while maintaining independent customer databases.
- Scalable tenant and hardware management: Supports multi-site or multi-division deployments with isolated yet consistent access control.
- Flexible agent roles and permissions: Can evolve to accommodate more complex organizational hierarchies or delegated administration.
The base design ensures that the system is robust today while remaining adaptable for future growth and advanced architectures.