Siemens - Knowledge Base
Overview of Siemens building automation and fire alarm protocols — XLS/Cerberus, SBT-FSI, XNET, Firefinder variants and integration considerations.
What Siemens Protocols Are
Siemens uses multiple proprietary protocols across its building automation and fire alarm product lines. These protocols are not interchangeable — each variant requires a specific gateway driver and configuration approach. Siemens protocol integrations typically convert to BACnet or Modbus for supervisory system connectivity.
Core Concepts
| Concept | Description |
|---|
| Protocol Variant | Siemens products use 4+ distinct, incompatible communication protocols |
| Driver | Each variant requires a specific QuickServer driver — wrong driver = zero communication |
| Multi-Party Coordination | Siemens projects often involve 3+ parties: fire contractor, BMS integrator, end customer |
| Points List | Device-specific data point definition — typically provided by the fire or building automation contractor |
Protocol Variants
| Variant | Domain | Typical Products | Key Characteristics |
|---|
| XLS / Cerberus | Fire alarm | Cerberus PRO panels | Fire panel data: zones, detectors, alarms |
| SBT-FSI | Building automation | Desigo CC, PXC series | Serial (19200/7E1 default); structured intake questionnaire required |
| XNET | Network protocol | Older Siemens network infrastructure | Legacy network-layer protocol |
| Firefinder | Fire detection | Firefinder XLS panels | Fire detection variant, distinct from Cerberus |
[!CAUTION] The #1 recurring support issue is variant misidentification. Assuming the wrong Siemens variant requires a complete driver swap and configuration rebuild. Always confirm the exact panel model and variant at intake.
Integration Prerequisites
- Identify the exact Siemens variant — XLS/Cerberus, SBT-FSI, XNET, or Firefinder.
- Panel model and firmware version — determines driver compatibility.
- Points list from the contractor — fire or building automation contractor must provide.
- SBT-FSI questionnaire (if applicable) — structured intake form with device and BACnet fields.
- Coordinate all parties — fire contractor, BMS integrator, and end customer must align on scope and timeline.
Common Problems
- Wrong variant assumption — misidentifying the Siemens protocol variant leads to incompatible driver selection and full project rework.
- Multi-party coordination delays — fire alarm projects require alignment between the fire protection company, BMS vendor, IT department, and end customer.
- Points list unavailable — configuration is blocked until the fire or building automation contractor provides the device’s data point definitions.
- Addressing/config mismatch — incorrect parameter capture leads to communication failures during commissioning.
- Customer unresponsiveness — multi-party projects experience longer response gaps due to coordination overhead.
| Tool | Type | Description |
|---|
| Desigo CC / Insight | BMS Platform | Siemens’ building automation management platform — point browsing, trending, scheduling, and alarm management. |
| Cerberus FIT | Fire Configuration | Fire alarm configuration software for Cerberus PRO panels (XLS variant). Required for fire panel point export. |
| XWORKS Plus | Configuration | Engineering tool for configuring Siemens P1/FLN controllers and network devices. |
Related Pages
Related content
Overview of DNP3 (Distributed Network Protocol) for utility and SCADA integration — protocol levels, master/outstation architecture, and common configuration pitfalls.
Overview of Johnson Controls Metasys N2 protocol for building automation — variants, point counts, device addressing, and common integration pitfalls.
Overview of MQTT (Message Queuing Telemetry Transport) for building automation — publish/subscribe model, TLS security, broker configuration, and cloud integration.
Need more help?
If this page does not resolve the issue, contact Chipkin support with the product model,
protocol details, and any diagnostics you have already captured.
Open Chipkin Support