A digital signage reference architecture is a blueprint for how content flows from creation to screen. It defines the layers (CMS, network, endpoints), their interactions, and the design decisions that determine whether the system scales to 10,000 screens or breaks at 50. This is the document your IT team, integrator, and vendor should agree on before a single cable is pulled.
When to Use a Reference Architecture
- Enterprise rollouts — 50+ screens across multiple sites need a documented architecture
- RFP responses — architecture diagrams are table stakes for government and enterprise procurement
- IT security reviews — your CISO needs to see network placement, data flows, and trust boundaries
- Multi-vendor integration — when signage connects to building management, room booking, or corporate ERP
How the Architecture Works
Layer 1: Content Management (CMS)
The brain. Handles template design, scheduling, data binding, user roles, and content publishing. SpinetiX offers two CMS options: Arya Cloud (SaaS, multi-tenant, ISO 27001) and Elementi (on-premises Windows application, air-gap capable). Both publish to the same hardware using the same protocols.
Layer 2: Data Integration
The data layer connects external sources to content templates. SpinetiX has 250+ native widget-constructors for: REST APIs, databases, calendar feeds, CSV/JSON/XML files, IoT sensors, room booking systems (Exchange, Google, Robin), and smart building protocols (BACnet, Modbus via gateway). No cloud middleware required.
Layer 3: Network Transport
Content travels from CMS to players over standard HTTP/HTTPS. For cloud: players connect outbound on port 443. For on-premises: players connect to the local Elementi server. Bandwidth per player: 1–5 MB per sync for data-driven content. Players should sit on a dedicated VLAN with firewall rules limiting traffic to CMS and data source IPs only.
Layer 4: Endpoint Rendering
SpinetiX media players (iBX440, iBX410, HMP400) render content locally using a hardware-accelerated engine. Not a browser. Not an app. The player pulls content, stores it locally (offline-first), and renders in real time. Power: 6W. Failure rate: 0.4% over 10 years. Deep dive into media players →
Layer 5: Monitoring & Management
Fleet health monitoring: online/offline status, screenshot capture, firmware version, storage usage. SpinetiX provides this via Arya dashboard or SNMP (v2c, read-only, disabled by default). For enterprise NOCs, integrate with existing monitoring tools via SNMP traps or REST API polling.
Key Parameters
| Layer | SpinetiX Implementation | Key Decisions |
|---|---|---|
| CMS | Arya (cloud) or Elementi (on-prem) | SaaS vs. self-hosted, single vs. multi-tenant |
| Data Integration | 250+ native widgets, no middleware | Which data sources, refresh intervals, caching |
| Network | HTTPS, ports 80/443 + 81/9802 | VLAN placement, firewall rules, bandwidth planning |
| Endpoints | iBX440/iBX410/HMP400, DSOS | Resolution, zone count, offline cache duration |
| Monitoring | Arya dashboard, SNMP v2c | Integration with NOC tools, alert thresholds |
| Redundancy | Local cache (offline-first), CMS replication | RPO/RTO targets, failover scenarios |
Common Mistakes in Architecture Design
- No VLAN segregation. Putting media players on the same flat network as workstations creates security blind spots. Dedicate a VLAN. It takes 30 minutes and eliminates an entire category of risk.
- Over-engineering bandwidth. Data-driven signage is lightweight. Don't spec fiber to each screen unless you're streaming live 4K video. Most SpinetiX deployments use existing Cat5e infrastructure with no issues.
- Skipping offline-first design. If your architecture assumes 100% network uptime, it will fail during the CEO's keynote. SpinetiX players cache content locally — design your architecture to leverage this, not fight it.
- No architecture documentation. "It just works" is fine until someone leaves the company. Document your architecture. Future you — and your successor — will be grateful. We can help with architecture design →