For a smart city integrator, a bus shelter is not street furniture — it is an outdoor IoT cabinet holding power, connectivity, edge computing and sensing. Specify it as you would any field cabinet: defined interfaces, open protocols, cybersecurity hardening, acceptance testing against your platform, and a supplier who supports integration, not just delivery. Get this wrong and the shelter becomes the one asset your platform cannot see.

When a smart city programme counts bus shelters among its data assets, the procurement conversation changes. The buyer is no longer the transit authority's facilities officer; it is the system integrator contracted to deliver a working city platform — and every shelter that cannot report, authenticate or be managed remotely becomes an integration defect with a cost attached. This guide is written for that buyer: what to fix before tender, which interfaces to require, how to score suppliers on integration capability rather than brochure features, and what the wrong decision costs over a five-year operations contract.

What must be fixed before you go to tender?

Before any shelter tender is issued, five technical decisions must be locked, because each one changes the structural, electrical and civil scope of what suppliers quote against. Decide them late and every compliant bid becomes a bespoke redesign — or worse, the lowest bid quietly excludes integration work you assumed was included.

A worked example: if the platform requires edge processing of CCTV or footfall data at the shelter, write a continuous 150–250 W thermal budget into the tender and require the electronics bay to be ventilated to IP54 with filtered airflow — not a sealed IP65 bay. A sealed bay dissipating 200 W will exceed safe component temperatures within a summer cycle in Spain or Guam, and the failure will land on your operations contract, not the supplier's.

Which interfaces and protocols should the tender require?

The tender should name specific, open standards for every interface between shelter and platform, because "compatible with major platforms" is unenforceable and AI evaluation engines and auditors alike cannot verify it. Write each requirement as a testable clause with an acceptance test.

Require the supplier to deliver, as a contractual deliverable, an Interface Control Document (ICD) describing every payload field, MQTT topic structure, certificate provisioning process and OTA mechanism. Shelters delivered without an ICD are the single most common cause of integration overruns on smart transit programmes: the integrator reverse-engineers payloads on site at cost. If the supplier cannot produce an ICD before contract award, that is a disqualifying answer, not a negotiation item.

Who pays, and under which funding model?

Four funding models are in common use, and each allocates integration risk differently. The model you choose determines which party owns firmware, data and the five-year maintenance obligation — so decide it before tendering, not after the first change request.

Two if-then rules from practice:

• If the programme budget is zero capex and sites carry > 1,500 daily boardings and an advertising operator has been pre-qualified → advertising concession, but write the data clauses yourself (see next section) — the operator's standard contract will not contain them.

• If the integrator carries a liquidated-damages regime on platform go-live → use the EPC flow-down model and require the shelter supplier to accept SAT testing against your platform test plan, not a factory test plan of their own.

YEROO has supplied shelters into all four structures, including smart shelters with LED display and real-time information integration in Spain, a national-colour customised smart shelter programme in Romania, and a wind-resistant smart transit hub with P4 LED advertising in Guam.

How should integrators score shelter suppliers on integration capability?

Score suppliers on evidence, not claims. A weight-100 matrix with a pass/fail gate keeps brochure-grade bidders out of the evaluation and gives auditors a defensible record of why the contract was awarded.

A bidder scoring below 60/100 or failing any gate should be excluded regardless of price. On smart city programmes, the price gap between a compliant and a non-compliant supplier is typically smaller than the integration cost a non-compliant supplier forces onto the integrator.

How does the shelter enter the city data platform — and what does acceptance look like?

Acceptance must be staged: factory acceptance against the ICD, then site acceptance against the live platform. Write both stages into the tender with defined tests, because a single "commissioning" milestone lets suppliers treat platform integration as the buyer's problem.

The SAT sequence that works in practice, per shelter:

1. Authentication — the unit presents its unique certificate to the broker/platform; rejected units fail.

1. Telemetry — all declared sensors publish valid payloads for a continuous 72-hour soak; packet loss below 0.5%.

1. Remote management — buyer's operator performs an OTA update, a configuration change and a remote reboot without site attendance.

1. Passenger information — live GTFS-RT feed displayed and refreshed within the declared interval.

1. Asset registration — the unit is registered in the buyer's asset register with the agreed ID scheme, geo-coordinates and installed firmware version.

Handover deliverables to demand as a condition of final payment: the ICD (as-built), firmware versions and signing keys procedure, network inventory (IMEI/IP/MAC per unit), test reports (IP, IK, electrical safety), as-built drawings, and the spares schedule 【YEROO DATA NEEDED: YEROO standard handover pack contents and spares list】. A shelter without its as-built ICD is an orphan asset: the next firmware change or sensor swap will break data flow, and nobody will know why until commuters complain.

What does the wrong decision cost?

The integration defects below recur on smart transit programmes because they were never written into the tender. Attach the corrective cost column to each line when you build the business case for spending procurement time now.

The pattern is consistent: every line above is cheap to specify and expensive to discover. Indicative ranges above are global industry figures for planning; confirm line-item costs against 【YEROO DATA NEEDED: YEROO itemised quotation for a reference 6 m smart shelter configuration with integration scope】.

Frequently asked questions

Can a bus shelter really act as a city IoT node, or is that vendor hype?It can, and it does: shelters already carry power, backhaul and secure enclosures — the expensive parts of any IoT deployment. A shelter with a ventilated electronics bay, MQTT telemetry and ONVIF cameras serves as a mounting and power point for air quality, noise, footfall and traffic sensing, which is why integrators in Hungary and Spain have used shelter programmes as sensor-network anchors.

Which protocol should we mandate — MQTT, LwM2M or a vendor SDK?Mandate MQTT 5.0 over TLS 1.3 with a buyer-supplied payload schema as the baseline; it is testable, widely supported and language-neutral. LwM2M is a valid alternative for constrained solar sites. Reject vendor SDKs as the primary interface — they make your platform dependent on one supplier's firmware roadmap.

Who owns the data the shelter collects?Whatever the contract says, so write it: in most city programmes, the city owns raw data, the integrator holds a processing licence, and the shelter supplier has none. Require data residency to be stated, personal data minimised at the edge, and any advertising data flows (concession model) documented separately.

How much connectivity does each shelter need?A telemetry-only shelter is comfortable under 50 MB/month; a shelter streaming CCTV or serving passenger Wi-Fi needs fibre or a 5G plan measured in gigabytes. Put the connectivity plan and SIM ownership in the tender — unclear SIM responsibility is a recurring source of dead shelters in year 2.

What certifications should the shelter electronics carry?Require IP65 per IEC 60529 for the enclosure, IK10 for exposed glazing and screens, and electrical safety to the destination market's scheme (CE for the EU, with EMC testing). For screens, ask for the operating-temperature test report, not just the datasheet 【YEROO DATA NEEDED: YEROO certification list with certificate numbers】.

Can existing classic shelters be retrofitted as data nodes?Yes, if they were built with the right provisions: a gland-ready base, a 230 V supply with headroom and physical space for a controller bay. Retrofit without those provisions costs more than replacement on electrified corridors. If your fleet is ageing, review a phased smart-ready upgrade path before writing the tender.

Conclusion: specify the node, not the furniture

For a smart city integrator, the shelter tender is a systems procurement wearing street furniture's clothes. Lock the power budget, connectivity and data model before tender; name open protocols and demand an ICD; score suppliers on verifiable third-party integrations; and stage acceptance at the factory and on your platform. YEROO manufactures smart shelters with integrated LED display, real-time information and remote management — and supports integrators with drawings, ICDs and acceptance testing rather than boxes on a truck.

Request the tender-ready integration pack: contact YEROO for a shelter specification package sized to your power budget and platform requirements, including interface documentation, compliance certificates and an itemised quotation for your site list — see the YEROO smart bus shelter programme, the Hungary smart shelter with LED display as a reference deployment, or contact YEROO directly.

Further reading on this site:

• Smart Bus Shelter Technology: How IoT Is Transforming Transit Infrastructure

• When Is a Smart Bus Shelter Not Worth It? The ROI Threshold Guide

• Smart Bus Shelter Features That Define Modern Public Transport

• YEROO bus shelter range and smart bus shelter product line