Procuring security technology: function first, then devices

Many security projects start with a shopping list: three cameras for the entrance, two loudspeakers for the stage, a few radios for the stewards. Each item makes sense, yet the result is rarely a system anyone can rely on when it matters. The camera at the entrance produces a picture nobody is watching. The loudspeaker by the stage does not reach the car park. And the mobile network holds up – until thousands of people try to use it at once.

This article shows how organisers, local authorities, companies and critical infrastructure operators can procure security technology from the task outwards – and check that it genuinely works.

The problem: components instead of functions

Security technology is often bought one component at a time: budgets are split into line items, quotes are easy to compare by unit count, and existing arrangements get carried forward. Traditional fairs, Christmas markets and company sites in particular often rely on equipment bought for a different purpose.

The result is a set of isolated measures – a camera here, a loudspeaker there – but no working security infrastructure. Who looks at the images? Who decides whether to make an announcement? What happens when the power fails or the mobile network is overloaded? Who records what happened, and when?

If you specify the devices first, you answer those questions too late – or not at all.

The basics: what is a safety function?

A safety function describes what must be assured during operation – not what with. For events, properties and facilities, four functions can be distinguished.

1. A reliable situational picture

Those in charge need to see unusual crowd movements, developing situations and whether emergency access routes are clear. A wall of camera feeds is not yet a situational picture; what matters is turning images into a statement: this area is clear, that one is getting crowded. On construction sites and at facilities, the key question is whether someone is entering a restricted area or crossing a fence line.

2. Reaching visitors in an emergency

Information is only useful if it arrives – intelligibly, in the right language, in the right area. For emergency sound systems, DIN EN 50849 sets clear benchmarks, including a Speech Transmission Index (STI) of at least 0.5. Our article on event announcements covers this in detail.

3. Communication under load

Stewards, medical teams, security and technical staff must stay reachable even when the mobile network is congested or the power fails – the function most often assumed and least often tested.

4. Documentation

What was detected and when, who responded and how, which announcement went out where? Traceable records protect those responsible and are the basis for planning better next time.

Running across all four functions is one condition: they must work when things go wrong – during a power cut, on overloaded networks and when crowd flows change suddenly.

In practice: from function to requirement

From the functions you derive requirements that a supplier has to meet and demonstrate. For public bodies, this approach is expressly provided for: Article 42 of Directive 2014/24/EU allows technical specifications to be set out in terms of performance or functional requirements, and German law mirrors this in § 121 GWB and § 31 VgV. Private clients are free to do the same.

The table below shows what such a specification might look like:

Function	Requirement	Evidence
Reliable situational picture	Entrances, bottlenecks, the stage front and escape routes are covered; the situation is shown per area as a statement (e.g. crowd density), not just as a camera image	Site plan marking covered and uncovered areas; trial run with an alert at a defined threshold
Restricted areas and perimeters	Entry into a defined area is reported with location and evidence	Walk-through with a test person; alert appears with location and evidence photo
Reaching visitors in an emergency	All public areas can be addressed by zone; prepared messages in the required languages; music is interrupted for safety announcements	STIPA measurement under IEC 60268-16 at representative points; test announcement per zone; test of the interruption
Communication under load	Team coordination and announcements keep working without mobile networks or internet	Trial run with mobile data switched off or no internet connection
Operation during a power cut	Situational picture and announcements work without mains power for the required duration	Stated runtime; test with mains supply disconnected
Documentation	Alerts, responses and announcements are recorded with time and evidence; report for authority and client	Sample report; log extract after the trial run

A few points on applying this:

• Areas, not unit counts: describe which places need observing and announcement coverage. How many devices that takes is the supplier’s job – and a test of their planning. For video systems, IEC 62676-4 describes how to define in advance what each camera image is meant to achieve.
• Make gaps visible: require uncovered areas to be shown explicitly. A situational picture that claims values where no camera reaches is more dangerous than an honest gap.
• Plan for people: decide who sees alerts, approves announcements and leads the team. Technology without an assigned role is just another isolated measure.
• Include the rules: the safety concept, the Model Places of Assembly Ordinance in its state version and the authority’s conditions set minimum requirements. Our article on event safety standards gives an overview.

The test on the day

No tender replaces the question that ultimately counts: do the planned measures actually work on the day? Four checks help:

1. Does information reach visitors? Make a test announcement in every zone, listen at the noisiest spots and measure intelligibility.
2. Is there a usable picture? Does the situational picture show the critical places – in darkness, against the light and with dense crowds?
3. Does communication hold under load? Can the control room still reach its team when the mobile network is overloaded?
4. Does the system survive a failure? What happens if the power fails or a link drops?

Schedule these checks before the gates open, with the people who will actually be on duty. For sites in continuous operation, repeat them regularly, not just at handover.

How MOVETOS OPS supports this

MOVETOS OPS is the platform that turns individual devices into a system: masts, visitor announcement systems (BDS), interrupt boxes for fairground rides, stages and other third-party sound systems and existing cameras and loudspeakers are controlled from one interface. MOVETOS OPS is available with MOVETOS hardware or as a service (SaaS) for systems already in place.

For the four functions, that means:

• Situational picture: camera images and crowd density per area on a single map. Live detection covers crowd density, people in restricted areas and unattended luggage; when an alert is raised, an evidence photo is stored, but no video is recorded. The AI runs on site, with no cloud required. You set the thresholds.
• Reaching visitors: announcements in five languages, offline as well, per area or everywhere at once. An interrupt box brings fairground rides, stages and other third-party sound systems into emergency communication; the safety announcement interrupts their music. The system suggests, a person approves.
• Communication under load: team coordination also works without mobile networks, over the local network on site. A MOVETOS SET – masts with camera, lighting and loudspeaker – is independent of mains power and networks.
• Documentation: the event is documented in full; the operations log and final report contain alerts with response times, announcements and key figures.

For testing before deployment, an event can first be started as a simulation to rehearse procedures, and every loudspeaker can be checked individually. Our article on planning mobile security technology describes how the layout is planned.

Procurement checklist

• Name the functions: which safety functions must be assured – situational picture, reaching visitors, communication, documentation?
• Define failure cases: which outages must the system survive – power, mobile network, internet?
• Describe the areas: which places need observing, which need announcements?
• Clarify roles: who sees alerts, who approves announcements, who leads the team?
• Require evidence: for every requirement – measurement, trial run, sample report.
• Have gaps shown: uncovered areas must be visible.
• Schedule the test: a trial run before the gates open, with the real team and under realistic conditions.
• Agree on evaluation: a report after the event as the basis for the next plan.

Conclusion

Safety does not come from adding up devices; it comes from functions that hold when it matters. Establish first what must be assured – a reliable situational picture, reachable visitors, communication under load and complete documentation – and you can set out requirements and evidence clearly and compare offers fairly. The test on the day shows whether the plan holds, and that question belongs in every procurement from the outset – for events, companies and critical infrastructure alike.