Your fleet system, ready for electrification.
Your customers are electrifying, and they expect the system that plans their day to handle charging too. i4B builds and runs the integration layer between your product and the energy side — chargers, CSMS, EMS, grid connection — and extends your product with what electrification demands, so your customers get on-time departures and lower energy costs without leaving your screens.
Charging features for DMS, TMS and ITCS products
Four things your product did not need before the fleet went electric. Diesel never constrained the plan. Energy does — and the constraint has to live where the plan lives, or the dispatcher ends up with two systems and one problem.
Energy as a planning constraint
Range per vehicle, state of charge on arrival, time to charge — the timetable now depends on them. The plan has to know, before 04:00, which vehicles can take which blocks.
Charging state next to the vehicle
Which vehicle is plugged in, at what power, on which charger, faulted or not. Today that lives in a charger portal; your dispatcher needs it next to the pull-out list.
Will it be ready at 05:04?
A projected state of charge at departure for every vehicle, recomputed as the night goes, with a swap proposal when the answer is no.
Energy as a cost line per vehicle and route
Delivered kWh per vehicle per night, tariff windows, grid limits and curtailments — the numbers your customers put next to kilometres and the ones their energy supplier invoices.
You keep the plan. We connect the energy side. Together we extend your product.
The integration layer is the necessary piece between a fleet system and an energy system. We build it for your product, run it against your customers’ depots, and extend your product with what electrification requires — as data your UI renders, not as a second screen.
What your product keeps
- Vehicles, blocks, routes and departures
- Dispatcher screens and workflows
- Telematics and OEM data you already hold
- Customer, cost and reporting structure
What we connect
- Chargers over OCPP 1.6 / 2.0.1 — directly or through the depot’s CSMS
- EMS and grid signals: envelope, tariffs, curtailment (OpenADR)
- Roaming for charging on the road (OCPI / OICP via Hubject)
- One depot model: vehicle, stall, charger, envelope, departure
What your product gains
- Charging state and session history per vehicle
- Readiness forecast per departure, swap proposals
- Charging plan under the grid limit, departure-aware
- Energy cost per vehicle, route and customer; CDRs that reconcile
Where a depot has no CSMS yet, the layer includes a light station layer scoped to private depots — enough to run the chargers, never a public charging platform.
Electrification features your customers expect — rendered by your UI, fed by the layer
Each item is data with a contract. Your front end shows it in your words; the layer keeps it true against the chargers and the grid.
Charging state in your vehicle record
Plugged in, charging at 75 kW on charger C-24, faulted, reserved for the 04:20 pull-out — live, next to the vehicle, without a second login.
Readiness per departure, with swap proposals
Projected state of charge at departure for every vehicle in the plan. When a pull-out is at risk, a swap candidate with matching block requirements — confirmed by your dispatcher, never automatic.
A charging plan that respects the grid
Earliest departure first under the depot’s envelope, tariff windows and curtailments. Storage and PV included where the depot has them. Returned as a plan per vehicle and a power profile per hour.
Energy that reconciles
Delivered kWh per vehicle, per route, per customer, with a charge detail record per session. The operator’s report and the energy supplier’s invoice match.
- DiscoveryAbout two weeks: your systems, your customers’ depots and the first depot to connect. Scope fixed before any commitment.
- Integration layerBuilt and run by i4B, one adapter per system, delivered as a versioned API.
- ExtensionReadiness, charging state, plan and cost arrive as data for your UI; the first depot goes live in sprints, observing before controlling.
- SupportThe same team in production, on a retainer you choose.
Thirty minutes, one depot in mind, a straight answer.
What you can sell to operators
Electrification turns a customer request into a product line. This is what the integration does for your business, not only for the depot.
Customers who stay
Operators who electrify keep the fleet system that handles charging for them. The churn risk becomes an upsell conversation.
Tenders you can answer
Public transport tenders increasingly ask for charging management, readiness per departure and energy reporting. You can answer yes without building a charging platform.
A new module on your price list
Charging state, readiness, charging plan and energy cost as a priced add-on per depot or per vehicle, sold to customers you already have.
No charging platform to maintain
OCPP versions, charger quirks and CSMS changes stay in the layer we build and run. Your roadmap stays yours.
From discovery to a running integration — in sprints you can see
We start by learning your product and your customers’ depots, and we deliver working results every one to two weeks.
Discover
Your data model, your customers’ depots and energy systems, the first depot to connect. Scope and approach fixed before any commitment.
Connect
The energy side: chargers over OCPP, the depot’s CSMS or EMS, grid signals — an adapter per system, built to what it actually exposes.
Extend
Your product gains charging state, readiness, plan and cost — as a versioned API your developers call like any other service.
Run
Live sessions on a real depot. Readiness recomputed as the night goes; deviations and their causes visible in your product.
Support
The team that built the integration supports it in production and keeps the protocol side current as OCPP and OCPI evolve.
What changes for your customers when the fleet system handles electrification
Seen from the depot floor, not from the architecture diagram.
Why fleet-system vendors work with i4B
i4B has built software for mobility since 2005; our charging software runs in production in 12 EU countries.
Vehicle and timetable data first
Blocks, departures, telematics, rFMS and OEM APIs: we model the depot the way your product already does.
The energy side, handled
OCPP 1.6 and 2.0.1 chargers or the depot’s CSMS. Open Charge Alliance member, tested on real chargers in our EVLAB.
One adapter per system
Built to what your product exposes, in 1–2 week sprints, supported by the same team in production.
For products that already own the fleet’s day
Depot management systems
Asked for charging and readiness by every electrifying operator — without wanting to become a charging-platform vendor.
Transport and fleet management systems
Whose customers run mixed fleets and need charging planned where routes are planned.
ITCS and scheduling vendors
Whose timetables decide the energy demand — and should decide the charging plan too.
Truck service and booking platforms
Who book services for vehicles on the road and want the charging slot to be one of them, held at the station.
Are you a CSMS or EMS vendor? Fleet integration for energy platforms → · Running the depot yourself? Choose your fleet system with us →
Tell us about your product and the customers who are asking
Thirty minutes. We look at how your product holds vehicles and departures, walk through how the integration would look in your UI, and tell you honestly what it would take — and whether we are the right partner for it.
- 1 · You send one emailWe reply within 24 business hours to pick a slot.
- 2 · Bring one customer’s depot in mindFleet size, a rough timetable and the energy system they have, if any.
- 3 · You get a straight answerFit or no fit, which capabilities first, what your API would need to expose. No sales sequence afterwards.
Thank you. We reply within 24 business hours to pick a slot for your 30-minute call.