Yes, an AVM can integrate with almost any onboard hardware, but only if the tender asks for it explicitly. In practice, "hardware-agnostic" means software that runs on standard devices and talks to existing onboard equipment through open, documented interfaces, instead of arriving bundled with one vendor's proprietary box. Five clauses in the tender document do most of the work: specify outcomes, require open interfaces, decouple hardware, secure data ownership and exit, and test the claims before award.
The reason this matters is structural. Writing in Mass Transit in February 2026, Gabriel Lopez-Bernal of Icomera North America argued that many transit software vendors cannot sell software alone and must supply hardware to collect the data they need, because the sector lacks open, standardised hardware platforms. The author represents a connectivity vendor, so read it as an industry opinion, but the mechanism he describes is familiar to any buyer who has tried to scale a pilot.
Why do AVM tenders end up locked to one vendor's hardware?
Lock-in rarely comes from one bad clause. It builds from several habits.
- Product-shaped specifications. The tender describes the incumbent's exact device. Or it uses an "approved equal" clause, which in the article's words rarely produces real competition.
- Bundled supply. The software is only offered together with routers, onboard computers or other devices, so replacing the software means replacing the hardware.
- Pilots that never end. Proving a commercially available product is evaluation, not innovation, and agencies that run long pilots often fail to scale them.
- Closed data. The data collected on board is only accessible through the vendor's own tools.
What are the 5 clauses for a hardware-agnostic AVM tender?
1. Specify outcomes and data, not products
Describe what the system must measure and at what quality, rather than which device must measure it. For example: position update interval, share of trips correctly matched to a vehicle, accuracy of stop arrival and departure detection, availability of the service. These are the same quality factors that decide whether planning tools can be trusted: Swiftly, for instance, reports that AVL update intervals above 30 seconds degrade arrival and departure detection, and that login rates of 50% to 75% at some agencies leave many trips unmatched. Our article on how AI is changing bus network planning shows why this data quality is the foundation for everything else.
2. Require open, documented interfaces
Ask for public API documentation, a test environment, and standard outputs: GTFS and GTFS-RT for schedules and real-time feeds, SIRI and NeTEx where the network or country requires them. See how to integrate GTFS-Realtime and SIRI with existing bus fleet hardware. Ask for the list of interfaces already running in production, such as passenger information displays, passenger counting or planning software, rather than interfaces that are only possible. Pysae, for instance, has published integrations with Hastus or ABC Planning, with the Iris passenger counting solution, and with Hanover Displays passenger information over an IP connection.
3. Decouple hardware from software
Allow standard devices, such as smartphones or tablets, as a compliant onboard option, and write a minimum device specification rather than a model. Where the vehicle already has an onboard computer, ask the bidder to state how the software connects to it. In Europe, the ITxPT standard defines interoperability at three levels: hardware, communication protocol and services. According to the Mass Transit article, Helsinki, Paris, Stockholm and Dubai order buses with ITxPT-certified onboard computers so that agencies can select software without lock-in. Ruter in Oslo has moved towards an open ITxPT-based onboard architecture. For the hardware side, see how many telematics boxes a bus actually needs and hardware-light versus hardware-heavy bus tracking.
4. Secure data ownership, export and exit
State in the contract that as-run data (positions, trips operated, punctuality, kilometres) belongs to the agency or operator. Require bulk export in a documented format at any time, an exit plan with transition assistance, and clarity on whether export has a cost. A system whose data cannot be extracted cannot be replaced, which makes any change of vendor too expensive to be a credible negotiating position.
5. Ask for lifecycle cost, outcome-based acceptance and a pre-award test
Ask bidders for total cost over the contract term, with subscription services treated as operating costs, so offers can be compared. The Mass Transit article gives an illustrative example of a guaranteed USD 500,000 over 10 years versus a USD 400,000 upfront purchase that grows to USD 1.1 million. Base acceptance on measurable outcomes such as those in clause 1. Finally, before award, run a short demonstration on a mixed set of your own vehicles: connect to an existing device, call the API, export a day of data. The article's recommendation to treat commercially proven products as demonstrations rather than pilots follows the same logic.
How can you check a "hardware-agnostic" claim before signing?
Four quick tests separate real openness from marketing.
- Mixed fleet demo: run the software on two or three different vehicle types and onboard setups from your own network.
- API test: ask for sandbox access and call the documented endpoints yourself.
- Export test: request a full export of a day of trips in a documented format.
- Reference check: speak to a customer that migrated from another system, not only to one that started from scratch.
For the wider selection process, see how to choose an AVM system for bus operators and our AVM features checklist for 2026.
Pysae is a SaaS AVM platform that runs on standard devices and exposes standard outputs. It is priced per vehicle, adapted to each network.
Frequently asked questions
What does hardware-agnostic mean for an AVM system?
It means the software does not depend on one vendor's proprietary onboard device. It runs on standard devices such as smartphones or tablets and connects to existing onboard equipment through open, documented interfaces.
Which standards should a tender cite?
GTFS and GTFS-RT for schedules and real-time data, SIRI and NeTEx where required by the network or country, and ITxPT for onboard interoperability in Europe. The right mix depends on your network and national requirements.
How do I avoid an "approved equal" trap?
Write requirements as outcomes and interfaces rather than product names. State measurable thresholds for data quality, specify open interfaces, and require a pre-award test on your own vehicles.
Sources: Gabriel J. Lopez-Bernal, "The Hardware Trap: Why Transit Can't Buy Tomorrow's Software", Mass Transit (17 February 2026); INIT, "The crucial role of ITxPT in modern transit"; HERE, "What Oslo's buses can teach us about data collection" (Ruter); Swiftly, "3 lessons from hundreds of data therapy sessions"; ITxPT specifications (itxpt.org).