Booster Fueling Automation System

Overview

Responsibilities

• Tech lead and manager of the members involved in building this system.
• I also acted as a product manager figuring out what we should be working on next, groom the Jira stories, and assign the work.
• I was the co-developer on the Booster Computer IoT called “Optimus” in the peripherals section above. We’ve used Node.js to write the code and Balena for device management.
• I managed a team of two mechanical engineers who helped reimagine the initial prototype of the Booster computer Optimus on the hardware side.
  • I lead some of the hardware decisions on the WiFi gateway options, cellular data providers, fuel level sensors among other things.
  • The Optimus enclosure includes a usb-to-serial adapter to allow sending commands and communicate with a TCS 3000 Register.
  • It also includes an ethernet port that connects to an industrial WiFi gateway, which also has its own service for device management.
• Troubleshooting sessions in the system proved to be quite fascinating, as they involved analyzing the flow of data across multiple devices, backends, and services. I consistently maintained a meticulous approach by creating detailed documents of the findings to ensure that issues were thoroughly resolved.
• Worked collaboratively across departments with Booster’s Operations team, conducting on-site visits to our Yards (locations where tankers are stationed and operations commence) to directly observe user interactions with our technology, identify any issues, and collect feedback for iterative enhancements. During major global releases, I frequently participated in ride-alongs with the SPs, staying with them until 3:00-4:00 am.

Platform #1: Booster Computer “Optimus” (Node.js)

• Co-developer writing the code in Node.js, exposing APIs for connected peripherals (iPad in iOS and Android in Kotlin).
• Wrote a Web Sockets wrapper to create a seamless connection between the iPad <> IoT <> Android handheld.
• Wrote a big portion of the business logic for authenticating a Service Pro, retrieving customer account information, loading thousands of vehicles, and  more.
• Wrote unit tests to cover almost the entire codebase.
• Helped influence the layer of communication between the IoT device and the TCS Register 3000.
• Third-party services:
  • Segment for analytics
  • Sentry and Datadog for error reporting
  • GeoTab for tanker tracking
  • Balena for MDM
  • PubNub for real-time notifications
  • Realm for offline capabilities

Platform #2: Tanker Remote Control (Android Handheld, Kotlin)

• I taught myself Android and Kotlin and completely developed the entire app from scratch in less than a month. The rapid development was necessary because we didn’t have the budget to build the app natively at the time, so I committed to working long nights and weekends to make it happen. The performance improvement over our old React Native app was dramatic, greatly enhancing the experience for our Service Pros.
• Followed a MVVM approach with data bindings in XML to connect many views to the data models.
• The app comprises of multiple modes the user can choose from:
  • Fueling: service fleet accounts/vehicles
  • Fuel Transfers: for tank-to-tank or tank-to-chassis fills (mostly used for our own tankers)
  • Pop-Up Gas Stations: for consumer drive thrus (refer to this page for more details)
  • Blast Tagging: allows the user to tag vehicles with an NFC sticker and program all the needed data to identify a vehicle using the handheld
  • Diagnostics: program the tanker’s wifi NFC sticker, troubleshoot the TCS register, and more.
• The handheld connects to the tanker’s WiFi after having scanned the NFC sticker with WiFi credentials, then http/websocket requests go to Optimus over TCP when needing to communicate with the meter to operate the pump remotely. Finally http requests go to our backend directly when the meter communication isn’t needed.
• While working on this project, a crucial priority was to prevent the Service Professional from ever delivering the wrong type of fuel to a customer’s vehicle, a safeguard we referred to as Cross-Fill Mitigation. We implemented numerous protective measures at various stages to ensure that, as long as the Service Professional used our technology from start to finish, this mistake could never occur.
• Third-party services:
  • Segment for analytics tracking
  • Sentry for error reporting
  • Scalefusion for MDM

Below are screenshots showing the Android app, some of those screenshots aren’t the most up-to-date.

Platform #3: User & Order Management App (iPad)

• I managed a team of two iOS engineers developing the iPad app, making sure that all tasks were well-defined, prioritized with stakeholders, and delivered with high quality.
• At times, when we were overwhelmed with requests, I stepped in to contribute and make necessary changes either to the iOS app and/or the backend.
• Highlights:
  • User authentication for Service Pros
  • Ability to see all tankers in the region to check-in and start their trip (which pairs the iPad to a tanker to ensure the IoT and Android handheld are all communicating)
  • View training materials in the app
  • Perform multi-point inspection on their tankers
  • In-house Bill of Lading OCR technology using Apple VisionKit for when our SPs go to a terminal to load their tanker. This ensures we prevent any cross-load from happening,
  • In-house hazmat aware navigation with Apple Maps
  • The ability to fully service vehicles in cases where the tanker isn’t equipped with an IoT device
• Third-party services:
  • Amplitude for analytics
  • PubNub for real-time in-app notifications
  • Lessonly for training materials
  • SimpleMDM for device management