EV Charging Management Software in India — Jaipur Studio

A charging management system (CMS) is the product a network actually operates. On the charge point operator side it is the CPMS, and OCPP 2.0.1 calls that server a CSMS. On the e-mobility service provider side it is the platform the driver belongs to. TheTriFusion builds those as two roles in one EV charging CMS, not as two unrelated products that happen to share a logo.

You can launch one role. A CPO that does not roam yet still needs OCPP. An eMSP that owns no chargers needs OCPI and a driver app, not a yard of hardware. A company that is both keeps stations and driver tokens in the same CMS so the second role is a phase, not a rewrite. Roaming between you and a partner is OCPI 2.2.1. That is not the same thing as operating a public roaming hub for every network in the country.

EV charging station software is the system of record for sites you operate. A charge point management system, usually shortened to CPMS, is that product: which stations exist, which connector is free, which session is running, and which fault needs a person. OCPP 2.0.1 calls the server a Charging Station Management System (CSMS). OCPP 1.6 calls it the Central System. The job is the same. Drivers never log into the CPMS. Operators do.

A useful CPMS stores the station once and shows it everywhere else: the driver map, the tariff, the invoice, and the roaming record if you publish the site. We model site, charger, connector, and session as separate records so a dual-gun charger does not collapse into a single pin. Meter values stay attached to the session that produced them. Without that split, billing and uptime reports argue with each other.

The OCPP CMS backend is the server chargers dial. OCPP 1.6J is JSON over a WebSocket. The messages operators rely on are BootNotification, Heartbeat, StatusNotification, Authorize, StartTransaction, StopTransaction, MeterValues, RemoteStartTransaction, and RemoteStopTransaction. Configuration, firmware triggers, and charging profiles are in the same specification, and a given charger implements a subset. We record which subset each model actually answers.

OCPP 2.0.1 is not a rename of 1.6. It uses a device model, TransactionEvent instead of the old start and stop pair, and stronger security options, including certificate-based connections. It is also the practical path when you later want ISO 15118 messages to pass through the charger. Many chargers already installed in India still speak 1.6J only. A backend that must run a mixed fleet implements both and keeps the session model identical so billing does not care which protocol started the energy flow.

OCPI roaming is how two companies share charging without merging their apps. OCPI 2.2.1, maintained by the EVRoaming Foundation, is an interface between businesses, not between a charger and a server. The modules we implement when they are in scope are credentials, locations, tariffs, tokens, commands, sessions, and charge detail records (CDRs). Charging profiles exist in the specification for smart-charging limits across a roaming session. We turn a module on only when the partner actually supports it.

A practical rollout is one partner, not a theoretical hub of every network. You exchange credentials, the charge point operator publishes locations and tariffs, the eMSP shows those pins in its driver app, a token authorizes the driver, and a CDR is the record both sides use to settle. Partial implementations are common. We keep modules separate so a partner that cannot send commands yet can still publish locations. Our OCPP and OCPI guide walks through the same split in more detail.

OCPP and OCPI solve different links, which is why both names show up in EV charging app development briefs. OCPP (Open Charge Point Protocol) is the charger talking to your backend: I am online, the connector is preparing, start this transaction, here are the meter values, stop. If that link is down, the hardware may still deliver energy under its local rules, but your app cannot see it and should not pretend the pin is live.

OCPI (Open Charge Point Interface) is your company talking to another company. It answers: here are my public locations, here is the price, this token belongs to your driver, this session happened, this CDR is what we will settle. OCPI does not replace OCPP. A charge point operator still needs OCPP, or a vendor cloud that speaks OCPP, to control its own chargers. An eMSP that owns no chargers may only need OCPI, plus a driver app. Putting both protocols in one sentence on a sales slide does not make them one integration.

The CPO CMS and the eMSP platform above share one charging management system, and the records stay separate. A station, a driver token, and a session are not the same table. The CPO side holds the OCPP connection, site tariffs, and the fault ticket. The eMSP side holds the driver account, the payment method, and the invoice the driver receives. Many networks start as one role.

We keep the roles in the data model even when the first release has a single brand. A driver, a token, a session, and a station should not be the same table. If you later roam, the eMSP side already knows how to hold a token that is not tied to a charger you own, and the CPO side already knows how to accept a token that did not originate in your app. That is a structure choice on day one, not a rewrite on day two hundred.

The driver mobile app is the map, the session, and the receipt. On iOS and Android we show chargers the backend actually knows about, with filters a driver uses in India: connector, power band, and whether the connector is available. A pin without a fresh status is labeled from the last heartbeat, not drawn as free. Navigation hands off to the maps app the phone already has. We do not invent a traffic layer.

Start can be an in-app remote start, a QR code that identifies the connector, or an RFID card the charger authorizes through OCPP. Reservation is included only when that charger implements it. Many 1.6J units do not. Payments are UPI, cards, or an in-app balance through a gateway you contract. We integrate the gateway. We are not the payment company, and we do not hold a prepaid-instrument licence for you. If a stored balance can be withdrawn or spent outside charging, your counsel confirms the RBI position before we shape that wallet. Screen flows are designed with the same care as our UI/UX work, and the store builds follow mobile app development.

The admin and operator dashboard is a web app, not a stretched phone screen. Dispatch sees which connectors are faulted. Finance sees which sessions have a CDR and which payments are still open. A site host, such as a mall or hotel, can be limited to its own locations. Head office sees the network. Those are roles, not three products.

We put actions the protocol supports on the charger page: remote start, remote stop, reset when the charger implements it, and a configuration change that is logged. An action the firmware does not support is hidden, not shown as a button that fails in front of a customer. Exports cover sessions and invoices for the accountant. The dashboard does not replace your books.

Load management and smart charging keep a site inside the power the electrical design allows. The input is a limit your electrician or facility team states for a panel, a feeder, or a site. The backend watches active sessions and sends an OCPP charging profile, on 1.6J via SetChargingProfile where the charger supports it, so the sum of connector limits stays under that cap. If a charger ignores profiles, we say so in the hardware test. We do not pretend a software slider can exceed the breaker.

Smart charging here is not a promise of grid-market trading. Utility demand-response APIs are a separate integration, in scope only when you have that contract and a document we can read. For a building, the useful version is quieter: pause or slow the sessions that can wait, and leave a session alone when the driver or the fleet rule says it cannot wait. The rule is written down. It is not a hidden score.

OCPP-compliant hardware integration means the charger speaks OCPP 1.6J or 2.0.1 closely enough to boot, authorize, meter, and stop. Brand names are not a compatibility list. Two units from the same manufacturer can ship different firmware. We ask for the model, the OCPP version, and a way to reach one physical charger or a vendor simulator that matches that firmware. The test is a script: boot, heartbeat, authorize, start, meter values, stop, and the remote commands you need on day one.

Connectors are a separate question from the protocol. Newer car chargers in India commonly use Type 2 for AC and CCS2 for DC. Older public sites may still use Bharat AC-001 or Bharat DC-001. AC-001 is a public AC specification with three 230 V outputs, about 3.3 kW each, and IEC 60309 connectors. DC-001 is the low-voltage DC specification for packs around 48 V, 60 V, and 72 V, on the order of 15 kW, with OCPP toward the management system on chargers built to that spec. We show the connector the hardware reports. We do not draw a CCS2 pin on a Bharat AC outlet. Charger connectivity is the IoT part of this work. It lives on this page, not on a separate IoT product.

Billing starts from a tariff a person can explain. Elements we model are energy (per kWh), time (per minute while charging), a fixed fee per session, and an idle fee after charging finishes while the vehicle still occupies the connector. A site can have more than one tariff by time of day. The price the driver saw at start is the price the receipt uses, unless you have written a different rule. OCPI's tariff module is how that price is published to a roaming partner. It is not a second, secret price.

GST invoicing means the document can carry your GSTIN, place of supply, SAC, taxable value, and the tax breakup your accountant specifies. We do not choose your tax rate, and we do not file returns. The operator remains responsible for registration and filing. Settlements to a site host, such as a hotel or a mall, are a split you define in the contract. The software records the split. It does not replace the contract. The published starting range for an MVP is on the pricing page. It is not a tariff for electricity.

Fleet charging is a depot problem more often than a public-map problem. The vehicles are known, the site is private or shared with a landlord, and the question is which vehicle must leave at which time. We attach an RFID or a vehicle record to the session so energy is reported per vehicle, not only per connector. A dispatcher can mark a departure priority. Load management then prefers the bus or van that has to move, and slows the one that can wait, within the panel limit.

A fleet can still use the same CPMS as a public site. Public pins are simply not published for the depot, or they are published only for the bays you mark public. Drivers of pool cars can use the same app with a group that does not see public prices. We do not assume a fleet wants OCPI on day one. Roaming can wait until a vehicle charges away from the depot.

A white-label EV charging CMS is your name on the store listing, your colors, your support address, and your domain on the dashboard. The protocol behavior does not change because the logo did. We still need to know whose chargers, whose payment gateway, and whose GSTIN appear on the invoice. White-label is a brand and release choice. It is not a shortcut around OCPP testing.

Agencies that want us to build under their client relationship can also use the white-label development engagement. On this page the product is the charging stack. You receive the repositories for the app and the backend that the scope names. We do not keep a hidden production lock. App Store and Play policies still apply to the legal entity that publishes the app.

ISO 15118 is the standard for communication between the vehicle and the charger. Plug & Charge is the use case where the car presents a contract certificate and the session can start without an app tap or an RFID card, when the car, the charger, and a certificate ecosystem all support it. OCPP 2.0.1 is the backend path that carries those exchanges more completely than 1.6J. Readiness means we leave a place in the data model for contracts and certificate status, and we do not paint the product into a corner that only understands an app token.

Readiness is not a live Plug & Charge network. We do not operate a vehicle-to-grid public-key infrastructure, and we do not claim your current cars will plug in and start with no other step. That depends on the vehicle, the charger firmware, and a contract certificate you are entitled to issue or buy. When those three exist, the OCPP 2.0.1 work in the scope is what we connect. Until they exist, drivers start with the app, QR, or RFID.

Analytics on an EV network are operational, not a vanity dashboard. The figures that change a decision are sessions started, sessions that delivered energy, kWh by site and connector, time a connector was faulted, and revenue by tariff. Uptime is derived from heartbeats and status notifications. If a charger stops sending heartbeats, the chart should show a gap, not a flat healthy line.

We do not publish benchmark percentages for your network before it exists, and we do not invent an industry average on this page. Filters cover site, connector, and day. Exports exist so finance can reconcile payments outside the tool. A map of India with guessed demand is not an analytics feature. If you later want a model on top of real session history, that is a separate custom software conversation with the data you actually have.

India context shows up in the connector list, the payment method, and the invoice, not in a stock photo of a city. Public and fleet sites here are a mix. Cars increasingly charge on Type 2 and CCS2. Two-wheelers and three-wheelers still meet Bharat AC-001 and Bharat DC-001 equipment. The app has to filter on the connector the vehicle can use. A car driver should not be sent to a low-voltage DC bay. A two-wheeler rider should not be sent only to a CCS2 gun.

Payments in India mean UPI is a first-class option next to cards, through a gateway you contract. Invoices need GST fields, as described in the billing section. We do not quote a government station count, a subsidy, or a tax rate on this page. Those change, and they are not our product. The team that builds the software is in Jaipur. Delivery is remote for the rest of India and for teams outside India. Your charger still has to be reachable by the backend, wherever the site is.

Charge point operators come when a vendor cloud is too closed, or when several charger brands must sit in one CPMS. eMSPs come when they want a driver app and OCPI onto networks they do not own. Fleets come for a depot view, vehicle identity, and departure priority. The software is the same family of components. The first release is not.

Real estate and malls usually host chargers rather than become a national eMSP. They need a site-level dashboard, a way for visitors to pay, and a settlement note for the operator or the brand on the charger. Hotels are similar, with the extra question of whether a stay should charge a room folio or a direct UPI payment. Startups come for a white-label product they can put in market under their own name. We will say if the brief is only a marketing site. That work belongs on website development, not here.

Cost follows scope. A driver app on one existing network is smaller than a CPMS plus OCPP for several charger models plus OCPI with more than one partner. Other factors are iOS and Android together, an operator dashboard, UPI and cards, GST invoice depth, fleet rules, load management, white-label store releases, and whether ISO 15118 readiness is in the first phase or later. Hardware you cannot reach, or a vendor cloud that will not expose OCPP, adds time we cannot compress with more screens.

The pricing page publishes a starting range of ₹4,50,000, ex-GST, after discovery. The label on that page is an eMSP or CPO MVP with live maps, charging sessions, and OCPP/OCPI. That figure is a starting range, not a package you can order unchanged. Our technical guide describes a first CSMS and driver app, a handful of charger models, and one payment method as often 10 to 14 weeks once access and hardware are ready. An eMSP app without owned chargers can be shorter. A multi-model rollout plus roaming is longer. We do not lock a week count in the first email.

OCPP and OCPI software for Indian CPOs and eMSPs, from ₹4,50,000. Live product proof: PlugOne. See custom software when the product still needs building around the CSMS; Android when drivers need a Play Store client.

The pricing page lists a starting range of ₹4,50,000 ex-GST for an MVP (Basic), with Standard ₹9,00,000 and Premium ₹18,00,000. This page does not sell a per-charger monthly SaaS menu. White-label vs build-vs-buy notes: build vs buy a CSMS and CMS cost guide.

OCPP is the Open Charge Alliance protocol between charger and CMS. OCPI is the roaming protocol between eMSPs and CPOs. UPI is NPCI. GST invoices are Indian tax documents, not a protocol. Charger OEM names we have tested are not listed in this repo, so they are not invented here.

PlugOne is a live EV charging product (driver app + CMS). Charger counts, session counts and uptime are not in this repo. Case: PlugOne portfolio. Protocol explainer: OCPP/OCPI guide.

Named people on the team page: Ashutosh and Karan, mobile developers; Anjali and Ajay, back-end developers; Manvender, Project Manager. Office: 5th Floor, Amoro Building, Patrakar Colony, Jaipur, Rajasthan 302020 · +91 63781 33780 · Mon–Sat 10 AM–7 PM IST.