509-26 Automated Fuel Management System

The Ohio Department of Transportation (ODOT) plans to implement an automated fuel management system which uses current technologies including web-based software and network capable hardware. Currently ODOT has approximately 190 Fueling locations statewide with pump islands ranging from 1 to 4 pumps. Fuel types currently used by ODOT include diesel, gas (including aviation grades), kerosene, nearly all pumps are unleaded or diesel. ODOT provides fuel for department vehicles and equipment. Vehicle types include pickups, service trucks, airplanes, vans, SUVs and construction equipment. The Division of Aviation within ODOT has 2 Fueling Tankers. ODOT has above ground fuel tanks.
OhioBuys training materials can be located at this site: https://procure.ohio.gov/bidders-and-suppliers/resources/Bidder+and+Supplier+Training/02_OB+training
Fleet management services
Inquiries Inquiry 88791 | When accessing link, I receive a 'page not found.' Can that document be provided some other way? | Answer: Attachment one (1) has been removed from the RFP document. A new solicitation round will go out with the updated RFP document. | Answered: 5/11/2026 Inquiry 89714 | Dispensers: 1.) What make and model of fuel dispensers are installed? 2.) How many hoses per dispenser? 3.) Which fuel products are dispensed, per dispenser? 4.) Are the dispensers mechanical or electronic? 5.) Are the fuel dispensers suction or remote units? Fuel Management System (FMS): 6.) Which software package(s) will the new fuel management system be required to interface with (e.g. vehicle maintenance management software)? 7.) How will the user/driver authorize the transaction (e.g. employee HID card, fob, card, PIN number)? 8.) Does the user/driver manually enter information into the FMS system? If so, what data (mileage, hours, vehicle number, etc.)? 9.) Please provide a listing of the vehicles and drivers that will be using the system. If unable to provide a detailed list, how many vehicles and drivers? 10.) Do the vehicles have transponders on the fill? 11.) Do the vehicles have transponders to automatically authorize the vehicle when it approaches the fuel island? 12.) Is information from the onboard diagnostic computer communicated to the FMS system? 13.) Per site, how many fuel management terminals are present? 14.) What reporting is required from the fuel management system? 15.) How will the fuel management island terminal communicate to the office and/or cloud (e.g. hardwired from fuel island to office, cellular)? | Answer: Dispensers: 1.) What make and model of fuel dispensers are installed? This may vary depending on the site. 2.) How many hoses per dispenser? Either one or two 3.) Which fuel products are dispensed, per dispenser? Either unleaded or diesel 4.) Are the dispensers mechanical or electronic? Mechanical 5.) Are the fuel dispensers suction or remote units? They could be either, depending on the site. Fuel Management System (FMS): 6.) Which software package(s) will the new fuel management system be required to interface with (e.g. vehicle maintenance management software)? Receive user ID from S2 security system, receive vehicle ID from and export transaction data to Agile Assets (ODOT’s EIMS fleet management system) 7.) How will the user/driver authorize the transaction (e.g. employee HID card, fob, card, PIN number)? Proximity ID badge 8.) Does the user/driver manually enter information into the FMS system? If so, what data (mileage, hours, vehicle number, etc.)? This is not the preferred method, but the proposed system must accommodate keypad inputs: User ID, Vehicle ID, mileage, hours, pump number. 9.) Please provide a listing of the vehicles and drivers that will be using the system. If unable to provide a detailed list, how many vehicles and drivers? Approximately 5000 users and 15000 vehicles and equipment. 10.) Do the vehicles have transponders on the fill? No 11.) Do the vehicles have transponders to automatically authorize the vehicle when it approaches the fuel island? No 12.) Is information from the onboard diagnostic computer communicated to the FMS system? FuelMaster captures OBD data, but not transferred to EIMS. 13.) Per site, how many fuel management terminals are present? One per site, except ODOT Office of Aviation site has two fuel trucks. 14.) What reporting is required from the fuel management system? At minimum: date. time, User ID, Vehicle ID, license tag #, mileage, hours, fuel type, pump #, hose #, transaction type (automatic or manual). 15.) How will the fuel management island terminal communicate to the office and/or cloud (e.g. hardwired from fuel island to office, cellular)? This may be either depending on the site. | Answered: 5/21/2026 Inquiry 89786 | Regarding A high-level project plan detailing how the Proposer will implement the proposed system addressing, at a minimum, the project tasks and deliverables described in Section 10. Can you elaborate on where to find section 10? | Answer: We are looking for a professional project plan on how the system will be implemented with locations, tasks, due dates and deliverables for the project. The information is in Section 11, not Section 10 | Answered: 5/22/2026 Inquiry 89789 | 1) can the cell-modems have their SIMs swapped to be registered on our private APN?2) If they can't, can the existing cellular hardware allow inbound ssh traffic over port 20 and outbound port 443 and our WebSocket ports at 8000? | Answer: 1) can the cell-modems have their SIMs swapped to be registered on our private APN? FROM IT: No. ODOT will be using our current hardwired sites on our internal LAN/WAN as well as our own private APN cellular solution at sites that are not hardwired.2) If they can't, can the existing cellular hardware allow inbound ssh traffic over port 20 and outbound port 443 and our WebSocket ports at 8000? FROM IT: No, we will not be allowing inbound traffic directly to modems. Outbound connections will be at our discretion. | Answered: 5/22/2026 Inquiry 89792 | Given the complexity of the RFP requirements and the volume of pre-proposal questions submitted, will ODOT consider extending the bid submission deadline beyond May 27, 2026 to allow vendors adequate time to incorporate responses to pre-proposal inquiries into their proposals? What is the budget for this project? Is there a detailed site list of all the locations? What is the current fleet maintenance software being used? How many vehicles in ODOT's fleet are equipped with On-Board Diagnostic (OBD) capability, and can ODOT provide a breakdown by vehicle type? can ODOT provide details on what specific data fields and frequency of exchange are required for the EIMS interface integration? can ODOT provide details on what specific data fields are required for the Veeder-Root integration and how many sites currently have Veeder-Root systems installed? What is Gap in current Automated Fuel Management System that you would like to solve in the new system? Do you currently have capability to integrate with the vehicle On Board Diagnostic (OBD) to enable capture of mileage, diagnostic codes and other vehicle information? If so, please explain how the process works. Do you currently have the ability for display vehicle information such as diagnostic code warnings to the vehicle operator via the Fueling Terminal display while fueling? If so, please describe the process. Please elaborate on what you mean by- “The system must support the ability for an authorized user to view the connectivity status of connected components in a system status type reporting environment.” Please provide details on what legacy data must be converted and for how many months/years- “The system solution shall include conversion and loading of legacy data. (To be performed by the contractor)” Please provide context on external hardware or software noted in this requirement for API integration and at what frequency- “The system shall include the ability to interface and exchange data with external hardware or software such as ODOT’s Equipment, Inventory & Parts Management System (EIMS), with a preference for a direct API connection. This will be at the cost of the contractor and approved by ODOT IT.” Do you currently receive Idle Time when the fuel is dispensed to the vehicle? If so, please provide context. Please provide make, model, and type of EV Chargers ODOT currently has in use in order for compliance with requirement – “The system shall accommodate all fuel types used by ODOT including but not limited to diesel, gas (including Aviation grades), kerosene, and accommodate EV charging transactions.” Do you currently have this feature and if so please provide context on process- “The system shall calculate any variance between the quantity of fuel on hand in the system (Veeder-Root or equivalent) and the manual stick reading for a tank.” Do you currently have a system to accommodate this requirement and if so please describe the process- “The system shall provide the ability to transfer fuel to a portable fuel storage device and wirelessly track fuel usage from the fuel storage device to the equipment consuming the fuel.“ Is this in place now and if so please describe the process- “The system shall have the capability to integrate with the vehicle On Board Diagnostic (OBD) to enable capture of mileage, diagnostic codes and other vehicle performance information.” Please provide examples of the 20 custom Canned reports noted in this requirement- “The system shall accommodate the generation of ‘Canned’ reports including cost per mile, mileage, idle time report, and fuel usage. 20 custom Canned reports shall be required.” Does ODOT currently have dashboard for key indicators listed in this requirement and if so please describe dashboard- “The system shall provide Dashboards showing Key Performance Indicators. E.g. Fuel usage by organization level, Fuel consumption by vehicle type, Idle time by organization level and user etc” Please provide context on in vehicle components noted in this requirement- “The system shall allow for wireless transmission for in vehicle components. (No wires in vehicle are preferred)” Do you currently have this in place and if so please provide context- “The system shall provide a method to obtain vehicle mileage (or hour) data from pre-1996 vehicles.” Do you currently have this in place and if so please provide context on this requirement – “The system should support the update of multiple records in one transaction.” Please provide context on this requirement- “The system shall include transaction auditing.” Is this currently in place and if so please provide context- “The system shall have the ability to work with a mobile fueling tanker with limited or no cellular connectivity.at our Aviation facility. All transaction data will be sync’d when the tanker is near a communication point.” Please describe current connectivity in place if ODOT if on cloud software now or on-premise software now? If on cloud software now, please describe how this requirement is achieved- “Outbound-Initiated Traffic: Preference will be given to solutions where on-premises Fuel Management Units (FMU) utilize outbound-only communication (e.g., HTTPS/TLS) to "call home" to the cloud server, eliminating the need for inbound firewall exceptions.” Please advise if ODOT will be setting up a B2B tunnel to accommodate the following requirements- 6.2.2 Just-In-Time (JIT) Connectivity • No Persistent Access: Permanent or "always-on" inbound remote connections (e.g., persistent VPN tunnels) to on-premises FMUs are strictly prohibited. • Session-Based Authorization: Remote access for maintenance or troubleshooting must be granted on a Just-In-Time (JIT) basis. Connections must be brokered through [Organization Name]’s approved Access Management platform. • MFA Requirement: Multi-Factor Authentication (MFA) is mandatory for every remote session initiated by the vendor. Please provide context on this request – “Repurchase (credit) for existing hardware – specify” | Answer: 1. Given the complexity of the RFP requirements and the volume of pre-proposal questions submitted, will ODOT consider extending the bid submission deadline beyond May 27, 2026 to allow vendors adequate time to incorporate responses to pre-proposal inquiries into their proposals? No more than a week. 2. What is the budget for this project? Not able to answer this. 3. Is there a detailed site list of all the locations? A detailed list is provided. Attached in the RFP 4. What is the current fleet maintenance software being used? Agile Asset (EIMS) 5. How many vehicles in ODOT's fleet are equipped with On-Board Diagnostic (OBD) capability, and can ODOT provide a breakdown by vehicle type? About 5,000 vehicles. This is listed on the pricing page. Vehicle details will be discussed with awarded vendor. 6. can ODOT provide details on what specific data fields and frequency of exchange are required for the EIMS interface integration? Date, Time, Equipment #, Plate #, Employee ID, Employee name, fueling location, fuel amount, fuel type, pump number, miles & hour reading, Transaction type (Manual or automatic) 7. can ODOT provide details on what specific data fields are required for the Veeder-Root integration and how many sites currently have Veeder-Root systems installed? Not able to answer this. 8. What is Gap in current Automated Fuel Management System that you would like to solve in the new system? IT security protocol 9. Do you currently have capability to integrate with the vehicle On Board Diagnostic (OBD) to enable capture of mileage, diagnostic codes and other vehicle information? If so, please explain how the process works. Fuelmaster collects the data but it is not integrated with Agile Assets(EIMS). 10. Do you currently have the ability for display vehicle information such as diagnostic code warnings to the vehicle operator via the Fueling Terminal display while fueling? If so, please describe the process. No 11. Please elaborate on what you mean by- “The system must support the ability for an authorized user to view the connectivity status of connected components in a system status type reporting environment.” FROM IT: We want current connectivity status of the FMUs throughout the state in real time. 12. Please provide details on what legacy data must be converted and for how many months/years- “The system solution shall include conversion and loading of legacy data. (To be performed by the contractor)” FROM IT: I would assume we need to migrate current inventories of equipment and fuel supplies and related information. 13. Please provide context on external hardware or software noted in this requirement for API integration and at what frequency- “The system shall include the ability to interface and exchange data with external hardware or software such as ODOT’s Equipment, Inventory & Parts Management System (EIMS), with a preference for a direct API connection. This will be at the cost of the contractor and approved by ODOT IT.” From IT: Badge data needs to come from S2 and equipment data from EIMS (Agile Assets). API information can be obtained from said vendors. 14. Do you currently receive Idle Time when the fuel is dispensed to the vehicle? If so, please provide context. Yes. Fuelmaster AIMs device has the ability to capture idle time. 15. Please provide make, model, and type of EV Chargers ODOT currently has in use in order for compliance with requirement – “The system shall accommodate all fuel types used by ODOT including but not limited to diesel, gas (including Aviation grades), kerosene, and accommodate EV charging transactions.” Charge point CT4000 & ABB formula.B , 16. Do you currently have this feature and if so please provide context on process- “The system shall calculate any variance between the quantity of fuel on hand in the system (Veeder-Root or equivalent) and the manual stick reading for a tank.” We do not have this feature 17. Do you currently have a system to accommodate this requirement and if so please describe the process- “The system shall provide the ability to transfer fuel to a portable fuel storage device and wirelessly track fuel usage from the fuel storage device to the equipment consuming the fuel.“ Two fueling trucks have a Fuelmaster unit installed on the truck, which records fuel dispensed from the truck to the aircraft. 18. Is this in place now and if so please describe the process- “The system shall have the capability to integrate with the vehicle On Board Diagnostic (OBD) to enable capture of mileage, diagnostic codes and other vehicle performance information.” Yes. The AIMs device captures this information. 19. Please provide examples of the 20 custom Canned reports noted in this requirement- “The system shall accommodate the generation of ‘Canned’ reports including cost per mile, mileage, idle time report, and fuel usage. 20 custom Canned reports shall be required.” FROM IT: Can Equipment Management identify the top 20 reports, once identified IT can package the reports for viewing. 20. Does ODOT currently have dashboard for key indicators listed in this requirement and if so please describe dashboard- “The system shall provide Dashboards showing Key Performance Indicators. E.g. Fuel usage by organization level, Fuel consumption by vehicle type, Idle time by organization level and user etc” No, we do not have a dashboard for this. 21. Please provide context on in vehicle components noted in this requirement- “The system shall allow for wireless transmission for in vehicle components. (No wires in vehicle are preferred)” This requirement needs removed. Redundant to SR6100 22. Do you currently have this in place and if so please provide context- “The system shall provide a method to obtain vehicle mileage (or hour) data from pre-1996 vehicles.” We need to have a way to obtain vehicle data (calculated) from a non-OBD equipped vehicle. 23. Do you currently have this in place and if so please provide context on this requirement – “The system should support the update of multiple records in one transaction.” FROM IT: Multiple locations should have the ability to update the system concurrently. 24. Please provide context on this requirement- “The system shall include transaction auditing.” There needs to be an audit trail of any changes made to fuel transactions within the fuel management system. 25. Is this currently in place and if so please provide context- “The system shall have the ability to work with a mobile fueling tanker with limited or no cellular connectivity.at our Aviation facility. All transaction data will be sync’d when the tanker is near a communication point.” FROM IT: ODOT is looking for a solution which can be installed on our mobile fuel tankers which will connect to the fuel management system via cellular APN like it’s physically connected, with all the same functionality as a physical location. The tankers currently have cellular modems that work fine at the site. 26. Please describe current connectivity in place if ODOT if on cloud software now or on-premise software now? Software is housed on-premise, transaction data is downloaded nightly via cellular or direct ethernet. 27. If on cloud software now, please describe how this requirement is achieved- “Outbound-Initiated Traffic: Preference will be given to solutions where on-premises Fuel Management Units (FMU) utilize outbound-only communication (e.g., HTTPS/TLS) to "call home" to the cloud server, eliminating the need for inbound firewall exceptions.” N/A 28. Please advise if ODOT will be setting up a B2B tunnel to accommodate the following requirements- From IT: It will depend on the solution but we will work with the vendor to allow for connectivity on an as needed basis. a. 6.2.2 Just-In-Time (JIT) Connectivity b. • No Persistent Access: Permanent or "always-on" inbound remote connections (e.g., persistent VPN tunnels) to on-premises FMUs are strictly prohibited. c. • Session-Based Authorization: Remote access for maintenance or troubleshooting must be granted on a Just-In-Time (JIT) basis. Connections must be brokered through [Organization Name]’s approved Access Management platform. d. • MFA Requirement: Multi-Factor Authentication (MFA) is mandatory for every remote session initiated by the vendor. 29. Please provide context on this request – “Repurchase (credit) for existing hardware – specify” If the proposer wants to purchase existing FuelMaster hardware from ODOT, provide unit cost credit amount on the Pricing Page. | Answered: 5/22/2026 Inquiry 89973 | Are the questions asked in this section expected to be part of the proposal response? Or, will they be discussed post award? Specifically, the ones with text boxes included. | Answer: Supplement A must be filled out completely and submitted with your technical proposal. | Answered: 5/27/2026 Inquiry 89976 | The Division of Aviation within ODOT currently operates two fueling tankers – will the Aviation location be included in the same instance as DOT? Or, does Aviation require their own separate, independent instance? | Answer: Please explain what you mean by "instance"? | Answered: 5/27/2026 Inquiry 89979 | Should equipment for the fuel trucks be included as part of the hardware costs? If so, the total unit count would increase from 187 to 189. | Answer: Yes, equipment for the fuel trucks must be included in the hardware costs. | Answered: 5/27/2026 Inquiry 89982 | Is there an updated list of sites that are hardwired vs. wireless vs. cell? | Answer: No, the site list provided is the latest. | Answered: 5/27/2026 Inquiry 90004 | 6The Division of Aviation within ODOT currently operates two fueling tankers – will the Aviation location be included in the same database as DOT? Or, does Aviation require their own separate, independent database? | Answer: 6 | Answered: The Division of Aviation within ODOT currently operates two fueling tankers – will the Aviation location be included in the same database as DOT? Or, does Aviation require their own separate, independent database? Inquiry 6 | The Division of Aviation within ODOT currently operates two fueling tankers – will the Aviation location be included in the same database as DOT? Or, does Aviation require their own separate, independent database? Inquiry 90253 | Does a hard copy need to mailed in to ODOT? | Answer: No. | Answered: 6/1/2026 Inquiry 90262 | 1. Background Can ODOT provide the total number of fueling positions (hose count) throughout the state? 5. Project Location Do each of the 12 districts require separate in-person trainings? 6.2.2 Just-In-Time (JIT) Connectivity What are approved Access Management platforms? 6.2.4 On-Premises Device Communication Does the prohibition of short-range wireless technology apply to telematics devices as well as the on-premises device? Can ODOT provide technical specifications for their GPS platform created in house? 6.5 Cost Proposal Are we allowed to add additional line items in the price spreadsheet for additional offerings in each subcategory? 6.5.3 & 6.5.4 Does this contract fall under the State of Ohio’s prevailing wage requirements? 11. Solution Requirements Applicability of IT Requirements to a SaaS-Delivered Solution Our proposed solution is a multi-tenant SaaS platform hosted in AWS US regions, with no ODOT-resident application servers, databases, or source-controlled artifacts. Many of the IT requirements in the RFP appear to be written against a traditional on-premise / state-hosted deployment model, and we want to confirm, line by line, which ones ODOT intends to enforce against a SaaS delivery.Our reading is that the following requirements do not apply to a SaaS-delivered solution, because the underlying systems are owned, operated, and secured by the vendor under SOC 2 / equivalent third-party attestation rather than installed into the State's environment. Please confirm or, if any of these do apply to SaaS, identify which specific clause and the artifact ODOT expects: Database platform mandates Any requirement to use Oracle, SQL Server, or another State-standard database engine? (Our platform runs on a vendor-managed mix of PostgreSQL and MongoDB inside our AWS tenancy; no database is installed in the State environment.) Data dictionary, table schemas, and physical data model deliverables to the State: Any requirement to provide entity-relationship diagrams, table/column definitions, stored-procedure documentation, or other internal database design artifacts. (Our platform exposes data to ODOT through documented REST APIs and standard export formats; the underlying physical schema is vendor-managed, evolves with platform releases, and is considered proprietary. We can provide API documentation, exported data field definitions, and a logical data model for the data ODOT owns, but not internal table-level schemas.) State-hosted infrastructure / server standards: Windows Server build standards, OS hardening checklists, server patching SLAs, hypervisor / VM standards, backup product mandates, and any State data center hosting clauses. Source code escrow, source code delivery, and "work for hire" code ownership clauses: Written for custom-developed software installed at the State. UI / technology stack mandates: Any clause prescribing a specific front-end framework, .NET version, browser support matrix beyond modern evergreen browsers, or similar implementation-detail requirements. Application code scanning deliverables to the State: SAST, DAST, IAST, SCA / software composition analysis, Veracode/Fortify/Checkmarx reports, or similar code-scan artifacts produced for ODOT review. (Our SDLC includes automated SAST/SCA in CI and we can share executive summary reports under our SOC 2 program; we do not provide raw code-scan output to customers.) Unit-test coverage thresholds: (e.g., 80% line/branch coverage) and direct access to test reports, beyond the quality attestations included in our SOC 2 Type II report. State-administered penetration testing: Of the application/infrastructure, beyond reviewing our SOC 2 program. Direct access to production infrastructure, OS, or database for State administrators, auditors, or DBAs. State change-management / CAB approval for vendor-side platform releases, patching, and dependency updates that do not change the State's contracted functionality or data handling. State Policy compliance documents specifically IT-14, IT-20, ITS-SEC-01, and ITS-SEC-02. To the extent these policies prescribe controls on State-owned systems. We expect to demonstrate equivalent controls via our SOC 2 Type II report and shared-responsibility matrix rather than by attesting compliance with the State policies verbatim. Please confirm SOC 2 equivalency is acceptable, and, if not, identify the specific control objectives where the State requires direct policy mapping. What we are asking ODOT to confirm That the requirements above are not applicable to a SaaS delivery, or For each item ODOT believes does apply to SaaS: the specific RFP clause, the artifact or attestation ODOT expects from the vendor, and whether a SOC 2 Type II report (plus our shared-responsibility matrix and standard SaaS security questionnaire responses) is acceptable as the compliance artifact in lieu of direct policy mapping. If ODOT intends the IT requirements to apply uniformly regardless of deployment model, please indicate that as well. 11.2 System Requirements SR 6005: What is the specific EIMS? Is the contractor responsible for the cost of integrating from EIMS vendor? SR 6030: Will ODOT be using VPN or dedicated cell modems (Semtech – ODOT property) to establish communication to ATG (Veeder-Root)? SR6045: What notification system is required (email, SMS, other)? SR6170: What changes are expected in a daily full dataset (full database or only the changes)? 13. Organization of Project Team Is there an expectation of in-person project management during the implementation? Attachment One – Vehicle and Equipment Numbers Can ODOT please provide the XLS due to lack of access to Ohio Buys? General Does ODOT plan to use their SIMs in Semtech hardware provided for data communication? Can the state provide details on any fuel card currently being utilized that would require an interface? | Answer: • 1. Backgroundo Can ODOT provide the total number of fueling positions (hose count) throughout the state? We do not currently have a report detailing total hose count.• 5. Project Locationo Do each of the 12 districts require separate in-person trainings? No, one system user training and one in-vehicle installer training (if required).• 6.2.2 Just-In-Time (JIT) Connectivityo What are approved Access Management platforms? Please refer to the RFP. We do not currently have an approved list of platforms, but will work with the awarded bidder to gain access.o • 6.2.4 On-Premises Device Communicationo Does the prohibition of short-range wireless technology apply to telematics devices as well as the on-premises device? Yeso Can ODOT provide technical specifications for their GPS platform created in house? No, a complete set of specifications is not available• 6.5 Cost Proposalo Are we allowed to add additional line items in the price spreadsheet for additional offerings in each subcategory? No, all offerors are to bid the line items on the pricing sheet as presented.• 6.5.3 & 6.5.4o Does this contract fall under the State of Ohio’s prevailing wage requirements? This contract will not be bid with prevailing wages. • 11. Solution Requirements IT questionsApplicability of IT Requirements to a SaaS-Delivered SolutionOur proposed solution is a multi-tenant SaaS platform hosted in AWS US regions, with no ODOT-resident application servers, databases, or source-controlled artifacts. Many of the IT requirements in the RFP appear to be written against a traditional on-premise / state-hosted deployment model, and we want to confirm, line by line, which ones ODOT intends to enforce against a SaaS delivery. Our reading is that the following requirements do not apply to a SaaS-delivered solution, because the underlying systems are owned, operated, and secured by the vendor under SOC 2 / equivalent third-party attestation rather than installed into the State's environment. Please confirm or, if any of these do apply to SaaS, identify which specific clause and the artifact ODOT expects: 1. Database platform mandates Any requirement to use Oracle, SQL Server, or another State-standard database engine? (Our platform runs on a vendor-managed mix of PostgreSQL and MongoDB inside our AWS tenancy; no database is installed in the State environment.) 2. Data dictionary, table schemas, and physical data model deliverables to the State: Any requirement to provide entity-relationship diagrams, table/column definitions, stored-procedure documentation, or other internal database design artifacts. (Our platform exposes data to ODOT through documented REST APIs and standard export formats; the underlying physical schema is vendor-managed, evolves with platform releases, and is considered proprietary. We can provide API documentation, exported data field definitions, and a logical data model for the data ODOT owns, but not internal table-level schemas.) 3. State-hosted infrastructure / server standards: Windows Server build standards, OS hardening checklists, server patching SLAs, hypervisor / VM standards, backup product mandates, and any State data center hosting clauses. 4. Source code escrow, source code delivery, and "work for hire" code ownership clauses: Written for custom-developed software installed at the State. 5. UI / technology stack mandates: Any clause prescribing a specific front-end framework, .NET version, browser support matrix beyond modern evergreen browsers, or similar implementation-detail requirements. 6. Application code scanning deliverables to the State: SAST, DAST, IAST, SCA / software composition analysis, Veracode/Fortify/Checkmarx reports, or similar code-scan artifacts produced for ODOT review. (Our SDLC includes automated SAST/SCA in CI and we can share executive summaryreports under our SOC 2 program; we do not provide raw code-scan output to customers.) 7. Unit-test coverage thresholds: (e.g., 80% line/branch coverage) and direct access to test reports, beyond the quality attestations included in our SOC 2 Type II report. 8. State-administered penetration testing: Of the application/infrastructure, beyond reviewing our SOC 2 program. 9. Direct access to production infrastructure, OS, or database for State administrators, auditors, or DBAs. 10. State change-management / CAB approval for vendor-side platform releases, patching, and dependency updates that do not change the State's contracted functionality or data handling. 11. State Policy compliance documents specifically IT-14, IT-20, ITS-SEC-01, and ITS-SEC-02. To the extent these policies prescribe controls on State-owned systems. We expect to demonstrate equivalent controls via our SOC 2 Type II report and shared-responsibility matrix rather than by attesting compliance with the State policies verbatim. Please confirm SOC 2 equivalency is acceptable, and, if not, identify the specific control objectives where the State requires direct policy mapping. What we are asking ODOT to confirm IT questions • That the requirements above are not applicable to a SaaS delivery, or • For each item ODOT believes does apply to SaaS: the specific RFP clause, the artifact or attestation ODOT expects from the vendor, and whether a SOC 2 Type II report (plus our shared-responsibility matrix and standard SaaS security questionnaire responses) is acceptable as the compliance artifact in lieu of direct policy mapping. If ODOT intends the IT requirements to apply uniformly regardless of deployment model, please indicate that as well.• 11.2 System Requirements IT Questions• SR 6005: What is the specific EIMS? Is the contractor responsible for the cost of integrating from EIMS vendor? Agile Assets. The vendor is responsible for the cost of integration.• SR 6030: Will ODOT be using VPN or dedicated cell modems (Semtech – ODOT property) to establish communication to ATG (Veeder-Root)? This will be dependent upon site-specific conditions.• SR6045: What notification system is required (email, SMS, other)? E-mail would be acceptable• SR6170: What changes are expected in a daily full dataset (full database or only the changes)? The full database is downloaded each night.• 13. Organization of Project Team• Is there an expectation of in-person project management during the implementation? Per the RFP requirements, Contractor resource(s) attend (at a minimum) one (1) day a week meeting to review/update during the pilot, installation, and startup phases. Additional meetings to be scheduled if/as needed. - These meetings may be attended virtually, or if determined by ODOT, in person.• Attachment One – Vehicle and Equipment Numbers• Can ODOT please provide the XLS due to lack of access to Ohio Buys? No• General• Does ODOT plan to use their SIMs in Semtech hardware provided for data communication?• Can the state provide details on any fuel card currently being utilized that would require an interface? No fuel cards are currently being used | Answered: 6/1/2026 Inquiry 90265 | What does the pilot consist of? What is the expected duration of the proposed pilot phase? | Answer: The offeror should be able to demonstrate during development that they will be able to successfully integrate with ODOT systems. Equipment Management would require the vendor to prove the hardware, and software in the field prior to full implementation. | Answered: 6/1/2026 Inquiry 90268 | Is the variance calculation required to trigger an automated alert when the discrepancy exceeds a configurable threshold, or is a dashboard display of the variance value (manual review) acceptable for initial deployment? | Answer: A dashboard display of the variance value is acceptable. | Answered: 6/1/2026 Inquiry 90271 | The RFP references 'ad-hoc report generation within the native software.' FuelDrive's Information/Analytics tab currently allows users to filter, pivot, and export live transaction data across multiple dimensions. Does this data exploration capability satisfy the ad-hoc reporting intent, or does ODOT require a formal drag-and-drop report builder with save/schedule capabilities? | Answer: The data exploration capabilities should be sufficient for most users. | Answered: 6/1/2026