You are here
Welcome, everyone. This is Bruce Kinzey with the Pacific Northwest National Laboratory and director of the U.S. Department of Energy's Municipal Solid-State Street Lighting Consortium. Welcome to today's webinar, Connected Outdoor Lighting Systems for Municipalities, brought you by the DOE Better Buildings Challenge.
This webinar was specifically organized for this group due to your participation in the outdoor lighting accelerator via the Delaware Valley Regional Planning Council and the regional streetlight procurement program that they have assembled. Before we get started, I want to give a shout-out to the Better Building Summit that's scheduled for next May in Washington DC.
The summit is a national meeting of organizations that get together to share information and best practices for increasing the energy efficiency of America's homes and buildings. The summit is designed for program partners and stakeholders, which includes everybody tuned in to this webinar. And so I want to offer it for your consideration.
The summit agenda isn't finalized yet, but we expect it to include sessions on street and other exterior lighting, as well as numerous building interior energy applications. I think they had about 900 attendees last year, so it's a pretty broad participation. And there's a lot of information sharing going on.
We're also planning the final in-person meeting of the outdoor lighting accelerator membership in conjunction with the summit, as the accelerator is scheduled to wrap up its activities not long after that. Another thing I want to mention before we get on with today's topic is that Liz Compitello of the DVRPC is on the panel with us here to answer any questions during the Q&A that may pertain to the RFP that's just been released. And by the way, congratulations on getting that out, Liz.
Good job. Liz also has a brief announcement for the members out there. Liz?
Thanks, Bruce, and thanks to everyone that's on the phone. I believe we have more than 30 participants in the program joining us today, which is really great. And thank you to the MSSLC, the folks at Pacific Northwest National Labs for hosting this for us, particularly Carrie and Bruce and especially Michael for putting this on. Michael actually joined us at the kickoff meeting we had a few weeks ago. But due to technical difficulties, we weren't able to have it then. But this is actually a much better format, our very own webinar, so we can really get into the details of the topic.
And it gives you all a forum to ask as many questions as you have, which is just a really great opportunity. So thank you very much for doing that. And also the one quick announcement is that if you're interested in what you see, either for the project that you'll do under this program or for anything that you'd like to do with controls in the future, you have an opportunity to see this in action at the tour at West Chester Borough that we're hosting. It's going to be November 4 from 5:30 to 7:30 PM beginning at West Chester Borough Hall.
And they have a control system set up that they're utilizing quite effectively. So if you're interested in attending that, please just let me know. And thanks again. Back to you, Bruce.
OK, thanks, Liz. All right, let's get on with the webcast. By now, probably most if not all of us have heard about the next big thing in outdoor lighting being the use of controls. Controls are being touted for not only offering potential cost savings through enhanced capabilities like dimming or through monitoring and reporting performance in real time, but also by offering a host of new features potentially, like the addition of road and weather sensors and Wi-Fi networks and all this other stuff that I'm sure everyone's been hearing about. But what is the actual status of the system and what's it going to take to get one implemented?
What are some of the various issues the site should consider in pursuing some form of a control system? These are just a few questions that some of you may have and probably others as well. Our speaker today is Michael McCloskey, who came to work on our DOE solid-state lighting team about six years ago after 12 years in the commercial semiconductor industry.
He's been our local controls experts since he got here and probably knows as much on the various systems out there and what they offer and what the challenges are as anyone you're going to find. We're lucky to have him and I hope you'll take full advantage by not only listening to what he has to say today but also by sending in your questions for the Q&A afterwards. So without further ado, let me turn it over to Michael. Michael?
Thanks, Bruce. Oh, networked outdoor lighting control systems-- kind of three main pieces, right? There are your field devices that the main pieces of them are going to be installed on your streetlights and implementing the control. But they may also include-- more and more, people are operating sensors or meters, features that may be again integrated into the device mounted to the luminaire. They may be integrated into the luminaire or they may be a standalone type of device. But we're talking here about devices that are out in the field.
But in most not all systems, there's a gateway that is used to coordinate or route data from field devices to kind of the second main piece, right? The network infrastructure. And this is-- again, there are multiple ways to go about doing this. We'll talk a little bit about some of them later on in the presentation.
But the network infrastructure is really the link between your field devices through the gateway again and your central management system, right? So this is really where, as a city manager or streetlight manager, you'll be interacting with the system once it's up and running. Typically, this consists of a server and a database and one or more ways to interact with the system through some kind of software, often with the GUI or whatnot, maybe through a desktop computer or laptop or maybe even a mobile device.
So field devices, network infrastructure, central management system-- kind of the three pieces here of network outdoor lighting controls. So there are a lot of things we could've talked to you about today. And I'm going to say just a few words about kind of the capabilities of these systems and then really spend most of my time talking kind of one level lower about some of the main differentiators that we see in commercially available offerings and maybe post some questions about what you might need to think about as you start to want to compare and contrast these offerings.
So in terms of basic capabilities, most of these systems on the market today offer these things, right? The ability to do asset management, the ability to do remote monitoring, the ability to use that remote monitoring data to generate reports, to generate maintenance requests, to maintain the status of your field devices, to do basic lighting control, on-off scheduling, schedule dimming, et cetera, and some level up adaptive lighting, right, where you would be changing the light output from its maximum to some different level based on some circumstances. Maybe it is just a scheduled time of day. But on the other hand, maybe with a sensor, you might change light levels based on traffic, for example.
Now here's just a short list of some of the emerging capabilities you're starting to see these systems or this technology offer. And by and large, what's really happening is people are thinking, well, if I have this network across the city that allows me to exchange data between devices or bring data back to a central management system, what else might I do with that network? And again, I'm not going to go into detail here, but just a short list of some of the things that are being pursued and some of the things some people have done that are either directly integrated into the outdoor lighting control system or kind of related to its installation.
So some of you may be aware that many of the broadband carriers are interested in installing small cells on poles-- maybe integrate into your control system, maybe just adjacent. And we'll need to pay you monthly fees in order to do so. There are systems that can determine parking availability, where there are open spots, which could lead to the ability to offer parking location data or services and charge fees for that. Of course, there are systems that can be used to detect when meters are expired and give you the ability to collect fines.
Systems allow you to attach interactive LCD billboards to streetlights or street poles, I should say-- again, lead to retail advertising fees. And just some of the sensor types people are either investigating or piloting. Or in some cases, you can see some manufacturers have a fair number of installations of systems that also have weather-reporting sensors, air-quality-reporting sensors, and even illegal dumping trash, dumping-detection cameras or sensors – all, again, which could lead to either provide you direct value or provide you with the ability to provide others with a service and maybe collect revenue for that service. Now, there are a number of issues I would say that people have to address in terms of trying to adopt this technology.
And I'm not going to spend a lot of time on these here. Maybe you want to talk about these in the Q&A, but here's just a short list. I would say while the core technology that's being used to develop these systems is pretty mature-- they're often just borrowing from other application areas-- many of these products are still fairly new to the manufacturers who are providing them. And so sometimes there's still some things to work out.
Of course, many streetlight managers or departments don't have a lot of experience with networks in general or communication systems. So there can be this market and user maturity curve. I would say that people have to come up, if you will, to really make good choices that lead to successful installations and deployments. The upfront cost for the technology in these systems is still arguably high.
And I'll say maybe a little bit more about what I mean about that in a minute. But often, the price to add this functionality can be on par with what you're paying to, say, retrofit HPS to LED at any given pole. And then there's the issue of what kind of payback time do you need to justify the system.
And really, this issue is kind of really a lot about what of the features and capabilities, some of those ones I just showed you, are going to be of value to you. Some of them, obviously-- the newer ones, the more advanced ones – could produce some revenue that offsets the upfront cost. But for the other ones, I mean, are you just looking to do maintenance?
Do you need to improve your maintenance? Is that a big expenditure or sore spot for you? Are you interested and looking to do adaptive lighting? If those things aren't strong value propositions for you, then the cost per pole may be tough to justify.
A little bit more about one of those, right? If you are interested in doing any adaptive lighting or adjusting light output over the course of the night, as you well know, many you are paying fixed-rate tariffs for energy and don't have the ability to monetize those energy savings. So certainly that can be a challenge.
But pretty much for everything on this list, there are activities going on across the country poised to address them and even addressing them, I think, in some areas of the country. So there are, again, some regions where people do have adaptive plating tariffs in place or even real-time pricing tariffs in place and other areas where there are projects underway that are poised to lead to new tariffs in certain areas. And of course, we have an interest in trying to, as those things happen, broadcast broadly how they're being accomplished and hopefully speed people in their own region to getting those practices in place if they're interested in doing adaptive lighting.
Many of the, again, value propositions are a little tough to quantify with a simple calculation. Do you know your maintenance costs right now? Can you come up with a calculation that would compare new versus previous costs?
Again, are you willing to do adaptive lighting? If you're interested in weather data, what's that worth to you? So I think quantifying value propositions, comparing them to today's cost, if you need to do an ROI, can be challenging for some people.
Like I said, I think there's a lot of activities going on in helping users in some ways address these issues. And then similarly, there are a number of things going on on the technology side, if you will, that I'm just calling game changers here. I think they're poised to really help people more readily make decisions, right? And some of those are around modularity versus integration.
We certainly know if you were to integrate some of the control system functionality into the luminaire or the driver, that's going to greatly reduce costs. And certain manufacturers are considering or willing to do this. But this raises the question: well, what network protocol or what radio should I integrate in there?
Because there's many competing ones. Most of the solutions in the market today are proprietary. But this leads us to the next bullet.
There are a number of interoperability activities underway. And as those start to take root and hold, well, then it starts to make it more feasible for someone to say, well, I'm going to integrate this radio into the luminaire or into the driver. That would give you the ability to still work with multiple manufacturers-- say, install their gateways and central management systems or compete against each other to implement a system.
You know, there are also many examples of how city visions-- maybe top down from the mayor, if you will, or interdepartmental collaborations-- are allowing municipalities to consider more value propositions to justify this kind of technology. And then when it comes to adaptive lighting tariffs and monetizing energy savings, again, there are starting be more examples of municipal utility collaborations on business models and how this would work where both sides maybe can come close to what looks like a win-win. And finally, I already mentioned there are a number of new value propositions being piloted, developed, discussed, and deployed in some cases. And many of them have revenue opportunities which greatly affect, I think, the decision here.
So with that brief introduction on those topics, I want to spend the rest of the time really giving a presentation or going through a presentation I gave at the IES Street and Lighting Conference a year and a half or-- what was that? A little over a year ago-- called "What to Look for Today in Control Systems." And again, really, the focus here is on how some of the commercially available products are different or differentiating themselves from each other and what you maybe should think about as you start to investigate systems and think about choosing one or doing a pilot.
So here are just some learning objectives. I'm not going to read these, but learn a little bit about that technology, key building blocks, understand how those technology building blocks relate to features and value propositions. And really, you probably hopefully at the end of the day maybe know a little bit more and be a little bit better able to ask questions of technology providers when they're in your office trying to tell you how great their solution is. So I'm going to start off with a little bit of terminology, some of which I already gave you, right, with that opening picture, right?
But the three main pieces of the system-- field devices, central management system, and then the network, right? You can think about the network in different ways. There's a generic kind of high-level description from IES TM-23. And kind of more relevant to this technology, you can differentiate between the field device network, which really allows those devices to communicate with each other in some cases, and that backhaul network, right, that is kind of bridging the field device to some central management system.
The controller, again, is the most common feel device or the one that probably most people would be thinking about or purchasing a system for, right? It's the device that's going to sit on or near a luminaire and execute lighting changes. So this, again, is a definition from IES TM-23, kind of a generic definition, and a little bit of few extra bullet points to kind of expound upon that, right?
So a controller not only controls but actually can do the physical monitoring of luminaires, can react and respond to inputs that either come from the network or may come from a sensor that's, say, in the luminaire or further down the pole, can implement algorithms and obviously communicates over the network using a network protocol. Gateway-- again, some of this is just for reference, right? I've already broadly described to you what a gateway does.
Here's another formal definition from IES TM-23-- a definition that is really more specific or was probably more written for indoor lighting control systems. But again, you see that in the bullet points here, for the purposes of this presentation discussion, it's really the interface between field devices and a central management system through that backhaul network, if you will. So it aggregates data packets and bridges or connects to another network.
And it often translates between a protocol that's used to facilitate field device communication and you translate to a different protocol that is used for the wide area network. So for example, there may be-- you hear the word "mesh" or "ZigBee network" being used amongst the field devices. And the gateway may translate to Wi-Fi or ethernet or even cellular protocol.
This is a little bit more terminology-- not super-important to understanding how the systems work, but maybe relevant when you hear different manufacturers come in and sort of call maybe their gateways slightly different things, right? So sometimes people will refer to leafs or routers or border routers, right? So you see a little bit of a diagram here and some additional detail, right?
A leaf just transmits and repeats or receives messages. We have-- sorry, transmits and receives messages. A router generates and repeats data or here they're being referred to as packets. And a border router is really just another word for a gateway, right? So something that sits typically at the-- logically the edge. I mean, not physically, but logically the edge of the network, because it is what bridges or connects you to another network.
OK, a couple more definitions that are, I think, important to especially one of the first things we want to talk about here-- compatibility, interoperability, and interchangeability.
You see a few slides here I've updated since the original presentation with what I think are, in this case, slightly better definitions. We're going to want to talk about interoperability, but I want to take a second to differentiate-- or either to say what that really means. Because often, people use maybe all three of these words to mean maybe any one of these three things.
But there's three very different concepts, right? Compatibility is really about devices living in the same environment and coexisting, not interfering with each other. On the other end of the spectrum, interchangeability is really about devices or applications or networks or systems that can be physically exchanged for each other and provide some level of identical operation, right? Usually, that's not 100% across the board, but some level of identification, same operation.
Again, you can think of an A lamp, right, that can be removed from a socket and a lighting system and you could put another one in and it will function, right? Electrically, it'll connect. Mechanically, it'll be maintained there.
But it may provide a different amount of light, right? But those two devices are interchangeable. But interoperability, what we're talking about there is really the ability of two or more, again, devices, applications, networks, or systems to work together and achieve more together than they can do on their own, and most typically or more specifically to exchange and readily use data with each other.
So those two pieces are important. They can exchange data with each other, but they understand the data also and can readily make use of it. That's often what we really want to talk about when we're using the word interoperability.
When it comes to installing or deploying, I should say, a system in general and especially a networked outdoor lighting control system, many people find it useful to think of that deployment process in three different steps. We're not going to spend a lot of time on this, but this becomes I think important to maybe writing your RFPs and contracts and whatnot.
But the first step, of course, is just component installation. And here, you're really talking about mechanical mounting and electrical connections and maybe very basic configuration. But this doesn't necessarily result in a state where the components are operating as intended, right? Where the system does what the manufacturer's data sheet says it could do.
But the system, again, has been electrically and mechanically mounted. System startup, again, is that next set of actions that typically includes things like configuration of system hardware and firmware and software and the things that really make the system functions and capabilities available to the user. So another way to look at that, right, is once the system is through the startup phase, it can do everything the manufacturer told you it can do, right? Everything the data sheet or the brochure said it can do.
But commissioning, then, is the final step, right, where the system goes beyond "it's just, I can do whatever you want," to "OK, I'm now able to do things exactly the way you want, right"? So where the system function capabilities are configured exactly according to user needs and desires. And this typically includes the modification of system software settings to the central management system. So a little graphic here kind of in the bottom of this slide kind of just captures those same ideas in a slightly more concise form, right? Installation, physical configuration, mechanical mounting, startup, logical configuration, maybe getting the network up and running, right? The sensors up and running. But then finally commissioning-- at least for the purposes of this presentation, right?
People will use different words here for these things. But here, we're really talking about functional configuration-- so things like grouping and scheduling and setting up reports and implementing whatever adaptive lighting approach that you're interested in. So with that, then, I'm going to get into 15 things.
I'm going to talk briefly about that if you are again talking to a manufacturer or trying to compare systems, you might want to think about. We'll go through them one by one. Interoperability-- I've already mentioned what this is. But really, the reason you're going to want to think about that is because of what it brings you as a user, right?
It facilitates the ability to integrate best-of-breed components into a system. I don't have to use only components, whether those are sensors or controllers or even software that come from one manufacturer. But if the system is interoperable, I can mix and match pieces from different manufacturers. This allows you to also modify and improve an existing system as you learn what you really need or what. And this, I think, gets back to that learning curve for users.
You know, why do you install a system? And the reasons you think that make sense today may be different two or three years from now. Do you have to rip out the whole thing to go make those modifications, or can you integrate in just the pieces that you need?
Of course, it helps manage the risk of component or manufacturer obsolescence also and facilitates greater competition like when you're writing RFPs and whatnot. Now, there are some-- I don't know if I'd call them caveats, but some other things to consider. Interoperability is somewhat of a complex topic.
I'm going to say a few more words about it in a few slides. But it's really not one thing, right? There's many types or levels of interoperability. You can imagine you might want to talk about interoperability between a controller and a luminaire, between a central management system and the field device network, or even between field devices.
I'll go on here. So there are a number of activities underway in the industry developing interoperability specifications and standards. I'm going to say a few more words about some of them. So it’s just a small laundry list along with some links if you really want to do some more reading or need something to put you to sleep at night.
But here, I'm going to try to again say a few words about what I mean about different levels of interoperability. When people talk about interoperability or develop interoperable, especially communication, networks, often they like to use a model to describe the levels. And the common model is this OSI model. I'm not going to really spend any time on this.
But just, again, if you want to do more reading or want to realize that interoperability doesn't just mean one line in your Spec-- you don't just say, for example, ZigBee, and achieve interoperability-- you may want to have to talk. Or, again, technology developers will talk about seven different layers or levels potentially. One-- I'm going to give you a couple of reference points to how maybe this is simplified down for things that may be more readily digestible to you.
Anybody who has used a computer or a desktop or laptop, whatever, or connected to the Internet, often this OSI model is simplified down to just these four layers here. And again, just to give you a feel for it's not a matter of writing one line or one protocol down in your RFP, here is an example of all the different protocols that are used to achieve the interoperable computing environment that we're all familiar with, right? And so you see there are various protocols that exist even in one of the layers in the application layer or in the transport layer.
It's not-- the market hasn't gotten simplified to just one. And further, building a fully interoperable system requires a different protocol, right, and at least four different layers here, right? So you don't see the same protocol repeated in any of the four different layers.
So on one hand, letting you know it's more complicated than just figuring out that one line or one protocol that I might write into my RFP-- on the other hand, at the same time letting you know it's very doable, right, especially as the market matures and technology developers kind of narrow in on certain choices, right? Because we all know how easy it is to swap computers onto the ethernet and get things to work.
So a couple of other reference points, right, and other ways to think about what are these different layers actually doing, right? And one example I like to use is just to think about how we as human beings communicate with each other and what you might need to specify to ensure that you are effectively communicating with someone else, right? So you might start, for example, at the bottom and say, well, are we going to write or are we going to talk, right?
And then after we make that decision, are we going to write in surface mail, or are we going to use email? What kind of technology are we going to use there? Or if we talk, is it going to be face to face, or are we going to have this other technology in between us, right?
Use a phone or something. How is the information going to be routed? Maybe if we're in different locations, right? Is it going be wired or wireless?
If it's physical mail, is it going to be sent through the air or a railcar or way back in the day on the Pony Express? What language are we going to speak? What dialect are we going to use?
What are we actually talking about, right? If I'm expecting to talk about quantum physics and I'm going to use certain language and you don't have that background, we're not going to effectively communicate, right? So there's not just one thing we need to agree upon just communicating with each other to ensure we're going to effectively exchange information, right? There's many multiple layers here, if you will, that need to be specified in order to, again, exchange information that we can both use, right?
I may still give you information written in French and you'll have it. But if you don't understand French, you won't be able to do anything with it. Another way to think about this, again, is kind of a simple water analogy, if you will, right? So when you look at the simplification here of the seven-layer model, you can think of the physical and data-link layer as establishing the pipes that I'm going to route or transmit data through, the transport network layer-- oops-- about how I'm going to route those pipes from one place to another, and kind of the application layer of thinking about, well, what's actually flowing through that pipe, right?
So is it just bits-- zeros and ones? How might I actually group those bits in certain configurations so they more effectively go through the pipe? How might I compress those bits, right, so they take up less space as they're flowing through the pipe?
And finally, OK, how do I convert them to something that I actually understand? Maybe in this case, 20 kilowatt-hour measurement from a reader, followed by a 21 kilowatt-hour measurement reader. So a couple analogies-- hopefully, you get the points both about maybe the complexity and the value of interoperability.
I'm going to say a word here about gateways, right? I already mentioned that gateways serve as the bridge between systems, right? And they are translating effectively between systems. This can be done at one or more of these communication layers, right? Now, the successful translation across layers requires the device to fully understand how those protocols are being implemented.
And I guess the only one point I want to make here is that it's one thing to translate from one physical layer to another when the physical layer definitions maybe aren't changing, right? So WiFi to, say, just the mesh, if you will. But when you're talking-- when you need to translate application data, well, here, sometimes application data definitions change more frequently, especially, if you imagine, as new features and capabilities are being enabled.
So when you're looking at a system that requires a translator, sometimes to achieve interoperability, you might want to ask the question or think about, well, am I translating application data and today I install a system that's just controlling lights. But tomorrow's system, I want to install sensors. And those sensors are going to be producing data.
As that data flows through the network and through a gateway, is that new data going to be translated correctly? And what do I have to do to ensure that? So there's a lot more we can say about this, but just kind of wanted to make the point there.
So let me say a few words now about some of the laundry list of interoperable and interchangeable specifications that are out in the industry or being developed. Hopefully, everyone's familiar with the NCC136.10 interchangeability specification that allows you to connect, for example, a traditional streetlight controller into a luminaire through a standardized socket that provides physical and electrical configuration parameters. Maybe use some of you are a little bit less aware, but hopefully not.
A couple years ago, there was a new standard-- C136.41-- that added two to four other connectors to that same receptacle, thereby allowing you to send a control signal through the interface, right? And this really has enabled adaptive lighting or we are basically sending some kind of lighting control signal from the external controller that's part of your network lighting control system into the luminaire and into the LED driver or ballast, if you will. So definitely a feature that you want to consider when you're installing luminaires and you might ever want to do adaptive lighting in the future.
In case people are still wondering "is this really out on the market," here I'm just showing you a screenshot from a distributor. Or you can go buy these receptacles. You could retrofit them, in some cases, on your existing luminaires.
Certainly every manufacturer has these available to them now. It's a widely available socket and receptacle. Here's some examples, right, of products on the market that are offering this receptacle.
So a few words about where we're at with interoperability, before I go into some of those other examples of efforts. Today, if you look at most products on the market, that application or lighting control layer is typically implemented in a proprietary manner. And even the way data is routed across the field device in the network is typically done in a proprietary manner.
Where you are starting to see some-- or where you can see, I should say, a lot of standards-based interoperability is at that physical or data-link layer, right? So people are using-- you see the word ZigBee or even in some cases WiFi radios to establish that physical or data-link connection between devices. But remember, this just allows you to send zeros and ones perhaps from one device to another. But the devices may not understand what those zeros and ones mean unless there's the upper layers of interoperability.
Now there are a number of emerging efforts, very new, on the market that are working to achieve application-layer interoperability. There's a number of them I'm listing here, and we'll say a few more words about a few of them. So LonMark is a vendor consortium.
Anyone who's worked in the indoor world, especially in buildings and with HVAC systems, you may be aware of LonMark. They've been around for a while. They have 14 street lighting members.
They do have specifications to achieve full interoperability, including that application layer. But primarily for wired physical implementations, they are trying to work to deliver wired and wireless or hybrid solutions and also trying to bring more offerings to street lighting control. But their history is really in buildings.
Their specifications have been standardized in many cases through ISO or IEC. And kind of very importantly, they do require compliance testing and certification. So if you say your product complies with one of the LonMark specifications, you need to get it tested, and certified and then it'll get even listed in a database.
Here again is just an example of the history of LonMark and their focus really on buildings historically and the broad spectrum of specifications that they've written. You see in here then they do do lighting-- again, not as much as they have done other devices. But to the right here is the 30.0 list of specifications for lighting devices. And at the bottom, you see something for an outdoor luminaire controller-- 35.12.
Now, a more recently launched consortium is the TALQ consortium. And they, unlike LonMark, are very focused on one application-- outdoor lighting. I think these numbers have changed. You can go to the website and look for yourself.
So there's more members and associate members. I think they're up to the 20s. They have developed or are developing a standardized interface including the application layer between the central management systems and the outdoor lighting or field-device network, right? So this will allow, say, one person's software to interact with different persons’ or manufacturers' fields device networks.
It doesn't necessarily ensure that a controller, two devices in the field, can talk to another controller or a controller can talk to another gateway. That may be enabled, but doesn't ensure that. And typically, what people are doing now doesn't realize that.
But really, it allows you to use, again, one central management system or one piece of software to talk to and connect with multiple manufacturers' outdoor field-device networks. So they again have written specifications and also have a compliance testing and certification process. They are really right around the corner of launching compliant products. My understanding as of even a few weeks ago is that they're just working through that final compliance testing process whereby manufactures can say "my product definitely passes, and I can put the logo on my product."
Here's just a diagram again kind of describing what talk-compliant components can achieve, right? One software interface-- central management system can talk to perhaps two different outdoor lighting networks or sets of field devices provided by two different manufacturers. Wi-SUN Alliance I'm going to go through this a little bit quicker, because there's a couple here that are more really relevant to electric utilities than municipalities.
But it's another-- you see the same thing-- vendor consortium, many members working on, in this case, kind of the other end of the spectrum, right? The physical data link, networking, transport-layer interoperability-- basically everything except the application layer, right? Or the translation or the description of what the data actually means.
Their specifications are based on yet again other standards, and they are also doing compliance testing and certification. And I won't spend really any more time on the details here. Again, they're really focused on smart utility networks.
So let me go on to the next topic, right? Luminaire integration options-- I want to enable my luminaire to do streetlight control. I'm going to go buy a controller.
How am I going to connect it to the luminaire? There are a variety of ways to do this. You can buy a device that's external to the luminaire and only can implement on-off control. No dimming-- I might do this through the ANSI three-prong receptacle that I showed you.
Or of course I could do it through the C136.41 five- to seven-prong receptacle. I may do it external to the luminaire. I mean, I may want to do dimming, in which case I could still use the three-pronged receptacle.
But I'd have to figure out a way to get the control signal into the luminaire. I may do that with a wire or a pair of wires. I may try to create a power-line carrier signal over the power lines. I may readily install a wireless radio to go from outside to inside the luminaire.
Probably the easiest way, though, nowadays is to just use the C136.41 receptacle. There are also technology providers that will give you a controller or sell you a controller that you can mount or install internal to the luminaire. This raises questions, though, about who's going to do the installation and is responsible for that integration.
How does it integrate? How does it interact with the driver in terms of maybe it's going to produce additional heat or unintentional radiation? How do I mount the antenna, et cetera?
And finally, in the future, I think you'll see solutions where the controller is integral to the luminaire and really integrated into the driver. Here's just pictorially how an externally mounted controller looks. And then on the lower left here, you see an example of an internally mounted controller and the little protruding antenna at the bottom. And I think in the near future, you'll see controllers that are integral to the-- or internal to the ballast driver.
Input voltage-- not every manufacturer offers controllers that can work with all luminaire voltages, right? So often, you see different classifications-- universal, maybe 240 only or 347 only or 480 only. If you're installing the controller into the luminaire, you may be able to put a transformer in there to allow for a different voltage.
And there are emerging options where the controller is powered by the driver ballast and not by the externally provided voltage. In this table on the right, I'm just showing you an example. I went out-- this is over a year ago-- and surveyed a number of vendors in terms of what voltage options they provided.
And here, you can kind of see the spectrum. Nobody provides every option, although many people through a couple of the implementations can get you all the way from 120 to 480. Lighting control-- if I want to do adaptive lighting, I need to send a dimming signal from this controller into the luminaire.
There are typically two ways people are doing that-- leveraging protocols that were developed for indoor lighting control, 0 to 10 volts-- hopefully most people are familiar with-- or DALI. There are some pros and cons to both. In North America, you're mostly seeing 0 to 10 volt, although there's more interest being generated around DALI because, in particular, of its ability to do two-way communication and talk to the driver ballast. There are some lighting users who are actually very interested in having two-way communication to do asset managements.
So if the driver had programmed into itself its make and model number and some details about its luminaire output, et cetera, and could communicate that back to the controller, well, upon installation, the controller may query that light source and say, "hey, what kind of light source did someone just install me with?" And the light source would communicate back with "I'm a manufacturer A, model B, you know, so many thousand luminaire package," et cetera. And that could be populated into the central management system. So it's a kind of a new capability, and people are trying to implement it using DALI.
I won't spend a lot of time here. Often you use the word-- people, you hear the word "control ready." What does that really mean? If you're just doing a lighting retrofit today, as I know many people are but are considering doing controls in the future, you probably want to install a control-ready luminaire. To me, this means a luminaire that has a dimmable driver and ballast and has a low additional upfront material cost and low future upgrade labor costs to enable adaptive lighting and networked remote monitoring, et cetera, and all the features here.
A number of ways to go about doing it-- I think, again, the most easy way to do it and the way most people I think are looking at it today is just require a luminaire with that NCC136.41 socket. It shouldn't cost you hardly anything extra beyond the three-pin sockets. And some manufacturers are starting to offer it as standard.
And it gives you the option to install pretty easily and simply. You have to make the pole visit, but you can very easily install or replace the existing photo control with a network control. Light-level config considerations, right? So if you are thinking about adaptive lighting and you're going to want to know or think about, "well, what light levels am I going to want to change to at different times," you kind of have to work through this set of questions, right?
What conditions might warrant different light levels? How am I going identify when those conditions occur? Am I actually going to get the light level or power that I want? We could spend more time talking about that in detail, if interested. How do I establish that light level, and how do I get billed for the resultant power level?
For people who want to think through those questions, there's a very useful document that was just produced by the FHWA. There's a link for it here. And it sort of walks you through some of this. It’s not very straightforward, if you will.
Again, there's guidance on maybe different light levels that you might consider for different conditions. But you're really going to have to think through "how am I going to identify when those conditions occur? Do I need to install some sensors to determine that?" Et cetera, et cetera.
Energy metering-- right, this is again if you're going to be setting different light levels and you want to monetize those energy savings. Many products actually have the ability to meter the power or meter over every 15 minute-interval the energy consumption of the load connected to them or the luminaire in this case. But then there might be questions about-- or there are questions about the accuracy and precision of those measurements, and of course the data security transmitting that data from the device through the network maybe back to the central management system.
As you might expect, right, there's utility meters doing this every day at your home and in your office building. Those meters are-- the accuracy is specified or evaluated according to these ANSI C12.1 20 standards. But because they were developed for building meters, right-- much bigger loads-- they're not directly applicable to a much smaller and unique type of load that an LED, for example, streetlight is. As a result, the NCC136 group is working on a specific new standard for accuracy of the meter readings, if you will, from these devices. So in the meantime, until that's out, you're going to need to take the manufacturer's word for what the accuracy is, or maybe talk with your utility about whether they can verify the accuracy or whether it meets their needs.
Here's some examples of different manufacturers' marketing claims around accuracy. In some cases, you see they refer to the same standard-- 12.1 or 12.20-- and claim different numbers, right? On the top left, they say plus or minus 2%. On the bottom right or top right, they say half a percent.
That kind of gets into the details about how the standards work. We don't have time for that today. Another thing being discussed in many municipal utility disk interactions is "do we really need to work with meter data in order to enable adaptive lighting?"
And here's what some folks are suggesting, right? Today with your fixed tariff, you're being billed based on a model of on-off usage, right, and the assumption that you're going to run at 100%. But that's just the model, right?
That 100% power of course might change over time. And even the on-off use may fluctuate over the course of the year. But if that model is good enough today, some folks are saying, "well, what if we just came up with one or two or three models that capture, say, common or typical or just even different enough adaptive lighting usages and go do kind of a mathematical calculation of energy use and just bill you according to one of these different models?" So here's just an example, right, of two different models, one where-- I mean, again, the 50% for four hours in the middle, and then another one where I'm going to dim all the way off.
I'm going to turn the luminaire off for four hours a night. If I had enough of these, might you be able to talk to your utility and say, "what I'm doing is kind of mostly like model one or mostly like model three," and you'd be able to agree to bill according to that mathematical calculation of energy consumption? The tradeoff for the utility here is "I will have to accept and work with all that data that's going to be produced by each streetlight."
OK, we're getting a little short on time here. So I'm going to go a little bit more quickly through some of the remaining differentiators. Location commissioning-- there are two different ways, two different key ways-- a number of different, I should say, key ways this is being done through commercially available products. Some solutions don't offer any location, any ability to capture where the controller was installed. Or others, the location is assigned from a database.
Probably the two most common offerings are where you capture the location with a field device. So maybe read a barcode off the controller. You let-- the field device grabs a GPS signal, and it connects the two together and uploads it to the database.
And then the other end of the spectrum-- some of these controllers have their own GPS receiver, so all you've got to do is mount it and walk away. And once it locks in on a GPS signal, it'll communicate that through the network to the database. So key things to consider here of course-- are you going to use that integral GPS functionality once?
Does it make sense to pay for it? Conversely, how long does it take to get an accurate GPS location? And therefore, do I have to sit there with my handheld device in order to get an accurate location? This really gets into are you installing a thousand controllers total, or like some of the big cities, are you trying to install 1000 a week?
Sensor options-- I kind of went through this a little bit. But there's certainly a wide spectrum of what different technology providers are offering-- a lot of sensors that you can think about and even different variations amongst them. So I won't spend any more time on this, but these are all commercially available options today.
Some things to think about there are, along the lines of "where's that sensor going to be located, and how is it going to get its sensor data into the network," right? So is the sensor-- could it be integral to the luminaire, or is it going to be external? Can it communicate its data through, say, that seven-pin interface, or do I have to again drill wires or install some other means to get the sensor data into either the luminaire or the controller and into the central management system?
And once again, will the system understand that data? That gets back to interoperability. Does the sensor speak a language that's consistent with the rest of the system?
Some examples of different sensor types and integrations that are done in the field today-- everything from just a separate device on a pole all hardwired into a luminaire to in the lower right-hand corner something fully integrated into the luminaire. Network architecture-- so here, you're getting into wired versus wireless. Maybe you've seen mesh versus star.
In this, there are the number of tradeoffs or pros and cons here that we probably don't have time to get into. But you'll want to ask your technology provider how their system works and let them describe the pros and cons to you. One of them very commonly is just about the number of gateways that are required.
Gateways cost extra money, and you're going to have to-- I mean, cost money, of course. And you're going to have to find places to mount them in. And there are additional maintenance points and energy consumers, if you will.
Here are the two most common network topologies, especially for wireless in particular. So you'll see mesh versus star. Mesh is really where each device sends out data, and the data maybe only can get to an adjacent device and it gets repeated, right? So you're really relying upon the ability of each individual device to be able to hear and repeat data from adjacent devices or nearby devices in order to get that data all the way into the gateway and into your central management system.
In the star configuration, each gateway talks individually to the light source. So one other differentiator or way to look at this is in a mesh net system. The mesh forms the network, and gateways are primarily used to interface to other networks, right, and make that connection to your central management system.
Where in a star configuration, it's really the gateways that create the network, right? Each one has a coverage area. And once you put those up, any device mounted in that coverage area will then get connected to the network.
Now, there's a couple slides here just showing you how people go about planning for mesh installations. Again, in order to bring data from a given device out to a gateway, you need to think about, well, what's the-- how am I laying out the different controllers, and will that data be able to find its way to a gateway right as it's broadcasting and repeated and repeated?
You'll want to ask a manufacturer or talk to your coverage area and have them maybe do a simulation for you, to show you that the number of gateways they're installing is sufficient and data will be able to get from every luminaire, find its way through the other luminaires or through the other controllers, eventually reaching a gateway. Here, you can see an actual diagram showing how the data is being routed from device to device to device and eventually getting to a gateway. And you might say-- a quiz question here would be to say "where do you think the gateway is?"
Actually, it's a little clearer here when you see the number of hops that data needs to take to get from one luminaire to the next to the next and eventually to the gateway. And the quiz questions should be more straightforward here. When the number of hops is the smallest, that means the gateway is probably nearby. And in fact, it's right there.
Wireless spectrum-- right, this is the frequency, if you will, that wireless radios are communicating over. And there's really two broad categories here. There's unlicensed spectrum, where anybody can operate according to certain rules, or licensed spectrum, where access is granted to just one user.
Some pros and cons to both-- most solutions on the markets are operating in unlicensed spectrum, but not all, right? And so this is something to consider and maybe ask questions about, especially depending on your operating environment. Backhaul selection-- how am I going to bring data from gateways to my central management system? Again, most commonly today, people are deciding between running fiber from the gateway over to wherever I'm housing the central management system, whether that's in my office or whether the manufacturer is hosting it for me in the cloud or cellular, right? So this is where the gateway has a cellular radio in it and can connect to the third-party cellular network.
A central management software-- so I already alluded to this, right? There are two main offerings on the market today where-- and some vendors offer both, right – where that server and database is hosted by the technology provider in the cloud, if you will, or whether it's provided to you and you have to install and maintain it locally. Certainly very much variation in capabilities and features-- a few things to consider in the subsequent bullet points here as you're maybe asking questions or wanting to evaluate software.
This is certainly something you're going to want to get your hands on and see live and ask yourself, "who's going to be using this software, and how do they need to work? What levels are-- are they more visual? Are they going to be able to go through 10 layers of screens, whatever, to get to the data they want?" Et cetera.
Here is kind of a graphical depiction, again, of the two different hosting types, right? So vendor-based hosting-- you have a remote desktop. You're connecting through the Internet to the solution being hosted in the cloud.
Some pros and cons in the bullets below to consider for each option. Here is how user-based hosting would work where you would install the application and have your own database. And you could either remotely access that or directly access it on the same network from a desktop or laptop computer.
Obviously, a different set of tradeoffs here-- you can control their performance. You get to dictate security and availability or define it, I should say. But then you have to maintain and operate, if you will, and manage upgrades and this that and the other for the software.
Security-- really not any time to go into this in detail. Probably really two points I want to make here-- security is, once again, not just a feature or even a set of features that you're going to write into your RFP. Security is a process and a commitment, just like it is everywhere else, whether that's in your home or on your IT network or whatever.
So when it comes to this, you really want to create-- start a conversation with your technology provider about what's important to you, take into consideration how your system's going to be implemented-- on remote or cloud-based access. How you're going to-- do you have to go through the Internet or not? Those are all decisions and questions that require discussion and maybe different levels of technology or technology solutions to mitigate the risk to the level that you want when it comes to security.
Here I'm just showing you an example that there are network security certification tools for applications where you really need to ensure high levels of security. Typically in federal environments or defense environments, there's two main techniques people use. There's FIPS and Department of Defense insurance certification and accreditation process. You can read more about those if you think that applies to you.
And the final couple of points-- data access, right? Once I install this network lighting control system, maybe that's my area in the city. I do street lighting.
But is anyone else going to be interested in this data, and is it possible for me to get data out of the system into somebody else's system? So here, you want to again just have that conversation, ask questions. Does the technology provider require fees in order for you to export the data? Do they have an API?
Is this kind of a standard software wait for one system to query another and either put information into or pull information out of a system? Quite a wide variation on the market in terms of how or even if they facilitate communication with other systems. And finally, business models, right? Kind of-- we already talked about the issues around cost and value propositions and ROI.
And sort of in response to this, many technology providers either directly or with partners are offering a variety of opportunities or a variety of models to finance and ultimately pay for the installation for the deployment of these technologies. And these of course even include revenue generating and sharing opportunities.
So those are all things to be considered. For sure, I think if you're going to do an investment, a payback analysis, you're going to want to try to think beyond simple return on investment and look at things like total cost of ownership or total value of ownership and how different value propositions may mean something to other departments, and what other revenue-generating opportunities might be and how they might be factored into your payback analysis.
And finally, kind of related to what I already mentioned before, it's one thing to want to share data with other systems, pull data into or I should say out of your system. But if I really want to fully integrate this system with something else, that's another set of discussions and potentially technologies that need to be deployed or made available. And so just some things to consider. And here's an example of how that's been implemented from one technology provider through an API. So here, you're connecting an asset management system with a lighting control system.
And I guess my concluding example is just pointing out that in many cases, the connection of systems is maybe more available than you might realize, right? So here is a snapshot of a manual from a wireless vehicle detection system that a major city that we worked with had already deployed and didn't even realize that they could connect to a streetlight control system. But in fact, there is the ability to export data from one system to the other.
Here's a screenshot of data we actually collected through that export capability. And that could be fed into the control system to do adaptive lighting. So the final slide-- hopefully everyone's already aware of this.
But if you are interested in deploying networked outdoor lighting control systems, the DOE SSL program has produced now two versions-- we're on the second revision, I should say-- of a model specification. So it kind of goes into many of these topics in more detail. It gives you user-selectable options for many of the features and capabilities I've described and some that I haven't, and really at the end of the day, I think, is a tool that can help you facilitate conversation with the technology provider in your office or through an RFP. And with that, I will stop. And if we have time and interest in some questions, I'm happy to answer some questions.
OK. Thanks, Michael. Wow.
So that was a lot of technical detail. And I'm sure for people that haven't heard all this stuff before, it seems overwhelming at this point. But I just want to point out: of course, if we look at these other systems that we use every day, like the Internet and our cellphones and the smartphones all of that, if somebody was talking about all the different protocols, communication protocols and so on, it would be equally complicated.
So the fact that there's a lot of complexity in here doesn't mean that we're not going to have a user-- Michael didn't spend a lot of time showing the graphical user interface there, but there are a lot of systems that are being built to basically enable the average folks like me to be able to use these complex system. But there is a lot of complexity that underlies it. So I think you've got a good-- I think you've got a good feel for that.
We just had a couple of questions. So let me just launch into those since we're over time here. Michael, could you discuss in plainer terms how these options relate to lowering our electricity use? Are any of the controls cost-neutral, and would they be able to pay for themselves through decreased energy use?
So I would say at today's prices and from talking again with a variety of user types, people are going to probably struggle to pay for the systems. Again, it depends on what kind of ROI or cost-recovery mechanism you're going to use. But people are going to struggle to pay for the systems in two to four years or something, a simple ROI just based on energy savings.
In fact, many users I think are struggling at today's prices to justify the systems even for just energy and maintenance and reduced maintenance costs. So typically, people I think are looking for value propositions beyond energy savings, right, and maintenance to justify. And I think that'll change in the near future, because I think cost is going to come down as some of these interoperability solutions really hit the market and then facilitate more competition, facilitate integration of that controller into the luminaire.
Costs will come down, and you'll see more systems, I think, that can pay for themselves just from energy or maintenance. But I think most people, especially most municipalities, are probably going to need to consider other systems. Now, on the other hand, we're seeing some utilities justify the technology just for maintenance and maybe energy.
Well, they're not really considering energy, but just maintenance. But that's because they have giant coverage areas, right, in some cases. And maintenance is a big cost to them. So hopefully that sort of gives you a feel for where I think things are today on that.
OK, and let me combine the last couple. Are there examples of successfully operating systems out there, and are there examples of municipalities who have leveraged these value-added capacities like the-- what you were just-- all these new features and things-- telecom, et cetera?
So certainly, yeah. There's a number of examples of deployed systems, and maybe different levels of press, if you will. But I mean, there's systems in Glendale, Arizona. Of course, Los Angeles is actually on their second technology solution, if you will, for this capability.
So the number-- and quite a few installations. I wouldn't say it's widely prevalent, but there are a number of installations out there. The use of kind of some of the advanced features-- pretty much any of the advanced features, I would say-- is really still kind of-- it's still early days, right?
So there are a number of cities that maybe initially installed a system just for control or maintenance, I should say, and some level of adaptive lighting. Maybe they only did it in a part of the city.
And now as they've gotten comfortable with it, they're going back to their provider or even considering a different provider and saying, "OK, now I want to do parking management, right?" How would that work? What's that going to cost?
Do I want to put that everywhere? What would business model look like, right? Are we going to generate revenue, et cetera.
And so those I think are kind of going on on definitely a much smaller basis. And almost every occasion of it that I know of is unique in this country, maybe-- unfortunately, there's probably quite a bit more of that going on in other parts of the world. But in this country, it's still very early days, I think, on pretty much all of those other applications, right? Whether it's, again, parking management or air-quality monitoring, or gunshot detection, et cetera. So there's examples of it, but not widespread.
So-- and that would also apply to the actual sort of revenue generating opportunities here? How much money is actually being-- I mean, I've heard, right? There's a few-- aren't there a few cities that are actually seeing some revenue streams from some of that stuff already?
Yeah, I mean, so of the revenue streams, I think the most widely deployed revenue generator is really kind of more adjacent to this technology, right? It's the installation, the small cells, and whatnot where you're getting revenue from the carrier, right, for something that's mounted on the pole. And there are some people that are doing that that are saying, "well, can that thing, that small cell, be integrated into the luminaire or into the controller that gives me lighting control capability also?"
But the other revenue-generating opportunities-- again, it's really case-by-case basis. It's a new market. So you can imagine it's at least two people trying to figure out how to split a new revenue stream.
And often, it's more than two, right? Or maybe there's the technology provider, the municipality, some third party that's going to run the app and market that to users, et cetera. And how much you can get and how to split up is-- it's a brand new market.
And everyone's maybe trying to get the most for themselves or trying to take advantage of the lack of sophistication of one or two of the other partners in the discussion. So I certainly-- it's way too early to say, hey, there's anything typical at all. Is it being done? Yeah.
Is there anything typical about it? I would say it's-- no. It's way too early.
OK, well, that about wraps it up. I want to thank everybody for participating in today's webcast. That was brought to you by the U.S. Department of Energy. We hope you found it useful.