Making Resilient Software with HOOTL

At Electric Era, we’re passionate about creating a robust and reliable electric vehicle (EV) charging network to power the future of transportation. A key part of achieving this is ensuring resilience in both our hardware and software systems. One of the most effective practices we employ to enhance this resilience is Hardware Out of the Loop (HOOTL) testing. In this blog post, we’ll explore what HOOTL is, how it supports critical system capabilities like Fault Detection, Isolation, and Recovery (FDIR), and why it’s a cornerstone of our development process.

What is HOOTL Testing?

HOOTL testing is a methodology that allows us to validate and debug software without relying on physical hardware. By building abstractions for every hardware component we interact with—such as chargers, payment terminals, and sensors—we can run comprehensive tests in a simulated environment. This approach supports the implementation and verification of critical system functionalities, including FDIR, by enabling us to isolate and test software behavior independently of hardware dependencies.

HOOTL is particularly valuable in the context of EV charging infrastructure, where hardware is complex, costly, and not always available for testing. It empowers us to catch issues early, streamline development, and ensure our systems are robust before deployment.

Why HOOTL Matters for EV Charging Networks

Creating a reliable EV charging network involves navigating unique challenges. Our systems must seamlessly manage real-time interactions between software, hardware, and external factors like payment processing, grid connectivity, and user interfaces—all while maintaining uptime and safety. A single software issue interacting with hardware could lead to downtime, safety concerns, or poor user experiences. HOOTL helps us address these challenges in several ways:

  1. Catching Software Issues Early
    By isolating software testing from hardware, we reduce the complexity of debugging. Instead of troubleshooting across an end-to-end system with physical chargers and network connections, we can identify software-specific issues in a controlled environment. This ensures we’re confident in our code before it interacts with hardware.
  2. Maximizing Hardware Testing Efficiency
    Testing with physical hardware is time-consuming and resource-intensive. Setting up chargers, simulating real-world conditions, and iterating on fixes can slow progress. HOOTL allows us to thoroughly vet software beforehand, minimizing the time spent on hardware testing and accelerating deployment cycles.
  3. Testing Without Hardware Availability
    Hardware isn’t always accessible—whether due to supply chain delays, lab scheduling conflicts, or field deployments. HOOTL enables us to test software on Continuous Integration (CI) platforms or local developer machines, keeping development on track even when hardware isn’t available.
  4. Doing Dangerous Things
    By running full test flows without hardware dependencies, we can evaluate software logic designed to prevent or detect critical hardware failures (e.g. causing a grid overcurrent protective device to trip, or repeated charger emergency shutdowns). This allows functional and regression testing without damaging hardware or creating safety hazards.

How We Implement HOOTL at Electric Era

HOOTL testing at Electric Era combines industry-standard software practices with a custom-built Hardware Abstraction Layer (HAL). Here’s how we bring it to life.

1. Leveraging Software Best Practices

We rely on tools and strategies common in modern software development:

  • Docker: Containers ensure consistent, reproducible testing environments that mirror production systems.
  • CI Runners: Our Continuous Integration pipelines automatically validate every code change, catching issues early.
  • Automated Tests: Separate from unit tests, test containers actually run test cases that check for conditions, and are evaluated by CI to determine if a test passed or a regression occurred.

These practices provide a strong foundation for reliable testing, but the real magic happens with the HAL.

2. Building a Hardware Abstraction Layer (HAL)

The HAL is the core of our HOOTL strategy. It acts as a simulation layer that replicates the behavior of physical hardware components. For example:

  • Instead of interfacing with a physical payment terminal, our software communicates with a simulated terminal that mimics realistic responses, like transaction approvals or declines.
  • Instead of controlling an actual charger, we use a virtual charger that emulates power delivery, fault conditions, and communication protocols.

The HAL is designed to be flexible, allowing us to simulate edge cases and failure modes—like a charger malfunction or network disruption—that are challenging to replicate with physical hardware. This capability is critical for verifying functionalities like FDIR, ensuring our systems can detect, isolate, and recover from faults effectively.

3. Creating Component-Level Abstractions

To make HOOTL practical, we’ve developed abstractions for key components of our EV charging system. Consider two examples:

  • Payment Terminal Abstraction: This simulates the entire payment flow, from card swipes to transaction processing, enabling us to test payment logic without a physical terminal.
  • Charger Abstraction: This emulates the charger’s behavior, including power output, error codes, and status updates, allowing us to validate energy delivery logic in isolation.

These abstractions let us test most of our system’s functionality without hardware.

4. Running Full Test Flows Locally

With the HAL and component abstractions in place, developers can run full test flows on their local machines. This means simulating an entire charging session—from a user initiating a payment to the charger delivering power—without leaving their development environment. These tests are fast, repeatable, and don’t require access to a hardware lab.

For example, a developer can:

  1. Simulate a user swiping a credit card.
  2. Verify that the payment processes correctly.
  3. Confirm the charger initiates power delivery.
  4. Test fault handling for scenarios like a payment failure or charger error.

This local testing capability speeds up iteration and reduces reliance on shared resources, while also supporting validation of critical capabilities like FDIR. Below is a real-world example of what a developer can see on their workstation during a HOOTL-backed charging session, observing the various simulated and real application logs, as well as what the actual UIs for the charger and the backend would be displaying.

5. Validating with CI

Once local tests pass, our CI pipelines take over. Every code change triggers a suite of automated tests in Dockerized environments using the HAL. This ensures our software remains stable as we scale and add new features. By catching regressions early, we maintain confidence in our codebase, even as complexity grows.

The Impact of HOOTL on Electric Era’s Mission

HOOTL testing is a critical enabler of our mission to deliver a resilient, reliable, and scalable EV charging network. By isolating software issues, optimizing hardware interactions, and enabling testing without physical dependencies, we achieve:

  • Enhanced Reliability: Early issue detection reduces the risk of field failures or outages.
  • Faster Innovation: Rapid iteration cycles let us roll out new features and improvements quickly.
  • Scalable Development: Testing without hardware constraints supports growth without resource bottlenecks.

Importantly, HOOTL supports the implementation and verification of critical system capabilities like FDIR. By simulating fault scenarios in a controlled environment, we can ensure our systems detect issues, isolate them effectively, and recover gracefully—keeping our charging network operational and user-friendly.

What’s Next?

As we grow our EV charging network, we’re committed to evolving our testing capabilities. Future enhancements include:

  • Richer Simulations: Expanding the HAL to cover more edge cases and failure modes will unlock better test coverage. These get summarily added to CI to automate testing for developers.
  • Expanding HITL: HOOTL is the first leg of a long journey in resilient software development. We also have HITL (Hardware In The Loop) that we will share parts of the HOOTL simulation infrastructure with to achieve testing of real systems (real chargers, real batteries, and real vehicles).

Conclusion

At Electric Era, HOOTL testing is a powerful tool for building a future-ready EV charging network. By combining software best practices with a robust Hardware Abstraction Layer, we isolate issues, accelerate development, and verify critical capabilities like FDIR. Whether it’s running full test flows locally or validating code in CI, HOOTL empowers us to deliver systems our users can trust.

We’re excited to continue pushing the boundaries of resilience in EV charging, and we hope this deep dive into HOOTL has provided valuable insight into our approach. Stay tuned for more updates on the technology driving the next generation of EV infrastructure!