NIT No: 06/PR/BSPGCL/2026

Sl. No. Query Query Details Query Answer

1 Estimated Project Cost: Kindly confirm the estimated project cost/budget for the work covered under this RFP, if available. Approx Rs. 11 Lacs

2 Indicative RMS/System Quantity: Kindly provide the indicative total number of RMS/systems expected to be integrated under the contract, along with the approximate breakup of System-1 (up to 100 parameters), System-2 (up to 200 parameters) and System-3 (up to 300 parameters). Kindly also confirm whether any minimum quantity is envisaged/assured. Maximum 175

3 Definition of Billable System/RMS: Kindly clarify what constitutes one billable “System/RMS” for commercial purposes. Where one physical RMS identified by a unique IMEI communicates data for multiple Virtual Devices such as inverter, meter, DAQ, controller, etc., whether the same will be considered as one billable system or multiple systems. as per RFP

4 Parameter Classification: Kindly clarify the methodology for determining the 100/200/300 parameter categories, including whether the parameter count will cover only monitoring/Hard Tags or also Soft Tags, archived parameters, alarms/events and parameters of all Virtual Devices connected through the RMS. Kindly also clarify the treatment of systems exceeding 300 parameters. as per RFP

5 Financial Evaluation / L1 Methodology: Since the Financial Bid specifies Qty. “1” against each System-1/System-2/System-3 item, kindly clarify whether financial evaluation/L1 determination will be based on the simple total of all quoted unit rates or whether any indicative quantities/weightages will be applied. Simple Total

6 PM-KUSUM Components Covered: Kindly confirm whether the commercial scope under this RFP is limited to PM-KUSUM Component-C / Feeder Level Solarisation, or whether Components A and B are also proposed to be covered under the same contract. Component-C

Ellume Technology

Sl NO. NIT Clause NIT Reference Bidders Query BSPGCL Response

1+A3:A7 Clause 2.3 (Exclusions) read with Clause 9 and Clause 8, Pages 8, 15–20 RMS hardware supply, installation, testing and commissioning is excluded from the Bidder’s scope, yet the Bidder’s platform "must be fully compatible with, and capable of integrating, RMS devices" and must implement the MNRE communication and security architecture "exactly as specifi ed". The tender proceeds on an implied assumption that every RMS/DCU already installed (or to be installed) in the field is natively capable of MQTT publication over TLS 1.2+, X.509 client-certificate authentication, the prescribed topic structure, OTP handshake, heartbeat, on-demand read/write and configuration-over-the-air, in the exact JSON schemas of Annexures 1–7. BSPGCL is requested to confi rm in writing that all such devices are so certifi ed, and to furnish the conformance / type-test certifi cates. Further, BSPGCL is requested to expressly confi rm that where any installed device is found NON-COMPLIANT with the MNRE communication architecture, the entire responsibility, cost and time for making that device compliant (fi rmware upgrade, communication module replacement, certifi cate installation, re-commissioning) rests solely with the RMS supplier / empanelled agency, and NOT with the Bidder. till RMS part, it is in scope of Solar Power Developers

2 Clause 8.2 (RMS Registration Process), Page 16 The State platform generates an individual X.509 client certifi cate per IMEI, shared with the vendor through a secured web API; on expiry the RMS connects to the FTP server and downloads the renewed certifi cate. This process presupposes that the deployed firmware supports (i) installation of a device-specific X.509 client certificate, (ii) an FTP client for certificate renewal, and (iii) remote reconfiguration of broker URL/credentials. BSPGCL is requested to confirm the above capability exists in every deployed model, and to confirm that field visits, firmware flashing, on-site certificate installation, SIM/APN reconfiguration and any physical intervention at site are outside the Bidder’s scope. Where a device fails to connect for any of these reasons, no penalty or SLA deduction shall apply to the Bidder. as per RFP

3 Clause 2.2, 4.2 and Clause 16 / Annexure-9, Pages 7, 8, 29, 30 The Bidder is required to integrate "the various RMS devices installed in the fi eld" and to quote unit rates per system, but no inventory of the installed base is provided. BSPGCL is requested to disclose, as a corrigendum, the inventory of RMS/DCU devices to be integrated — make, model, fi rmware version, quantity, communication module, SIM/APN provider, protocol presently in use, and whether each model is MQTT/TLS-capable — substation-wise and connection-wise. In the absence of this inventory the integration effort, remediation risk and cloud sizing cannot be estimated, and any rate quoted will necessarily be qualifi ed. Bidders cannot price an unknown legacy estate at a fi xed unit rate for an 8-year rate contract. Ans. - Maximum 200 RMS/DCU Devices will be integrated at present, further it may be increased.

Clause 8.3, 8.4, 8.5, 8.6 read with Clause 2.3, Pages 8, 16–18 MQTT over a private TLS/SSL VPN with prescribed topics and JSON message structure is mandated as the only RMS-to-server communication method. A material part of the RMS population presently deployed under PM-KUSUM in various States communicates over HTTP/HTTPS REST, FTP push, proprietary TCP or SMS only, and does not support MQTT at all. Where a device cannot publish in the prescribed MQTT/JSON format, BSPGCL is requested to specify which of the following shall apply: (a) BSPGCL/DISCOM shall direct the empanelled agency to upgrade the device at the agency’s cost, with the integration clock held in abeyance; (b) the Bidder shall be permitted to deploy a protocol-translation gateway / adapter / middleware layer, for which a separate payable line item shall be introduced in the price bid on a per make-model basis; or (c) the device shall be excluded from the order and from all SLA computation. A defi ned written procedure is requested. Ans. - Only in prescribed MQTT/JSON message fromats as required by MNE.

4 New clause requested (Clause 4.2 / 4.3 / 13), Pages 8, 24 Integration timelines run from the date of e-mail intimation, with penalty for delay and SLA deductions for availability. The Bidder requests insertion of a "Device Conformance" clause to the following effect: "Where a device fails the Device Conformance Test, the integration timeline under Clause 4.2, the penalty under Clause 4.3 and the SLA computation under Clause 13 shall stand suspended in respect of that device until the device is certifi ed compliant with the MNRE communication architecture by its supplier, and such device shall be excluded from the denominator for all availability, % device connectivity and % data availability computations." Kindly confi rm acceptance. Ans. - Penalty and decuction will be charged as per NIT Clause 4.2, 4.3 & 13.

5 Clause 4.2, Page 8 Integration to be completed in 2–4 days computed "from the date of e-mail intimation from BSPGCL/DISCOM (subject to the CSV device list uploaded by the respective installer)". It is requested that the integration clock commence not from e-mail intimation but from the date the device passes a documented Device Conformance Test — i.e. successful TLS handshake with a valid client certifi cate and receipt of a schema-valid JSON payload for every mandated Virtual Device. Kindly clarify who conducts and certifi es this test, in what format, and confi rm the timeline is computed only on conformant devices supported by a complete and validated CSV. Ans. - After date of integration, e-mail intimation will be send to the Bidder it means both are same

Clause 2.3, 8.5, 9.3, Pages 8, 17, 19 Interoperability "irrespective of make/manufacturer" over RS485 MODBUS RTU is assumed. MODBUS RTU is not a self-describing protocol; integration is impossible without the OEM register map of each inverter, string combiner box, plant controller and drive. BSPGCL is requested to confi rm that (i) OEM register maps, JSON payload samples, fi rmware documentation and OEM engineering support will be procured and furnished by BSPGCL/DISCOM/empanelled agency free of cost to the Bidder, (ii) such obligation is made back-to-back and enforceable in the empanelled agencies’ own contracts, and (iii) time taken to obtain the same is an excusable delay excluded from Clause 4.2 and 4.3. Ans. - Developer wil provide necessary arrangements to integrate the data.

6 Clause 6.2.1 and 9.2, Pages 10, 19 The substation-end RMS must monitor weather parameters (irradiation, temperature, wind speed) required for %PR calculation, feeder ON/OFF/TRIP status via digital inputs, and the bi-directional meter at the 11kV/33kV bus. Kindly confi rm that weather sensors (pyranometer, module and ambient temperature, anemometer), digital input wiring for feeder status and the bi-directional bus meter are in fact installed, wired and functional at every substation-end plant. Where any such instrument is absent, not wired or faulty, kindly confi rm that the Bidder is not responsible for non-availability of the dependent hard tags, soft tags, %PR and derived reports, and that such parameters are excluded from % data availability and SLA computation. Ans. - In that case such parameters are excluded from % data availibility and SLA Computation

7 Clause 7.5, 8.5, 9.1, Pages 13, 17, 19 Energy meter communication over DLMS or Modbus; MDAS/MDM covering instantaneous data, billing history, load survey and tamper data. Kindly furnish the list of meter makes, models and fi rmware versions installed (bi-directional grid interface meters and solar generation audit meters), and confi rm that DLMS HLS security keys/passwords, OBIS mapping and any meter-OEM licence or protocol documentation charges shall be provided/borne by BSPGCL/DISCOM. Non-availability or delayed provision of meter keys must be treated as an excusable delay, since DLMS data cannot be read without them. Ans. - ABT Meter shall be installed by solar power developers ( 2 meters at PSS end and 1 meter at Plant end. So far 11 plants have been commissioned which have installed Secure APEX 100 models) and further details will be provided to succesful bidder.

Clause 7.1, 7.2, 8.4, Pages 12, 16 The platform must support SMS-based periodic data, on-demand read/write and confi guration update as a fallback channel; Clause 2.3 excludes SMS gateway subscription charges from scope with the note "There should be provision in Software." (a) A large proportion of deployed RMS fi rmware does not support SMS-mode command parsing. Kindly confi rm whether the SMS fallback channel is to be demonstrated only at platform level (software provision) and whether inability of fi eld hardware to support SMS shall not be held against the Bidder. (b) Kindly confi rm that procurement of the SMS gateway, DLT/sender-ID registration, transactional SMS credits and e-mail relay volumes are BSPGCL’s responsibility and cost, and that the Bidder’s obligation is limited to API integration. Ans. - Bulk SMS charges will be carried by BSPGCL

8 Clause 7.1 (OTP confi guration), 8.1, 8.4, Pages 11, 15, 17 Auto-generation and exchange of a 32-character random OTP subscription topic at 15/30/60-minute intervals; confi guration-over-the-air; topic-level authorisation. Kindly confi rm that the deployed RMS fi rmware implements OTP rotation, dual POTP/COTP handling and confi guration-over-the-air exactly as per Annexure-1. Where a device does not, kindly confi rm whether the Bidder may (i) operate that device in a defi ned degraded/exception mode without penalty, or (ii) reject the device from integration, and confi rm which of the two BSPGCL prefers. The security architecture cannot be enforced unilaterally from the server side. as per MNRE Communication Architecture Guideline

9 Clause 7.9, Page 15 The Bidder shall integrate the platform data with "the existing State-level as well as National-level" SEDM Platform. This suggests an existing Bihar State-level portal already in operation, while the balance of the tender requires a new State portal to be designed and developed. Kindly clarify: (a) whether an existing State portal or agency-hosted RMS portal exists, and if so its vendor, technology and data volume; (b) whether migration of historical data is within scope, and if so, the period, volume and format of data to be migrated; (c) whether such migration is payable separately, as it is not provided for in the price bid. (a) No, there is not an existing State portal. Bidders need to develop, deploy and integrate it with the RMS/ DCU and MNRE portal (b) yes migration of historical data is within scope of Bidder (c) No, such migration is not payable separately.

Clause 11.2, Page 22 Updating SCADA confi guration in case of device/meter replacement is included within Remote Software Maintenance Services. Kindly clarify whether re-provisioning and re-confi guration of a replaced RMS or meter (fresh certifi cate, credentials, topics, tags, archiving and event confi guration — i.e. the full Clause 10 activity set) is covered within the original per-device unit rate, or is payable as a fresh device confi guration. If covered within the unit rate, kindly specify a cap on the number of free re-confi gurations per device per annum, beyond which the Clause 16 Item-1 rate shall apply. Ans. - As per NIT

10 Clause 16 / Annexure-9 (Price Bid), Pages 29, 30, 44 The price bid contains only four items — SITC/confi guration, O&M Part-1, O&M Part-2 and cloud hosting. There is no line item for hardware remediation, protocol adaptation, middleware development or fi eld support. Since the commercial structure provides no mechanism to recover the cost of making a non-conformant fi eld estate integrable, kindly confi rm one of the following: (a) BSPGCL will issue such work, if required, as a separate variation order at rates to be mutually agreed; (b) bidders may quote an optional item (not loaded for evaluation) for protocol adaptation per non-standard make-model; or (c) BSPGCL confi rms unconditionally that no such work will arise because every device is pre-certifi ed conformant. Absent one of these, all bids will carry an implicit unquantifi ed risk premium. Ans. - As per NIT

Virtuoso Consulting & Technology

SL No. Query Suggested Action / Change Bid Section & Page Reference BSPGCL Response

1 Security Architecture – How will OTP exchange be synchronized across thousands of RMS devices? Propose automated OTP refresh via secure broker with redundancy to avoid sync failures. Annex.6 Communication Architecture, Sec.1, Pg.2 As per MNRE Communication Architecture Guidelines

2 RMS Registration – What is the renewal cycle for client certificates and how will expired certificates be managed? Suggest automated certificate renewal alerts + fallback FTP mechanism with monitoring. Annex.6 Communication Architecture, Sec.2, Pg.3

3 MQTT Topic Structure – Will topic authorization scale for 10,000+ devices? Recommend hierarchical topic authorization with role‑based access. Annex.6 Communication Architecture, Sec.3, Pg.3

4 Communication Modes – How will missing data indices be reconciled during push mode? Propose automated backfill mechanism with priority queues. Annex.6 Communication Architecture, Sec.4, Pg.4

5 Protocols – DLMS/Modbus interoperability across vendors needs validation. Suggest vendor‑agnostic compliance testing before rollout. Annex.6 Communication Architecture, Sec.5, Pg.4

6 Message Structure – How will MSGID be tracked for ondemand/config messages? Recommend centralized transaction ID repository for audit. Annex.6 Communication Architecture, Sec.6, Pg.5

7 Proof of Concept – Will BSPGCL provide test RMS devices or only virtual clients? Request clarity; propose hybrid POC with both virtual and real RMS. BSPGCL RFP NIT06, Sec.3, Pg.7–8 No, BSPGCL would not provide any test RMS devices or any virtual clients.

8 Integration Timeline – Penalty clause Rs.10/day/system seems harsh for large batches. Suggest grace period for >100 systems integration. BSPGCL RFP NIT06, Sec.4.2, Pg.8 Penalty applicable as per clause mentioned in RFP.

9 Go‑Live Acceptance – What exact reports/dashboards are mandatory at acceptance? Propose phased acceptance: device connectivity first, dashboards later. BSPGCL RFP NIT06, Sec.5, Pg.9 As per RFP

10 System Architecture – How will sub‑station and plant‑end data be logically grouped? Recommend feeder‑plant mapping schema in SCADA DB. BSPGCL RFP NIT06, Sec.6.2, Pg.9–10 As per MNRE Communication architecure guidelines

11 Device Management – Will IMEI/MAC ID be sufficient for unique identification? Suggest dual ID (IMEI + Serial No.) for redundancy. MNRE Model Guidelines, Device Management, Pg.24

12 SCADA Tag Processing – How will missing data be backfilled? Propose BOT‑based backfill with configurable priority. MNRE Model Guidelines, SCADA Tag Processing, Pg.25

13 Events & Notifications – What is escalation timeline for alarms? Suggest SLA‑based escalation (Vendor 24h, Farmer 72h). MNRE Model Guidelines, Events & Notifications, Pg.26

14 RMS Specifications – Will RMS hardware be supplied by empanelled vendors or bidder? Confirm exclusion; bidder only supplies SCADA software. RMS Specifications Annex.7, Pg.4–7 procurement and installations of RMS is in scope of Solar Power Developers.

15 1000 Endpoints – Can the SCADA/MQTT broker handle 1000+ concurrent endpoints reliably? Request confirmation of scalability tests; propose cluster‑based broker deployment. BSPGCL RFP NIT06, Sec.7.1 Device Management, Pg.10

16 Tender Fees & EMD – Can fees/EMD be submitted fully online without physical BG submission? Request acceptance of e‑BG or digital guarantee. BSPGCL Tender Notice, Pg.1–2 Fees/EMD can be submitted online.

17 Bidder Eligibility – Are consortium bids allowed (IT + Solar integrator)? Suggest consortium participation to widen competition. BSPGCL RFP NIT06, Preface/Background, Pg.6 consortium may be considered.

18 O&M Scope – Will cloud hosting charges be reimbursed separately or bundled? Propose separate line item for hosting charges. BSPGCL RFP NIT06, Scope of Work, Pg.7 cloud hosting charges should be separately provided

19 Penalty Clause – Is penalty capped at 10% of order value? Request clarification and possible reduction. BSPGCL RFP NIT06, Sec.4.3, Pg.8 Yes, penalty capped is capped at 10% of order value.

20 RDSS Smart Meters as Experience – Can projects involving deployment of smart meters under RDSS (with MDAS/MDM integration) be considered valid experience for the “1000 Energy Monitoring Devices” requirement? Request explicit confirmation that RDSS smart meter rollouts qualify, since they meet MDAS/SCADA integration and remote operation criteria. BSPGCL RFP NIT06, Technical Experience Clause, Pg.6 May be Considered

21 Location Specifics – Can BSPGCL provide a district/substation‑wise list of RMS integration sites? Request detailed site list to estimate logistics and manpower. BSPGCL RFP NIT06, Scope of Work, Pg.7 Provided to Suceesful Bidder.

22 Payment Milestones – What is the payment schedule for 5‑year O&M and cloud hosting? Propose annual milestone payments with separate line item for hosting. BSPGCL RFP NIT06, Scope of Work, Pg.7 As per RFP.

23 EMD Submission – Can EMD be submitted via e‑BG instead of physical BG/DD? Request acceptance of e‑BG to align with e‑procurement norms. BSPGCL Tender Notice, Pg.1–2 As per RFP.