On this page
- 01Before you start
- 02What ELV means on a building project
- 03Security and access systems
- 04Life-safety systems
- 05Building operation and communication
- 06Specialized and facility-specific systems
- 07The first two weeks: shared infrastructure
- 08The integration matrix
- 09Standards that set performance
- 10Cabling and shared infrastructure
- 11Network architecture, IP addresses and cybersecurity
- 12Power supplies, UPS and availability
- 13Choosing the integration method
- 14Common problems and how to fix them
- 15Pre-sales engineering checklist
- 16Testing, commissioning and acceptance
- 17Frequently asked questions
- 18Related articles on this site
- 19Talk to PSS about the company systems map
This article is a working reference for consultants, contractors, system integrators, presales engineers, project managers, facility managers and technical procurement teams. It maps the major extra-low voltage (ELV) systems on a commercial or institutional project, then the shared rooms, pathways, protocols, power, cybersecurity and tests that decide whether those systems still work together after handover.
Read it in this order when you are pricing or designing a package:
- Name every system and the category it belongs to.
- Size the rooms, shafts, trays and racks for the whole package, not for one trade.
- Write the integration matrix and approve it before you buy.
- Specify measurable performance, not marketing words.
- Plan IP addresses, segmentation, PoE, time and backup power.
- Test the interfaces and the emergency behaviour, not only each box on its own.
Before you start
Have these on the table before a final bill of quantities goes out:
- The full system list, and the line between each contractor.
- What is base scope, what is optional, and what is a provisional allowance.
- Whether supply, installation, programming, integration, testing and maintenance are included.
- Any client-supplied equipment, including X-ray, parking and third-party servers.
- Room, shaft, rack, tray, power, UPS, earthing and fibre capacity.
- Who owns IP addresses, VLANs and firewall rules.
- A draft integration matrix, even if some cells are still “to be confirmed”.
- The codes and authority that apply, and the performance you will measure.
- One named person who coordinates interfaces across vendors.
What ELV means on a building project
ELV stands for extra-low voltage. On a building project the name usually covers a family of systems that run at extra-low voltage or that use low-voltage signalling, data and control.
ELV is not one electrical class that applies everywhere. Voltage limits and safety rules depend on the standard, the circuit type, the installation conditions and the local regulations.
Not every device in the package is a passive signal device. Some contain processors, motors, relays, power supplies or batteries, and they draw real power. Design each system for its electrical, functional, environmental and regulatory needs. Do not design it only because the trade calls it a low-current system.
Four categories
Life-safety systems protect occupants, support emergency response or help people leave the building. Fire detection and alarm, emergency voice communication and selected emergency interfaces sit here. Codes, approvals and the authority having jurisdiction often govern how they are designed and operated.
Security systems protect people, assets, facilities and controlled areas. CCTV, access control, intrusion detection, ANPR and selected vehicle-security systems sit here. The design follows a risk assessment, the security objectives, the operating policy and the regulations that apply.
Building operation and occupant-comfort systems keep the building running, manage energy, carry communication and serve the people in it. Building management systems (BMS), structured cabling, public address, professional AV, master clock and selected automation systems sit here.
Specialized systems serve one operational job: X-ray screening, parking management, nurse call, industrial monitoring or a particular environmental control.
The lines are not absolute. One system can do more than one job, and one project usually mixes several categories.
Why the classification matters
A clear list tells the team:
- Which codes and standards apply.
- Which systems need authority approval.
- Which systems must stay up during an emergency.
- Which interfaces are required.
- Which systems share infrastructure.
- Which systems need their own power or backup.
- Which contractor owns each function.
- How the finished installation will be tested and accepted.
That list is the start of design, cost, procurement, installation and handover.
Security and access systems
The 16 headings below are a planning map for commercial and institutional work. Scope changes with building type, the specification and the client. This is not a list that every standard requires on every job. Some projects add systems. Some combine or omit categories. The approved scope is the real list.
CCTV and video surveillance
A CCTV system monitors, records, retrieves and manages video from cameras across the facility.
Typical parts: IP cameras, network switches, recording servers or NVRs, video management software, storage, operator workstations and displays.
Common interfaces: Ethernet, PoE, ONVIF profiles where the devices support them, RTSP, and the vendor’s own management interface.
The design states camera coverage, the pixel density on the target, recording resolution, frame rate, retention, storage, bandwidth, cybersecurity and the integrations that are in scope.
Access control
Access control authorises and records passage through doors, gates, turnstiles, lifts and other controlled points.
Typical parts: controllers, readers, credentials, electronic locks, door-position contacts, request-to-exit devices and management software.
OSDP
is a reader-to-controller protocol with two-way communication and, when it is configured, Secure Channel protection.
Wiegand
is still on many existing sites. On a new design, compare
OSDP
for security and for what the reader can report back.
Door hardware, emergency egress, the fire-alarm interface, fail-safe or fail-secure behaviour, and the local life-safety rules are coordinated from the start, not after the locks are on site.
Intrusion detection and alarm
An intrusion system detects unauthorised entry or activity in a protected area.
Common devices: magnetic contacts, passive infrared detectors, dual-technology detectors, glass-break detectors, control panels, keypads, sirens and alarm communicators.
The design covers risk classification, detector coverage, false-alarm control, tamper monitoring, alarm transmission, backup power and the link to the security operations platform.
EN 50131
sets requirements for relevant intrusion and hold-up alarm components and systems. Pick the grade from the risk assessment and the specification. Do not assume one commercial grade fits every building.
ANPR and vehicle identification
Automatic number plate recognition (ANPR), also called licence plate recognition (LPR), reads a registration plate from an image.
Typical uses: parking, vehicle access, traffic monitoring, restricted areas and security investigations.
The design accounts for lane geometry, camera position, lighting, shutter and exposure, vehicle speed, plate formats, recognition performance, and the link to access-control or parking software.
Recognition is not authorisation. The application that receives the plate applies the access rules before the vehicle is allowed through.
Parking management, guidance and barriers
Parking systems handle entry and exit, transactions, payment, permissions, occupancy and guidance.
A project may include boom barriers, ticket dispensers, ANPR cameras, RFID readers, payment terminals, occupancy sensors, directional displays and central software.
The design states lane capacity, queue behaviour, safety detection, cable routes, power, interfaces, and what the lane does when communication or power fails.
Vehicle security and screening
This group covers under-vehicle inspection (
UVIS
/
UVSS
), vehicle screening, road blockers, bollards and selected perimeter devices.
Requirements follow the threat assessment, the vehicles, the environment, the detection the client needs, the civil works and the safety standards that apply.
These devices often need their own foundations, power supplies, control cabinets and operator screens, plus a defined link to CCTV, access control and the security management platform.
Life-safety systems
Fire detection and alarm
A fire detection and alarm system identifies fire-related conditions, processes them in a control panel, and starts the notification and control functions the strategy requires.
Typical parts: fire alarm control panels, smoke and heat detectors, manual call points, notification appliances, interface modules and monitoring devices.
The design follows the applicable code, the occupancy, the fire strategy, the system category, the devices chosen and the authority’s approval.
Interfaces may include fire doors, smoke control, lifts, emergency voice and selected building controls. Each one follows the approved cause-and-effect matrix.
Public address and voice alarm
A public-address (PA) system carries announcements, background audio and operational messages.
A voice-alarm or emergency voice system carries emergency instructions where the life-safety strategy requires them.
Parts may include amplifiers, speakers, audio processors, paging microphones, emergency microphones, controllers and monitored speaker circuits.
Emergency voice needs the right design, monitoring, an intelligibility check, backup power and coordination with the fire alarm. Good background music is not evidence that an emergency message will be understood.
Nurse call and emergency assistance
A nurse-call system lets a patient or occupant ask for help, and lets staff receive, prioritise, acknowledge and manage the call.
Typical places: hospitals, clinics, care facilities and accessible washrooms, and any other place where a call for help has to arrive reliably.
The design states call priorities, indication devices, staff workflow, fault reporting, backup power, and any link to mobile devices or clinical systems.
Building operation and communication
Building management system
A BMS monitors, and may control, selected building services: HVAC, pumps, meters, lighting interfaces and other mechanical or electrical plant.
Common technologies:
BACnet
,
Modbus
, Ethernet and
RS-485
, depending on the devices and the architecture.
The design states which system owns each control function, which points are exchanged, how alarms are prioritised, and what the building does when a network or a supervisory controller is down.
Do not treat a BMS as a substitute for a dedicated life-safety control system. Any safety-related interface follows the approved design and the requirements that apply.
Structured cabling and data networks
Structured cabling is the physical path for IP cameras, access-control devices, wireless access points, computers, building systems and other network endpoints.
Typical parts: copper, fibre, patch panels, outlets, racks, cabinets, switches and backbone links.
The design covers cable category, distance, channel performance, PoE, pathway capacity, rack space, labelling, testing and network segmentation.
Several systems may share one cabling installation. Each service still needs its own logical security, bandwidth and availability plan.
Master clock and time synchronisation
A master clock distributes one time to clocks and to the electronic systems that can use it.
NTP
is the usual method for IP devices. Some platforms need another timing method, or a tighter tolerance.
Accurate time matters when you line up CCTV, access events, intrusion alarms, fire records, parking transactions and operational logs.
The design names the authoritative source, the time zone, daylight-saving behaviour where it applies, the synchronisation method, and what happens if the time server is unavailable.
A master clock does not always mean a separate physical clock network. The architecture follows the devices and the accuracy they need.
Public information displays and digital signage
Digital signage distributes messages, wayfinding, operational information and other content.
Typical parts: displays, media players, content-management software, network connections, mounts and power supplies.
Design for viewing distance, brightness, ambient light, operating hours, who owns the content, cybersecurity, mounting, heat and maintenance access.
Professional audio-visual systems
Professional AV serves meeting rooms, conference halls, control rooms, training rooms, auditoriums and collaboration spaces.
It may include displays, projectors, video walls, cameras, microphones, speakers, digital signal processors, amplifiers, matrix switchers and AV-over-IP equipment.
The design covers signal formats, resolution, latency, audio coverage, speech intelligibility, the room’s acoustics, control interfaces, network capacity and how people actually use the room.
Specialized and facility-specific systems
X-ray screening and security inspection
X-ray screening inspects baggage, parcels and other permitted items. Tunnel size, imaging capability and the operator’s workflow differ by product.
The design covers throughput, image quality, the operator workstation, radiation safety, installation conditions, maintenance access and the security procedure the machine sits inside.
Confirm the product specification and the local radiation rules for the equipment and the use you intend.
Industrial monitoring and automation interfaces
Some project maps include monitoring and control interfaces for industrial or facility equipment: selected SCADA interfaces, equipment monitoring, environmental monitoring or automation gateways.
SCADA and industrial automation are wider disciplines. They are not automatically “ELV” on every project. Include them only when the scope, the voltages, the control architecture, the process and the standards say so.
Where they touch the building ELV infrastructure, write down the data exchanged, the communication boundary, who owns each control action, and the cybersecurity requirements.
The first two weeks: shared infrastructure
The expensive coordination mistakes start before anyone orders equipment. Early decisions fix room locations, shaft size, rack space, tray routes, cooling and electrical supplies, and they decide whether integration is even possible later.
Plan the shared infrastructure for the whole ELV package. Do not design each system as if it owned the building.
Telecommunications rooms and equipment rooms
Identify:
- Main equipment rooms and intermediate telecommunications rooms.
- Rack count, rack size and reserved rack units.
- Where switches, patch panels, controllers and servers sit.
- Cooling and ventilation.
- Electrical supplies and UPS.
- Earthing and bonding.
- Access control on the room, and maintenance clearance.
- Fibre backbone routes.
- Spare capacity for systems that are not in this contract.
A figure sometimes used in early talks is about one telecommunications room per
1000
–
1500
m² in a medium building. That is not a design rule. Room count and position come from layout, horizontal cabling distance limits, floor shape, network architecture, the number of endpoints, the structured-cabling standard and the client’s requirements. Do not set the rooms from floor area alone.
Shafts and cable trays
Size containment for the combined load of:
- CCTV and access control.
- Fire detection and voice alarm.
- Structured cabling and fibre.
- BMS and automation.
- PA and AV.
- Parking and vehicle systems.
- Specialized equipment.
- Future expansion.
Tray sizing uses cable quantity, permitted fill, segregation, bend radius, support spacing, fire-stopping, installation access and the standards that apply. A tray that fits today’s cables is too small the day a sixth system is added with no reserve.
Racks and cabinets
Allocate rack space from an equipment schedule: device size, rack units, power, cable entry, ventilation, service clearance and future growth.
Where several contractors share a room, name who owns rack space, patch panels, switches, cable management, labels and power distribution. A coordinated rack elevation is more reliable than each trade guessing its own units.
The integration matrix
The integration matrix says how systems talk, and which party owns each interface. Write each row in this form:
System A sends signal or data X to System B through interface Y under condition Z.
For every interface, record the source, the destination, the trigger or data, the method, the expected response, the responsible contractor and the test.
What each row contains
| Field | Required information |
|---|---|
| Interface ID | A unique reference for the interface |
| Source system | The system that generates the signal or data |
| Destination system | The system that receives it |
| Trigger or data | The event, command, alarm, status or information exchanged |
| Interface method | Native protocol, API, gateway, relay, or another documented method |
| Expected behaviour | What the receiving system must do |
| Failure behaviour | What happens if communication or a device fails |
| Responsibility | The vendor or contractor who implements it |
| Verification | The test method and the acceptance criteria |
| Approval status | Reviewed and approved by the parties who own it |
Example rows
| Source | Destination | Example interface requirement |
|---|---|---|
| CCTV/VMS | Access control | Show the relevant camera when a configured access event occurs |
| Access control | CCTV/VMS | Send selected door events so they can be lined up with video |
| Fire alarm | Access control | Release doors only as the fire strategy approves |
| Fire alarm | Voice alarm | Start the specified emergency message or evacuation sequence |
| BMS | Mechanical equipment | Exchange the approved status, alarm and control points |
| Parking management | ANPR | Match a recognised plate to the transaction and the access rule |
| Parking management | CCTV/VMS | Tie a selected lane transaction or alarm to the relevant video |
| Master time source | IP systems | Give the systems one time reference by the method they support |
These rows are examples, not a default scope. The design team marks which interfaces are necessary, supported by the products, and included in the contract.
Approve the matrix before you buy
If integration waits until installation, teams discover that:
- The receiving system cannot read the source data.
- A required API or licence was never in the price.
- The proposed gateway does not match.
- One contractor assumed the other would supply the interface.
- The event or control point does not exist on the product.
- The network or the server cannot carry the interface.
Review and approve the matrix before procurement when the interface changes product choice, licensing, architecture, safety behaviour or commercial responsibility. A signed matrix does not integrate the systems by itself. It is the baseline for design, buying, installation and acceptance.
Standards that set performance
Words such as “high definition”, “intelligent”, “integrated” or “high reliability” are not a specification. Name the performance you will measure, and the standard that applies to that system.
Fire alarm classification
Follow the local code, the authority and the standards the project adopts.
NFPA 72
and the
EN 54
series are important references. Whether they apply depends on the jurisdiction and the specification.
State the architecture, detector types, notification, circuit supervision, power, interfaces and commissioning.
L1
to
L5
are coverage categories under the relevant fire-detection standards and design practice. They are not interchangeable with every product class, and they do not, by themselves, give you a device count. Coverage follows the fire strategy and the standard.
Fire-resistant and fire-survival cable
Specify fire performance by the job the cable does. Distinguish:
- Reaction to fire.
- Circuit integrity during fire exposure.
- Smoke and corrosive gas.
- Mechanical performance.
- Water exposure.
- How long the circuit must keep working.
PH30
or
PH120
can mean a defined test class under a particular standard and test method. The specification names that standard, the test conditions and the performance required. A number is not a promise that the cable survives every fire, flood or mechanical attack. The test documents and the installation system have to match the project.
Public address and emergency voice
For general sound notification, audibility depends on ambient noise, speaker coverage, room acoustics, device output and the code. A target such as
15
dBA above ambient noise is used in some applications. It is not a universal rule for every appliance and every room.
Emergency voice is a separate question: can people understand the words? The speech transmission index (
STI
) is one way to measure that. A target such as
STI
0.50
may be specified for relevant areas. The threshold, the measurement method, the test points and the operating conditions come from the adopted standard and the project, not from a single number copied into every room.
Account for reverberation, background noise, speaker placement, room shape and emergency-message coverage.
CCTV image detail and DORI
Specify the detail the operation needs, not only a marketing resolution.
IEC 62676-4
gives guidance for video-surveillance design and for DORI:
- Detection. Decide that an object or a person is present.
- Observation. See enough to observe relevant characteristics.
- Recognition. See enough to recognise a familiar person, or to identify relevant characteristics, at the stated performance.
- Identification. See enough to support identification at the stated performance.
The exact requirement depends on the application and on the edition of the standard. Instead of writing only “HD” or “4K”, state the target, the scene width, the camera-to-target distance, the field of view, the lighting, the frame rate and the detail on the target.
A nominal resolution does not make a face identifiable. Lens, viewing angle, mounting height, compression, light, motion and the pixels that actually fall on the target all change the result.
Access control and OSDP
On a new access-control installation, evaluate
OSDP
as the reader-to-controller interface where the equipment and the specification support it. It offers two-way communication and Secure Channel. The security benefit exists only when the devices match, the configuration is correct, and the protection is turned on.
Wiegand
remains common on older sites. It does not offer the same native two-way communication or the same Secure Channel behaviour.
The specification names the protocol, the reader functions, the security requirements, the cable, the distance limit and the test.
Intrusion alarm grading
EN 50131
defines requirements for relevant intrusion and hold-up systems, including grades tied to threat level. Choose the grade from the risk assessment, from insurance requirements where they apply, and from the specification. Grade
2
appears on many commercial jobs. It is not automatically right for every building or every threat.
Network and interface standards
Keep four ideas separate: physical connectivity, the communication protocol, the application interface, and what the system actually does.
Examples:
- Ethernet for IP networking.
-
Cat6orCat6Acopper where it is appropriate. - Fibre for backbone links that need the distance or the bandwidth.
-
RS-485for serial devices that support it. -
BACnetfor building-automation data. -
Modbusfor monitoring and control interfaces that support it. -
ONVIFfor the video functions the profile actually covers. -
RTSPfor real-time media streams the device exposes. -
OSDPfor reader-to-controller communication. -
NTPfor network time.
The same protocol name on two datasheets does not prove the products work together. Confirm profiles, object types, commands, security options, firmware and the functions this project needs.
Cabling and shared infrastructure
Cabling is one of the dependencies that ties the subsystems together. A weak pathway limits performance, slows fault-finding and makes the next system expensive.
Common cable types
| Cable or medium | Typical applications | Key considerations |
|---|---|---|
| Cat6 / Cat6A | IP cameras, networked controllers, access points and other Ethernet endpoints | Channel performance, distance, PoE, environment and termination |
| Fibre-optic cable | Building backbone and links that need distance or bandwidth | Fibre type, link budget, connectors, pathway and testing |
| RS-485 cable | BMS and automation devices that use it | Topology, termination, polarity, shielding and device limits |
| Fire-rated or circuit-integrity cable | Fire alarm or emergency circuits that specify it | Test standard, circuit function, route and installation rules |
| Manufacturer loop cable | Inductive vehicle detectors | Loop geometry, lead-in, detector match and installation |
| Speaker cable | PA and voice-alarm speaker circuits | Load, topology, voltage drop, supervision and fire rules where they apply |
| Control cable | Relays, status and other supported control signals | Signal type, isolation, conductor count, interference and route |
These are typical uses, not a rule for every device. Follow the equipment documents, the standards and the approved drawings.
Segregation
Circuits may need separation for electrical safety, electromagnetic compatibility, fire performance or the installation rules. State the gap between power and signal, the containment that is approved, and any extra restriction on life-safety circuits.
Do not assume every ELV cable can share one tray, and do not assume a fire-rated cable may be routed however the installer finds convenient.
Labelling and testing
One identification scheme should tie drawings, the cable schedule, terminations, patch panels, field devices and test records together.
Test to the cable and the function: copper certification, fibre tests, continuity, insulation checks where they apply, and fire-alarm circuit supervision. Finish and file the cable tests before final system commissioning.
Network architecture, IP addresses and cybersecurity
Many ELV systems now sit on IP networks. A shared network can avoid duplicate cabling. It still has to meet each system’s availability, performance and security needs.
IP address plan
Agree the address plan before devices are installed. It names:
- VLANs and subnet ranges.
- How addresses are allocated and reserved.
- What is static and what uses DHCP.
- Device names.
- Default gateways and DNS, where they apply.
- Management and monitoring addresses.
- Firewall rules and the paths that are allowed.
- Who owns allocation.
Without that plan, contractors assign clashing addresses or overlapping subnets.
Segmentation
CCTV, access control, BMS, AV and other systems do not share one risk profile. VLANs and firewall policy can keep traffic apart and allow only the conversations the design needs.
Segmentation is not the whole security design. Also cover accounts, patching, remote access, logging, secure configuration and vendor support.
Bandwidth and PoE
Size the network from the real devices: traffic pattern, bit rate, multicast where it applies, uplinks, redundancy and growth. PoE maths includes device power, switch budget, cable limits and the budget that remains in the required operating condition. A switch can have free ports and still fail because the power budget or the uplink is too small.
Time synchronisation
Point the systems at a defined time source. This matters when you correlate CCTV, access control, intrusion, parking and other platforms. Specify the authoritative source, the methods the devices support, the time zone, and how a loss of the time source is detected or handled.
Power supplies, UPS and availability
Calculate power per subsystem, then coordinate it across the installation.
Load schedule
For each device or group, record:
- Normal consumption.
- Maximum or peak consumption.
- Start-up or inrush, where it matters.
- The source and the protective device.
- The backup duration required.
- What must keep running when mains fails.
- Battery and maintenance needs.
- Whether the device is part of a life-safety function.
Do not size a UPS by adding nameplate watts and stopping there. Include load behaviour, power factor, efficiency, battery ageing, the environment and the autonomy you actually need.
UPS autonomy
30
to
120
minutes is sometimes used as an early planning range. It is not a universal requirement. Duration follows the code, the system function, the risk assessment, the client specification, the emergency operating strategy and any required standby or alarm period.
Life-safety systems can have their own battery and standby rules. Calculate those from the applicable standard. Do not replace them with a generic UPS duration.
Keep critical loads separate
A fire alarm panel and a CCTV recorder do different jobs and can have different backup rules. Keep the independence, supervision and reliability the life-safety system requires. Do not put a fire alarm control panel on a shared UPS with non-life-safety loads if that conflicts with the approved design, the manufacturer’s instructions or the code.
Decide whether the project needs dedicated power supplies, dedicated batteries, separate UPS systems, or another approved arrangement.
Earthing and bonding
Include earthing and bonding for equipment rooms, racks, cabinets and the connected systems. Follow the electrical design and the standards. Improvised bonds contribute to interference, equipment faults and long fault-finding.
Do not blame every video noise or unexpected reset on earthing alone. Check power quality, cabling, compatibility, configuration and network behaviour as well.
Choosing the integration method
The right method depends on the systems, what they can do, the safety requirement and the information you need. A practical order of preference is:
- A native, documented protocol, when it does the job.
- A supported, documented API or SDK.
- A gateway or protocol converter, when you need one.
- A dry contact, for a simple binary signal.
This is a preference, not a law. A hardwired interface may be required for a safety function. A documented API may be the right method for transaction data.
Native protocols
BACnet
,
Modbus
and
OSDP
do different jobs at different layers. Confirm that the devices support the functions you need, and that the integration exposes the points or commands you will use.
APIs and SDKs
An API or SDK can carry events, transactions, configuration, device status or history. The interface note covers authentication, permissions, data format, errors, licensing, version compatibility, rate limits where they exist, and recovery.
Dry contacts
A dry contact is enough for a simple signal, such as a supported alarm output or a binary status. It does not carry a detailed event description, a transaction history or a complex command. The receiving system has to know what that contact means and what to do.
Safety-related interfaces
A software message, an API event or a generic relay is not a safety function just because it can start an action. The approved design names the interface, the supervision, the response, the failure behaviour and the test.
Common problems and how to fix them
Most of these failures sit between trades, not inside a single defective device.
The tray is too small
A tray sized for one system later carries six or more, with no spare.
Prepare one cable and containment schedule, calculate the capacity, and reserve space for the growth you have written down.
Nobody owns the IP plan
Contractors allocate clashing addresses or overlapping subnets.
Name one party for the master plan, with a written allocation and a change-control step.
The fire-alarm interface is a loose relay
A relay is wired from the fire panel to access control, and nobody has written what the door must do.
Write the cause-and-effect, the door hardware, fail-safe or fail-secure, interface supervision, reset behaviour and who approves it.
Earthing and power were never coordinated
Uncoordinated bonding or power distribution shows up as noise, intermittent faults and resets.
Follow the approved electrical and earthing design, verify the installation, and investigate the fault in a fixed order rather than by guess.
Third-party equipment has no interface
The client buys X-ray or parking equipment, and nobody has stated its network needs or who integrates it.
Put client-supplied equipment on the interface register and the integration matrix. Confirm power, network, licensing, interface documents and acceptance before you buy.
Each system passed, and the workflow failed
Devices pass their own tests. The combined operation does not.
Test whole scenarios across the boundary: normal operation, alarms, faults, loss of communication, recovery and the approved emergency behaviour.
Handover is a box of unknowns
Missing as-built drawings, IP schedules, configuration backups, licences and training records make the building hard to run.
Name the handover package in the contract and check it is complete before final acceptance.
Pre-sales engineering checklist
Presales work is the technical basis for price, equipment, scope and delivery. Complete this before a final proposal or bill of quantities is issued.
Scope
- Identify every system in the project scope.
- Draw the boundary between systems and contractors.
- Separate base scope, options and provisional allowances.
- Confirm whether supply, installation, programming, integration, testing and maintenance are included.
- Identify client-supplied and third-party equipment.
Site and infrastructure
- Confirm layouts, floors, zones and equipment locations.
- Review telecommunications rooms, shafts, racks and trays.
- Identify power, UPS and earthing.
- Review network connectivity, fibre backbone and spare switch capacity.
- Identify environment and mounting.
- Confirm civil works, containment, penetrations and fire-stopping, and who owns each.
Network and integration
- Assign who owns IP addressing and the client’s IT network.
- Set VLANs, subnets, firewall rules and permitted paths.
- Put every required interface in the integration matrix.
- Name the owner of each integration.
- Confirm protocol, API, gateway and licence requirements.
- Define behaviour when the network or a service fails.
- Confirm time synchronisation.
Technical compliance
- Identify codes, standards and authority requirements.
- Define performance you can measure.
- Verify cable and equipment specifications.
- Confirm fire alarm and emergency voice requirements where they apply.
- Define access-control and emergency-egress behaviour.
- Confirm cybersecurity, privacy and data retention.
- Check compatibility across the proposed equipment and software versions.
Commercial and delivery
- Prepare a complete equipment and licence schedule.
- Include installation, configuration, integration and testing.
- List exclusions and dependencies.
- Confirm delivery, warranty, support and maintenance.
- Define commissioning and acceptance criteria.
- Confirm training and documentation.
- Name one party accountable for integration across vendors.
Testing, commissioning and acceptance
Acceptance checks that the installation does what the approved design says, not only that equipment has power.
Test each system on its own
Each subsystem gets the inspection, configuration check, functional test and performance check that applies to it. Examples: camera coverage and image quality, access permissions, fire-alarm device operation, network certification, BMS point checks, PA coverage and parking transactions.
Test each interface
Test every row of the integration matrix against its trigger, expected response, failure behaviour and acceptance criteria. Include the successful case and the relevant fault cases.
Test end-to-end scenarios
Representative scenarios include:
- An access event displays the relevant CCTV camera.
- A fire alarm starts the approved door or voice-alarm sequence.
- A parking transaction matches the correct vehicle and authorisation record.
- The BMS receives a selected equipment alarm.
- A time-synchronisation failure produces the response you documented.
- A network interruption is followed by the documented recovery.
The scenarios match the approved scope. Life-safety tests run under the approved procedure, with the responsible parties present.
Handover documents
Include, as they apply:
- Approved drawings and as-built drawings.
- Equipment and cable schedules.
- Rack elevations.
- Network architecture and IP address schedules.
- The integration matrix and interface documents.
- Test results and commissioning reports.
- Configuration backups.
- Software and licence records.
- Operation and maintenance manuals.
- Training records.
- Warranty and support information.
- A secure handover of administrator credentials.
The acceptance record lists outstanding defects, the agreed corrective action and the party who closes each one.
Frequently asked questions
What is the difference between ELV and structured cabling?
ELV is the broad name for many building systems: CCTV, access control, fire alarm, BMS, PA and specialized technologies. Structured cabling is the physical communications infrastructure that can carry many IP systems. It is one part of the ELV architecture, not another name for every ELV system.
Do all ELV systems use Cat6?
No.
Cat6
or
Cat6A
suits many Ethernet devices. Other systems use fibre,
RS-485
, dedicated control wiring, speaker cable, fire-rated cable, loop cable or a connection the manufacturer specifies. The cable matches the interface and the installation.
Should every ELV system use the same network?
Not necessarily. Systems may share physical network infrastructure where the design allows it. Logical segmentation, access restriction, bandwidth, availability and cybersecurity still apply. Some functions need a dedicated or independently supervised circuit.
Why does the integration matrix matter?
It states which systems exchange information, what triggers the exchange, how the interface works, who is responsible and how the result is tested. It reduces missing licences, incompatible interfaces, scope arguments and integration that fails late.
Is OSDP always mandatory?
Evaluate
OSDP
on new reader-to-controller links because of two-way communication and the security features it supports. Whether it is mandatory depends on the specification, the requirements that apply and the equipment. Existing
Wiegand
sites may stay, with a written migration or integration plan.
Does a 30 to 120 minute UPS prove the ELV package complies?
No. Backup depends on the function, the code, the risk assessment, the load, the standby period and the operating sequence. Calculate and verify the duration against this project.
30
to
120
minutes is only a planning range some teams use at the start.
Can a BMS control the fire alarm?
A BMS may receive selected fire-alarm information, or take part in an interface the design has approved. Do not assume it replaces the fire alarm system, or that it may perform a safety function outside the approved architecture and the requirements that apply.
Should each ELV system be commissioned on its own?
Each system needs its own tests. Final acceptance also verifies the interfaces and the end-to-end workflows. You need both.
Related articles on this site
- CCTV: cameras, recorders, and what coverage means
- Access control: doors, readers, and attendance
- Fire alarm: conventional and addressable systems
- A building management system in plain terms
- Networks: the cabling under every other system
- Public address and voice evacuation
- Parking and barrier systems
- What a UPS does, and how the main types differ
- Video wall and AV systems
- X-ray and security screening
- Physical security and vehicle barriers
- Intrusion alarm: zones, sensors, and arming
Talk to PSS about the company systems map
PSS designs, installs and maintains the networks and infrastructure that cameras, doors, fire systems and building controls share. Contact the PSS team to book a first site survey.


