Introduction & Purpose

Kerim: Hi, everyone. This is Kerim, Kerim with SolarAcademy. I am here today with Kevin Phan, of NexWave Energy Monitoring. Kevin, welcome. Good to have you.

Kevin: Thanks, Kerim. I appreciate it. Thank you for having me. 

Kerim: Today, we’re going to talk a little bit more about NextWave’s Energy Monitoring platform, which we have already done a session in the past, and today, we’re going to talk about NextWave’s software and hardware architecture and how they have integrated the hardware along with the software to provide a customer-driven solution with some specific advantages that make a big difference in the customer experience over the lifetime of solar and renewable assets.

Kevin’s Background: From Vietnam to NextWave

With that, before we dive into the conversation though, Kevin, I’d like to talk a little bit about your background, your academic background, and how you ended up at NextWave Energy Monitoring doing what you do.

You are responsible for the DevOps at NextWave, so maybe talk a little bit about your role and how that shifted over time because you’ve been working with the team at NextWave for several years now. 

Kevin: Thank you for the question, Kerim. I first started at NextWave Energy Monitoring as the DAS engineer. Back in that time, I was in charge of overloads on the network of the DAS, configuring the DAS, working with different types of hardware and making sure they run efficiently. 

Kerim: The DAS being the data acquisition system for various different assets that they build? 

Kevin: That’s correct. It includes the data logger, meter, cell modem, you can name it. After that, later on, as I had more knowledge on the hardware side, I was also working along with the development team and the customers to make sure we can bring the best value to our customers between the hardware and the software products from NextWave. 

Kerim: You have an academic background both on the hardware side as well as software, if I remember that correctly, right? 

Kevin: Yes, that’s correct. I first got my bachelor’s degree in computer science back in 2011, in Vietnam. Back in that day, I wanted to learn a lot on how to build good software, how to scale it, and how to make it run reliably. 

Later on, with that, I got another degree in computer engineering, which is more on the hardware side, more on the firmware, how to program those PCB boards, making them work together with the software.

How Integration Became the Core Philosophy

Kerim: Then you ended up at, I guess, Phoenix Renewable Services, which is a developer of mostly C&I and utility-scale solar and renewable assets. Through that experience, you’ve joined the NextWave team as they innovated this product for their own needs, as well as their customers’ needs, I assume, right? 

Kevin: That’s correct. The time with Phoenix Renewable Services allowed me to gain more knowledge on what is good service for the solar O&M system or usually what is the common issue that the O&M team needs to work on in order to keep the system running efficiently?

Bringing that knowledge into NextWave is a very good foundation for me in order to have a NextWave team to establish their product or set up a good pipeline for the product to work well. 

Kerim: Let’s talk a little bit about that product evolution of this energy monitoring platform. Maybe tell us a little bit of the early days, how it started and how it evolved over time.

Kevin: In the early days, we had our data logger and our software, and back in that day, the integration was something that could be very challenging since you have the software from, let’s say, the customer might get the software from one vendor, but they might get the hardware from another vendor. We see that it’s very important that the integration allows putting the hardware and the software together and running smoothly.

At NextWave, we know that integration is something we must achieve. It’s not just a buzzword. It’s our DNA. We know that when the software and the hardware are designed well together, then every sensor, every line of the code and every dashboard, feels just like one living system.

Why Integration Matters for C&I and Utility-Scale Assets

It’s not like different pieces, but working together. 

Kerim: Tell me a little bit about, like, you know, I’m familiar enough with the inverters and their software platforms that they provide to mostly homeowners and consumers for their own monitoring needs. So when we’re talking about industrial scale, C&I applications, utility-scale applications, data loggers, extra software, all the little signals you need to measure. How much more complicated is that than what you would get as a consumer with a standard inverter? Why do we need to create another hardware and software bundled together solution for monitoring? 

Kevin: We see the frustration for a lot of our customers or the asset manager. They usually deal with 10 different vendors, 10 different portals, and all of those, even though they have the software, they have the hardware, none of them give them a good clarity on that. 

Kerim: You essentially need a meta layer that combines the signals from all the various different inverter vendor manufacturers, panel, and other sorts of data outputting equipment, let’s say, to create one easy-to-consume dashboard.

On that note, perhaps, I should pull up some of your screenshots, product screenshots that you’ve shared with me prior. I’m assuming, a view like this is what you’re talking about, a product like yours can provide. I’m going to share my screen here quickly.

This would be data that is coming from multiple different hardware providers being pulled into one view where you can monitor various different signals on one or multiple assets. Is that a fair way to describe it? 

The Unified Portfolio Dashboard

Kevin: Yes, what you’re looking at is the portfolio dashboard where it’s pulling hundreds of different portfolios. Just in a snap, you can see the calculation there on the performance metric.

That just lets the asset manager or the site owner instantly know how the site performs and without going into each of the single sites. We build the unified stack from our edge gateway that can run and constantly pull the data and put it on the way up to our cloud services. The way we design it, it could handle up to a thousand devices simultaneously.

Kerim: Also, you can geographically show which of the assets need critical attention or some attention in terms of performance improvement opportunities. Is that what this view is, for example, that we’re looking at? 

Kevin: Yes, correct. What you’re looking at here is the map view where our customer can quickly see all of their assets in just one view, one map, geographically.

Kerim: Thanks for sharing all that. Let’s talk about why it’s so important to integrate the hardware and the software experience in doing what you do. 

Kevin: Yeah, because the separation creates friction, right? When the data logger speaks one language and the software speaks another language, the user has got a lot of issues with that.

For NextWave, we design our white label logger to integrate directly with our ingestion pilot. The software on the software side can handle a lot of data points in real time, multi-million data points in real time. Usually, the pilot we build is not for speed, but for harmony.

Kerim: We’re talking about these pieces of hardware. 

Kevin: Yes, right. We not only pick the hardware that runs well, but we also ensure that runs with reliability and scalability. 

Customer-Driven Innovation #1: Smarter Alerts

Kerim: Right. This innovation of combining these was a customer-driven innovation based on demands from existing customers of Phoenix and NextWave, afterwards. Is that a fair assumption? 

Kevin: Correct. For NextWave, anything we build, we all make sure that it meets the customer’s need or it solves a real problem for the customer. We don’t just go ahead and build a dashboard to show a bunch of data, but everything we put on the dashboard comes from a customer pain point. 

Kerim: I do remember from our previous conversations that one of the largest big box retailers as being a customer of yours, I think was the customer that demanded the ability to watch all their assets simultaneously and be able to prioritize. 

As a result of that, you came up with some of the alert management and dashboard features that are present in the product. I think that’s a great example of a customer-driven innovation that came out of the NextWave team. Maybe there is another example we can talk about of another customer-driven innovation as a second example? 

Can you tell us a little bit about that approach of how everything you do is customer-driven and to solve a specific customer pain point? 

Kevin: One of our big O&M team, they shared with us that they spend hours every day chasing the first alarm. When they shared that, it’s just like a light bulb moment for us.

After sitting down with the customer having the conversation, we just wanted to try to understand what is the real pain point that they are facing. After talking with them, we realized they didn’t need a long list of alerts, but they needed a right way to see the alert and understand which one is more critical, which one needs to be prioritized. Imagine like you have 200 sites. Every day, you go to the office and you see a thousand alerts.

Now you might ask, “Oh, how can I solve a thousand alerts in just one week or one month?”

Customer-Driven Innovation #2: Plug-and-Play Hardware

It’s not that the customer needs a dashboard, but the insight they need is to know which one is worth tackling, which one is worth fixing. Rather than go out to try to fix just whatever you have on the alert list.

Kerim: I get that. Enhance this alert management screen you designed for your customers. Makes a lot of sense. What’s another example that we can talk about? 

Kevin: Another example that we have is we also have another O&M team. The customer reached out to us and said that our few technicians have very limited uptime to configure the DAS because they need to follow up with a lot of tasks on the construction side, and if they have a hundred sites, they cannot just spend a lot of time to configure the DAS on site. That would be their nightmare, and they try to avoid that at all costs. 

Kerim: They don’t want their technicians out in the field working on configuring your data acquisition system. They just want them to do all the other construction-related work, and they tell you that it’s taking too much time.

You guys then innovated something for them. What was that? 

Kevin: Yes, that’s correct. After understanding the pain point from the customer, we needed the right way to limit the time of commission on the field, on the site.

We understood that and changed again from there. From that, every gateway that leaves our lab, we always make sure that it is reconfigured. We simulate the device that we don’t have in the lab to simulate the signal and make sure on the DAS on the equipment, it’s configured and working properly with the software, with the cloud, before shipping out to the customer. 

And the moment they put in, it’s just plug and play. They plug it in, they see the data instantly on NextWave. 

Kerim: That’s great. That’s like buying a laptop, a new laptop without having to configure it. That is a great experience, I’m sure. Great.

Architecture Built for Scale and Reliability

Well, I guess there are also some architectural benefits to what you do from a reliability and scalability perspective. Maybe we can talk a little bit about that and how you guys designed, especially the backend part of the product to serve your customers better for reliability and scalability. 

Kevin: For our architecture, we understand that keeping the system running reliably and efficiency is a challenge. We want to make sure that all of our customers are happy with the data that they receive, all the insight. The way we design it is we have the load balancer on our data ingestion.

This is a common miss for a lot of the other competitors that I can see because when you have a certain amount of device that constantly is talking to your server, the server cannot automatically handle a big load. It needs to be designed properly in order to handle that.

Vision and Closing Thoughts

At NextWave, we simulate the scan error where we’re going to have a million devices talking simultaneously to the server. We test that and we make sure the data, our data ingestion layer is designed well so that it’s not going to fail in those cases, and it will ensure for us, even when we scale to a million devices or two million or three million devices.

Kerim: Got it. It sounds like you guys have been quite successful, innovating from a very customer-driven perspective, a well-integrated hardware, software solution that serves customer needs.

As you go forward, can you tell us a little bit about what you see in the future for NextWave in terms of products and how that will keep up with the high standards that you have achieved on integration, responsiveness to customers, and reliability? Tell us a little bit about that vision of the company. 

Kevin: For the vision, of course, we will keep, explore and make sure our design, our system is running reliably and we can scale up well.

From what I see, machine learning and AI is a big topic that everyone is up for. At NextWave, we will make sure if we use the solution, it needs to solve a real pain point for our customer because above anything, the one thing that doesn’t change is we want to retain empathy for our customer. Anything we design, again, we always make sure that this is something that our customer is looking for.

That is the real issue that the team needs to tackle and solve for our customer. 

Kerim: That makes a lot of sense. Well, I think designing products and solutions with empathy for customers’ pain points is a very good formula for success in business and sounds like you guys are doing a great job at it. Thank you for sharing the insight into NextWave as you did, Kevin. Thank you very much for this time.

Kevin:Thank you, Kerim. Thank you so much.