As talk of the "internet of things" -- ie: smart equipment via automation and machine-to-machine communications -- continues to get attention, we're seeing more and more entrepreneurs bringing forth some flavor of idea involving energy-focused equipment controls. Smart-home plays, automated load shifting efforts, smart grid software, etc.
From a cleantech perspective, the basic concept is the same: Using automated intelligence, make hardware save energy spend via optimized usage patterns, and then build other value propositions (e.g., preventative maintenance, more granular data, remote sensing, etc) on top of that core value proposition.
As entrepreneurs tackle a variety of sectors and applications with this concept, however, there's one basic question they inevitably have to ask themselves: How embedded do I want my intelligence? Or to put the same question another way, how much do I want my software- and controls-based solution to be residing within specific hardware devices, vs how much do I want to simply ride over a variety of devices with common set of controls and software?
Do I just sell software, separate from the purchase decision of hardware? Do I license software embedded into other OEM's hardware, by partnering with those OEMs? Or do I make my own hardware and sell it, but with my software/controls as the advantaged factor?
As we look across sectors and applications, there is no universally correct answer to these questions. But it is hugely important to answer them correctly, as we'll see below. So let's explore some of the trade-offs and key criteria entrepreneurs should keep in mind when addressing this question strategically.
1. How much technical advantage is gained by tailoring specific controls attributes to specific hardware?
This question has to do both with the complexity of the hardware being affected, and how much of the optimization gains are due to technical hardware operations vs. simpler adjustments to usage.
The more complex and intricate the hardware, unsurprisingly, the more you would expect a customized solution for each specific type (brand, model, etc) of hardware would ferret out additional efficiency gains. With solid state lighting, for instance, the differences in power electronics, cooling requirements, voltage choices (ie: run chips hard or easy), types of sensors, etc. are all variables that can significantly affect the ability of a controls solution to drive efficiency gains. The more tailored the controls to that particular fixture's setup, the more efficiency it can drive. You can certainly drive savings by applying a broadly-designed controls system across a wide variety of lights, but you get deeper savings by designing specific controls parameters for the other specific components and configurations of the fixture or bulb.
World-class leaders in battery control technologies, for example, have gained important advantages. Tesla's future growth, for example, is built as much on such factors as on brand awareness.
Contrast to a smart-home clothes dryer, on the other hand. It's a big energy user, but the specific energy-consuming system is fairly simple and standard. Instead, the energy gains to be made are more about time of use and some other choices around usage patterns. This would be more amenable to a separate, broader controls system that perhaps adjusts more in the home than just the dryer, for example.
2. How much existing, standardized equipment interface is available?
Many existing industrial controls standards already exist in the marketplace, for instance with large HVAC systems, other commercial buildings management systems, or factory equipment. These typically haven't been designed already with energy optimization in mind, but you also often don't need to build controls that are linked to specific components within the equipment, because the existing industrial controls they were designed around provide a "doorway" for energy-optimization software to make targeted adjustments.
On the other hand, in just about all segments there are also small niche industrial controls vendors or even just PLC-based homegrown solutions that have some portion of the installed base. If they make up a large portion of the market, you're going to need fairly customized solutions regularly.
3. Are you targeting applications inside or outside the meter?
Utility-facing smart grid software has to interact with hardware in some way. But there's a lot of legacy hardware out there, a lot of utility resistance against new hardware vendors, and a much bigger scale of project, than typical for energy consumer-side applications. System integrators are also more readily available for utility-scale implementations. Generally speaking, therefore, these factors will drive more non-embedded controls on the utility side of the meter than on the consumer side.
Even on the consumer side of the meter, I think we'll see a shift over time toward more common controls standards, even when embedded into hardware from various manufacturers. But utility-side projects are probably more often large enough to support software-only efforts in this regard.
4. How fragmented and receptive are the OEMs and channel partners to partnering with (and paying) controls vendors?
It's obvious but it's amazing how many entrepreneurs don't really factor this in -- if you're planning on getting your revenues from licensing controls to OEMs, how capable and receptive and scalable are they? You're not going to build revenues quickly if the answers to this question are at all negative.
So, for instance, in the lighting industry some smart entrepreneurs have instead chosen the two other pathways. Some have gone the fully separate software route, designing controls that are intended to be overlayed on any OEM's fixtures. Another, BCC portfolio company Digital Lumens, decided instead to start by building their own fixtures with their own embedded controls, eventually migrating to an OEM-licensing strategy.
Take note of what this implies: The counter-intuitive decision to manufacture hardware as a result of a go-to-market strategy, not the other way around. Per point #1 above, there are obviously operating efficiencies to this stack-integrated approach, but the other relevant factor here is the nature of the channels in addition to the OEMs. In today's lighting market, the channel partners generally don't "get" the economics of lighting controls yet, and in many customer segments there's resistance to paying much for an add-on controls solution (even when the economic value proposition is clear). So embedding the controls into actual hardware and selling the full bundle to customers gives more opportunities to capture the economic value created by the controls, is the theory.
And at least in this case, the theory seems to have held. DL's embedded controls have been installed in 50M square feet, ~10x as many square feet of space as any of the software-only startup contenders over a roughly equivalent period of time. Of course, it's still early days in that industry sector, the full story has yet to be told...
5. How hard is it to make the hardware yourself?
Another obvious one in many cases (why invent a new dishwasher manufacturing company just to sell a proprietary smart-home control system?), but not in all. Contrast EcoFactor with Nest. Both are going after smart thermostat hosted controls in the home, but Nest decided to sell proprietary ones and EcoFactor partnered with an existing smart thermostat manufacturer. Both companies are growing so it's hard to say yet which was the smarter pathway to establishing their controls in the marketplace, but it'll be fascinating to watch the rivalry as it develops.
But of course, it's only an issue because the thermostat assembly itself could be relatively cost-effectively outsourced. For more complex or otherwise costly manufacturing decisions, it's a factor that could skew entrepreneurs toward a non-embedded controls strategy altogether.
Ultimately for all of these software/controls plays, embedded or not, the goal is the same -- to become an actual or de facto industry standard. The decision as to what path to take is primarily one of market entry and early scalability, because the hope for all is that network externalities eventually take over after some critical mass is reached. But this is an important strategic decision for the long run for startups. It affects core and ancillary capabilities they must build into the team. It affects capital needs and revenue models. And as a couple of the examples above show, it can determine whether a startup can outpace the others to become a leader in the race to network externalities, or fall behind and be imperiled. There are other questions to ask when making this decision to embed, license or float above the hardware choices altogether. But the above five questions are ones that we've seen come up repeatedly, across a wide variety of end markets.