As we consider how to submit reports for the CFR and BC LCFS regulations, and what data needs to be collected, we also need to think about how we collect this data. Generally what we are talking about here are charging sessions. How much energy was delivered to the vehicle, when was it delivered and over what time period?
Our use case involves two actors: Rewatt is the pull system acting as the credit creator, and needs access to charging sessions, so that it can be delivered properly to a 3rd party auditor and a regulator for oversight. The charging provider has a data-management system for their sites, which includes charging session data. How do the two systems talk to each other?
A seemingly simple solution might be to export and deliver a CSV once a year to Rewatt, maybe by email or possibly by publishing to a secure site, such as an Amazon S3 bucket. While CSV’s are great for one-off situations, it starts to become a bit of a problem once business starts to scale.
As the number of sites increases, each potentially with multiple chargers needing to be monitored regularly, their management becomes more difficult. Throw in multiple projects, some projects where not all the sites are included and we really need to add some automation to make sure everything is correct.
Things get even more complicated from the perspective of the credit creator, that is trying to ingest data from multiple organizations, for multiple projects, with 100% reliability and accuracy. Having a well-tested, secured and reproducibly accurate API integration can really alleviate a lot of the concerns. Let’s now look at each of these concerns, and touch on how it affects the credit creator and the charging provider.
- Reliability
- Scalability
- Accuracy
- Historicals
- Error recovery
- Normalization
- Security
- Effort
Reliability
Even if the export of a CSV from your information system is automated, and perhaps it is uploaded to an S3 bucket, and maybe even that bucket is automatically ingested into the credit creation system automatically, there are some factors to consider. There are multiple systems involved, each with their own configurations and security requirements . Some programming is going to be required to make this all work seamlessly. And there are 3 points of failure.
Alternatively, a manual export and manual upload is a human activity, which is always subject to some error, as well as a lack of predictability. While it can work, it tends not be particularly reliable, and requires human intervention.
In contrast, an API is purely machine to machine, with only 2 points of failure, and since a contract is enforced and well-tested, is entirely predictable and reliable, after a one-time setup.
Scalability
As the number of sites increases, one can simply increase the number of rows in a sheet. Easy enough. But what if we wanted to increase the frequency of export? Or what if we wanted to limit which sites are exported? And what if we wanted a large number of sites over a longer or shorter time period? While doable, it requires work. With an API implemented, the work is already done! Additionally, it is is very easy to rate-limit your API, which can be critical during scaling.
Accuracy
This generally boils down to ease of repeatability. Once an API is implemented and tested and found to adhere to its contract, accuracy will be very high over an ongoing basis.
A CSV export, which if automated, should be similarly accurate. If manual, then we introduce uncertainty around time periods, possibly timezones, number handling, human error and more.
Historicals
With an API, this is simply a matter of querying for the appropriate dates, which is generally already a part of the automated data collection process.
With a CSV, a special request to the IT department would likely need to be made for the appropriate dates and sites, then manually ingested.
Error Recovery
If for any reason either system suffers failure, we may need to recover some missed data. Consider a case where a CSV is published once a month, but a month is missed. In all likelihood, solving the problem this will involve human intervention, such as a manual. With an API, this is automatic – the credit creator will simply retry later until it works.
Normalization
A very specific set of fields with accompanying units is required for accurate conversations between two systems. This can be accomplished with some light programming in either an automated CSV solution or an API solution. With a manual CSV solution, this will be prone to error, as human intervention is required.
Effort
Charging Provider
Conclusion
The question for the charging provider: is it worth the extra time to implement an API, rather than export a CSV? For anything more than a one-time delivery, the answer must be yes. The improved reliability, scalability, error-recovery, and avoidance of human intervention quickly recoups the investment.
For the credit creator, the answer is unequivocally yes – they get access to reliable, accurate, formatted data with fault-tolerance, without doing anything (this integration is already done for multiple providers).
