Good day, welcome to the Talking Operations web conference on adaptive software light or ACS-Lite. I will give a brief intro before turning over to Eddie Curtis, our moderator for the seminar. Be advised today's seminar is being recorded. A few logistical items, will last approximately 90 minutes, the final 20 for Question and Answer. If you think of questions, I encourage you to type it into the smaller text box underneath the chat box. Indicate who the question is directed toward. Make sure you are typing into the thin text box, not the large white area. Unable to answer during presentations, but some of the questions will be used for the Question and Answer session in the last 20 minutes of the seminar. If you would like to zoom in on the slide showing on the screen, you can use the bottom left magnifying class icon. The session is being recorded, a file containing the audio and visual will be posted on the National Transportation Coalition website within the next week. I will type that address into the chat box shortly. We encourage you to direct others in your of your office unable to attend to the web recording. Attendees will be notified of availability of the PowerPoints, recording and closed captioning of this seminar. Eddie Curtis, moderator, Mr. Curtis is a transportation management specialist in Atlanta. Serves as program manager for traffic signal timing program in the Office of Transportation Management in Washington D.C. Previously Mr. Curtis worked at the Los Angeles Department of Transportation before joining Federal Highway earlier this year. Eddie will introduce our first speaker. Thank you. I would like to say good morning or afternoon, depending on what coast you are closest to. I welcome you to the webcast on on ACS-Lite. We have slightly more than the normal number of speakers. I am going to limit comments to just a few things for for the introduction. ACS-Lite is the latest innovation in signal timing technology 90% of the traffic signal systems in the U.S., ACS is to have a very low cost deployment. I will introduce with that our first speaker Raj Ghaman, the research and technology for federal highway administration. Over 30 years of experience at the federal, state, county, city and private sector, graduate of the University of Michigan, post graduate degree from the Catholic University, and I will turn it over to Raj. Thank you for the introduction. My slides relate to the overall program, the exception and inception of the ACS-Lite program. A little background, if I can get my slide slide up and downer working. Back to the 1970s, for those of you who are my age. The UTCS, Urban Transportation same algorithms developed, obviously the technology in the 70s was different than today. Today's modern controllers have more. In the middle 1990s, the federal developed, a full-blown software, developed under roads and tested in northern Virginia, OPEC tested there, Chicago, and roads in Seattle and thank you thank you son very expensive, brand-new system, a very high-end system, controllers, because each prototype is resident at each intersection, so it's a very distributed system. As we looked into future, one thing management asked us to do was address with a low-cost solution for our closed-loop systems. Big cities, even Houston, had have closed-loop systems, so we embarked on a program, ACS-Lite. In order to make a low-cost solution would be to retrofit into existing systems. There should be backward compatibility, those kind of things. Early on we thought about, if we are going to do a retrofit solution we really need to work with the industry, ended up writing a letter to Them a, the signal manufacture manufacturers to work with us. We got four nominations, those shown on this slide, and the rest, University of Arizona, and ITT Industries the software what we did was develop a common algorithm for ACS-Lite, but for each application, what is the McCain or PEAK application, we developed an API, Doug will talk about the system architecture later on. Our ACS-Lite connects to a master, closed loop situation, and provides the essentials, intelligence to the local signals. That's our team. Various people, and then as we completed the laboratory testing, so forth, we embarked on where we want to field try these algorithms. working with Econolite, the first site was in Gahanna, Ohio, you will see attributes of that site later on. Tested there, application, next application was Eagle signal application in Houston, and two weeks ago we finished testing PEAK application in Braddenton, Florida, about hour from St. Petersburg, and in El Cahone, South of San Diego. I wanted to share with you some results. This is a slide before and after a number of stops, having a floating car type of technique. To summarize the benefits in Ohio, the savings to the motorists in terms of stops, delays to the tune of $88,000 a year. In this case, travel time reduction on state route 6 in how fast Houston, and the savings there. I don't have a slide from Braddenton, but initial results show that the savings to motorist necessary in reduction of fuel use was $36,000 or so. The objective in what we have done so far. That kind of wraps up my presentation. Thank you, Raj. I wanted to go over, if anyone has a question, chat window on the right-hand side you can type a question at any time and we will address all of them at the end. Next speaker is Dr. Douglas Gettman, research projects manager for the consulting group of Siemens ITS, Dr. Gettman and a past FHWA Eisenhower fellow, from University of Arizona in 1997. Before I get started I want to recognize our partners in the program. University of Arizona, Larry Head, and at Purdue, Darcy, who helped develop the algorithms. The other guy that's a key contributor to the software and program is Steve Shelby who works very closely with me. I was not the only person responsible for developing this system and they need to be recognized as well. As Raj mentioned, ACS-Lite is an adaptive software control system for closed loop systems, to provide integration, cooperation with the widest number of field systems we call an API or protocol translation service. This picture shows basically the field system architecture. ACS-Lite is deployed on a field processor now, an embedded pc platform, communicates with the field controllers using NTCIP where the vendors have not SPTD objects the API is included to translate to Eagle, econ protocol, Econolite protocol, PEAK, so on. We deploy the field processor in the cabinet where the field master would be or is, depending on the particular vendor system we are deploying, and the communications to each of the locals is through the vendor in the field, in the case of McCain. In the case of PEAK and Eagle ACS-Lite is performing the job of the master, we replace communicating directly in the translation component, over serial we have specked a minimum bandwidth requirement of 9600 baud is a little more con constrained, we need a little higher speed than we expect 9600 baud is the minimum, and maximum size of up to 12 controller controllers. ACS-Lite also supports IP communications. If you have a newer vintage system using IP we could support many many more controllers than just 12 on one communications channel. The other key element of deploying ACS-Lite is detection, the adaptive systems need surveillance to operate appropriately, and we have spaced this kind of basic detection layout. The blue highlights on this screen shot are showing where we would anticipate the detection to be needed. So we need advance loops on the approaches to coordinated phases we call profile detectors, and at the stop bar for tuning splits. My comment on the side, right side, for the PEAK tests we are able to use those for both split tuning and offset with good success. So, the key is, in most systems that are semi-actuated now you would need to add detection at the stop bar of the coordinated phases. If you have a system with these setback loops, 50 to 75 feet from the stop we may be able to operate without additional detection added. The second piece is a firmware upgrade on the local controller controllers, and Gary and Mark and Pierre will talk about that later a phase timing status object. By object I mine piece of software data on the controller. Detector status object, and configuration elements that allow ACS-Lite to tell the controller which detectors are required for which type of algorithm. Those objects are pulled by ACS-Lite once per minute, which is really the key to making this system work in a low bandwidth communications environment, but the objects include second by second accuracy of the detection and phase typing status during that minute. So it's bandwidth efficient, but includes second by second accuracy. That's the key. We take the minute by minute polls, stitch them together in cycles and look at cyclic performance measures to split. Three key elements to the ACS-Lite algorithm architecture. In this phase we focussed on the run-time refiner, here in the middle of the cycle by cycle optimization of splits and offsets of each controller on the second by second, controlled by the local controller. ACS-Lite is not controlling each intersection second by second. It downloads new splits, new offsets about every five to 12 minutes, and the local controller is using its gap out extension logic to manage the second-by-second changes to traffic. In this way it's a little more robust than second-by-second control. The other com components we haven't focussed on is time of day tuner and a little about the time of day tuner. This piece is what a lot 6 you out there, traffic engineers are looking for, long-term maintenance or tracking of changes to traffic pattern patterns day by day or month by month. So now adapting to changes in real-time but what we really want, if ever Friday we're adapting the offset or the splits to make them larger, smaller, to change the way the little controllers are operating because Friday is different than the particular base line patterns, instead of re-learning that every Friday we will change the base line settings so that the next Friday it just picks up where it left off last time. The a adaptive control fill philosophy we adapted, called adapting splits, offsets, downloading the splits every five to 15 minutes, roads, o pack and other systems were not doing a heavy traffic model based approach. There aren't many parameters, many configuration options. It's really very simple stuff, although the algorithms are significantly complex to compute the new splits and offsets, but there's not a lot of things that have to be calibrated or changed to make this thing work right out of the box. So for splits we use a performance measure caused phase utilization, and for statistical profiles. If you are familiar WITH scoot, it's similar to the kind of performance measure that SCOOT uses. This is just a car cartoon showing the detector vertical bars, the different intervals of a particular phase. We are getting the occupancy values every second and cooer relating them with the phase timing information to red green and yellow. Instead of having one occupancy number every minute we have one for every interval. Some screen shots, a time history of the phase timing on each intersection here. If you look at this, this is a list going back for, say, the last 15 minutes. You can see how the different phases have different times based on if they are gapping out or not. We use that correlated to the detector, and occupancy values of a particular detector at this intersection. We match those two up into the individual cyclic profile and average them here to get the average occupancy during each interval. Then for splits we are attempting to balance the phase utilization measures on each of the intersections. This is a screen shot from the Braddenton field site, still up and running. I took this Monday at 7:00. You can see at this particular intersection, the middle of middle of the system you have pretty good showing the ring, barrier diagram of the controller, and see phase 1, 2, 3, 5, 6, 7, 8, all low; and phase 4 is red. It needs some more time. ACS-Lite would probably steal some time from 2 and 6, and push that across the barrier into phase 4 to give it a little bit more flexibility. that's what we do for splits, a quick overview of that. The other component is cyclic occupancy used to tune offsets. In the same way we do the data for matching splits, we match up the data for offsets using the stack statistics of the flow approaching each coordinated approach to the intersection or the cycle. This blue profile here at the bottom is showing the average occupancy on the cycle on Wong approach one approach to the intersection. This green bar is showing statistically when this phase that that traffic is being served by is green. This little piece here is the most important to understand, this is showing the return to green behavior; say ing that during all of these times I am underlining, Phase II, for example, green 100% of the time, the last 15 minutes of cycles, that phase has been green during those seconds of the cycle all the time. These little bars down here saying once in a while one or two cycles of, say, the last five or six, it returned to green early. One thing interesting to note, sort of new, this visualization of the earlier return to green behavior. ACS-Light is using that as you will see on the next page. We look at detector profiles for both inbound and approaching Phase II and 6 and leaving the intersection to the next intersection. So we are looking at minor modifications to the offset, either earlier or later so we capture more of the traffic approaching this intersection. Here we have a little bit of this coming late. It's arriving to the intersection after that particular phase has already turned red. Here you have a bunch of people waiting at the intersection before the light turns green. We are making these adapt adaptive modifications to strike a balance of how much more traffic we can capture at this intersection and not effect the adjacent intersections. We did use a traffic responsive offset selection method, both the selection method and tuning method available in ACS-Light. In terms of future directions, our primary goal is two-fold. One, to implement the time-of-day tuner to get seasonal tracking of traffic, changes over time we can modify the baseline settings as schools start and so on, and also to tune when the time of day pattern is switched. Now whatever the time-of-day pattern the traffic engineer determined to use, we use that, implement, actually changing the time-of-day patterns by ACS-Light. Whatever the pattern is supposed to turn on, say say 7:00, but we think it may be useful to change when the pattern turns on, start earlier, or leave it later if the peak doesn't start at 7:00 a.m. That goes hand-in-hand with cycle time tuning, something entire desirable, as well as modifying a grid rather than arterials, weather responses, interchanges, coordination, all this is good stuff to be worked on in the future. So in summary, I know this has been a quick overview, I see a lot of questions flowing through on the chat here. The work works in a ninety 9600 baud, supports IP, and need one detector for every phase to do split tuning and advance loops on coordinated phases for offset tuning. We need NTCIP compliant controllers or translators with the firmware upgrade. For PEAK and Eagle systems right now we are replacing the master with the ACS-Light processor as the master. I put Econolite in parentheses; it works, the system will respond to the box as a master. In the field deployment, and Gary and Tom will talk about this, the approach used was a second communications channel, the masters talking to all the locals to give central support, and ACS-Light is talking in TCIP. Deploying a new master, and and the ACS-Light master will talk to each of the field processors using native protocol. Can work essential, communications to the field, really a set and forget type of application, really almost nothing to tune or calibrate. You definitely want to watch it when you first deploy it, but it's not susceptible to turning portion estimates or various other things other systems need. That's all I've got. Thanks, very informative presentation. Our next speaker is going to be Thomas Komlanc, assistant engineer in the city of Gahanna, Ohio. Side note on that, Gahanna was the first test site for ACS-Light, I believe running since early 2005, correct me if I am wrong. I will introduce Thomas, assistant city engineer for the city of Gahanna, Ohio, there since 1997. Received bachelor of science degree in civil engineering, and a registered professional engineer in the state of Ohio. Thank you. The map in front of you is basically a regional map. You can see Gahanna is a suburb of Columbus, a population base of 34, 35,000 residents. Next exhibit on the screen, more local map. We had nine intersections on the Econolite test site. As far as test site goes, the airport is to the South, the belt around Columbus was in proximity and we have an interchange there on Hamilton road. Immediately North of the interchange, Morrison Road, services business and industrial tax base, and further to the North a school zone, two principle arterials that cross, and a business strip-mall development. From the city perspective, let's see, we last did our signal timing updates in 2001, so when we went to test in 2005 we figured we would see some benefit, but didn't know how much we would get. We did see some benefits. Intersection 1, southern end of the project, typical during the P.M. peak, people heading home from work, that signal backed things up on the Interstate there, 270. As a result of ACS-Light being deployed, split times adjusted we were able to get the backup adjusted or eliminated at times. another benefit was within the school zone. When school lets out they have about 20 buses that let out, a hard-wired preemption. We did not see the backups along the corridors we typically saw after the introduction. On Hamilton and Granville where the two principle arterials intersect, we had main line progression going well there, but Granville backed up. As a result of ACS-Light we did a volume balancing and worked out to the benefit of all motorists going through the intersection. As a result of optimizing the timing, development occurring, we recognize capacity deficiencies and in the morning people heading to work, getting on the 270, increasing efficiency of the system, we experienced heavier backups trying to get on the interstate, and capacity on the ramp there, backed up to the North. We recognized there are some issues there, but not a result of the system. It's along the lines of capacity. Lack of pavement. Going through the first test site I think we had issues with the detector fail safe mode. When a detector wasn't called over a certain period of time it would go into a fail safe mode, provide a left turn so we would get some phantom calls. We have that figured out and things are working okay. As I guess as as far as downward compatibility, deploying new controller and hope to have the interface with ACS-Light. Beyond that I would like to take the time to thank FHWA, Siemens, Econolite, Path Master, and the Department of Transportation for making this possible, Raj, Doug, Steve, Mike, I am probably going to leave somebody out. But a lot of work and time went into this. We are very appreciative of all the efforts. That's it. Okay, I am going to keep moving along. We have four additional speakers -- excuse me, three. Next speaker is Mark Hudgins, can Siemens Eagle, degree in electric engineering, director during tenure in traffic industry, involve in many studies for design and new approaches to traffic flow, including hardware and software. In addition to other things mentioned, very involved in standard traffic software products. Familiar with the advanced technology of a adaptive projects, including Scoots, and now ACS-Light. Thank you Eddie, and good afternoon to everyone. I was excited to be chosen as part of this panel. I believe it all turned out to be beneficial to us and eventually to the motoring public. We have been involved at Siemens with a number of control strategies, approaches, done studies, for a longtime recognized the need for a low-cost, easy-to-install traffic a adaptive system. We believe developing an easier to use implementation strategy is very important. Along with the FHWA, who recognize the need for closed-loop environment because of the large number of closed-loop systems out there, we chose to volunteer to be on this, were selected to contribute market information. A number of meetings, in which we had strategy sessions, brainstorming situations, gathering information from various manufacturers, and gave input from our history, listened to a lot of input from other manufacturers. It was very helpful because we all felt like we were a big part of this program. We recognized early on as a team that there was a need for consistency in procedures and interactive protocol so there was commonality between different manufacturing systems. NTCIP, the national standard protocol, was chosen to be the key protocol used in the ACS-Light system. We recognized the need for minimizing changes in the field. To make a system easy to use it had to be something to implement with as few changes as possible. We reviewed a lot of things with controllers as far as the data input to provide data on ailing algorithms and how they would communicate back to the controllers. It was determined a unit to replace the master controllers was the way to go, and it would allow the most flexibility for a system. The system also is designed to utilize structure as much as possible. Some might have to be upgraded, but there was a minimum that would exist with and create adaptive control. The Eagle developers started developing, adding unique objects to the format we already had. A lot of developers in the transportation engineering professionals reviewed, looked for potential problem areas we saw within the configuration. We did testing, tried to check for standard traffic control methods normally used in closed-loop systems, got feedback. There was a lot of interaction during development, especially with the software development, Dr. Gettman and others. We selected a beta site. One thing we found out, there was a lost potential applications, we got a lot more people interested in putting in a beta site, anxious to support this. We finally selected a site in Houston, close by to us, worked in conjunction with Texas on state highway 6 just outside of Houston. The beta site installation, I guess, went in very well, a relatively short time frame if you consider it was a first-time installation for us. We worked with, local people out of the Eagle products group, and Doug Get man. We have done done a lot of installations on adaptive control systems. This was familiar to compare to we ran into a few unanticipated challenges, as you might expect. I put down a couple of things. One thing we ran into causing a short delay was issues associated with had you have phase sequence changes, by time of day, set up for normal use. We made software changes, overcame that. Some of the controller timing and synching issues associated with the local intersections and the ACS-Light program and algorithms, and then some standard issues associated with retrofitting equipment, so forth. All in all it went pretty fast, didn't run into anything that really became a major problem. I thought that went pretty good. Looking forward, we obviously see there's a lot of potential applications in the future, so we're obviously trying to let everybody know about the potential applications, advantages. There's many many places that it appears it's useable, applicable, and pretty straightforward to put in. It can run at 9600 baud as Doug outlined. That may require an upgrade, but can be installed in an inexpensive manner. As far as less detection than a lot of the ACS systems in the past, therefore the detection quest costs, new detection in some cases not at all. So far works with in-ground loops and video detection, also other methods, applications we will look at to go through all the detection methods and see if there are any problems we might run into. It's currently, of course, recommended for corridors and operates best for optimizing plans in those applications. For the future, we think and hope that some more networking capability will be applied, and obviously we think the program and additional features will grow, have things added to it as we learn and get more applications in. Program more things in, try some things. Upload/download capabilities, timing logs, et cetera, other things planned for the future. The bottom line is it was a very straightforward program for us, we enjoyed being part of it. I would also like to think all the people, Federal Highway and other payment ant participants helped us, allowed us to be part of the program we are very excited about, and it came out real well. That's all I have. Thank you, Mark. We're doing pretty good on time. I want to move thru this because we have many, many questions. Let's go right ahead, keep moving along. Next speaker is Gary Duncan, senior vice-president and Chief officer for Econolite technology, for business development efforts. 30 years of experience in the transportation industry, involved in the design of traffic control equipment and management systems. Involved in a number of standards, and the oversite committee, member of NTCIP, joint committees. Gary has a bachelor of science degree from you UCLA and the executive management program. Good morning. I would like to cover the project, and implementation issues we faced, what we stey as the outlook for Econolite. We had an an enjoyable experience, and I thank the rest of the team. Showed how the industry could come together as a diverse group, accomplish quite a bit in a relatively short period of time with some really positive results. We were involved at Econolite from the very outset of the project and were in somewhat on the bleeding edge, the first of the four Them a vendors to implement the ACS-Light object set within our controller. Our initial efforts were focussed on the architecture of the design so that we could rapidly get something into the lab for testing and into the field. That consisted of looking at communications architectures, design approaches with the research team, and working with the research team on coming up with a set of ACS-Light objects. The preliminary concept that was proposed was working directly with our on-y street master, communicating with it, that proved to be somewhat impractical because of high development costs and presented project risks. We came up with an approach, a separate communications channel. The use of NTCIP and defining a set of ACS-Light objects or an ACS-Light management information base or MIB allowed the development teams to work independently. The initial work involved, of course Siemens on the site, and the lab simulation work, and at Econolite we were all working independently together, but when we brought all the products to the lab to work, we were pleasantly pleased that things worked together once the interface issues were worked out. This led to no major surprises in the test in Gahanna, ready to go after the lab simulations. In the implementation, Tom outlined the actual test area in Gahanna. I would like to cover a little bit about the control equipment that was that was there. We had lab simulation tests in the ITT facility in served to shake out the architecture and the algorithms that Doug and his team were developing. We modified our standard ACS level 1b software controller, modified to implement support for the a additional ACS-Light MIB objects and worked with the research team to provide access to other objects within if they were looking for data that was NTCIP 1202 objects we currently weren't supporting. Doug's team communicated using some and then the ACS-Light objects. We did need additional detection as was mentioned, in the Gahanna test site because the artery used as the test site was running semi-actuated. Thanks to funding from Raj's side we were able to implement some detection for the phase utilization data needed by the algorithms. As has been slightly covered, we took an approach that kept our standard master, closed-loop master, in place, for the test cycle. This allowed the city to maintain complete management and control of the closed-loop system under test and we actually ran the ACS-Light system in parallel with that past master. There was a second between the ACS-Light computer and the intersections, using NTCIP over twisted pair and used a second communications port on the controller. This allowed us to implement two channels going simultaneously to the local intersections. One a 1200 baud, running standard internal closed-loop, and the other at 9600 bps, using a modem on a second hard-wired channel to the ACS-Light computer. This allowed Gahanna to monitor through; and Doug and Steve to monitor ACS-Light separately without interfering with what was going on, on our system. The city could have shut down the response of the local controllers if problems were found, luckily that didn't need to happen. This shows a pictorial of the architecture. As you can see on this side we maintained our standard closed-loop architecture with the master maintaining communications to the local controllers, so the system basically was under constant management by the system. The ACS-Light system sat in the same cabinet with the master, communicated on a separate twisted pair communications line, NTCIP, access to that computer over a Internet connection using CD wireless networking mod em. Allowed both Doug and his team, and our team to watch the ACS-Light operation remotely without having to be on site. Our outlook on ACS-Light is that it's very promising. The initial test results show some very positive results and it looks to be in a very effective, cost-effective adaptive control system for small-to-medium systems. The traffic responsive control, used in the past, typically going to be much easier to implement, as Doug touched on, but may require some additional detection over a typical closed-loop system because of phase utilization and... One thing we haven't done is compare ACS-Light to a well-timed traffic responsive system. Hopefully that's something that can get done in the future to show how well ACS-Light performs. The next generation of field masters the industry is looking at will be supporting NTCIP so ACS-Light fits in well. Able to run with the next-generation masters, giving the ability to do time of day or adaptive control with the staple same hardware, reducing the need for a second channel, all could go over the same channel. Next steps, to become more familiar with the algorithms, after a formal handoff of the software, allowing us to make investments to support ACS-Light MIB into our newer controllers and we, as all the other participants and researchers are looking for other early adopters to gain experience with the ACS-Light concepts. That's all I had. next speaker is Peter Ragsdale, with PEAK, traffic system development since 1993, from small closed-loop systems to large centrally based in Minneapolis and Toronto. Peter is general manager of new products for member of joint committee, highly active in and in a leading efforts to fully implement it. Thank you, good afternoon everybody. I want to walk through what PEAK did in our involvement in the project. We took a little different approach compared to the Econolite, more like Siemens, not using a master. A quick overview, I will talk about the deployment area we used in Braddenton, Florida, our implementation, approach, what we needed to change and what ended up being our final architecture, the challenges we faced and future directions and summary comments for everyone. We did this deployment in Man a tee county Florida. Chose state road 70 in Braddenton. 9 intersections, one of them on a bit of an L at the very end, where the major flow went. We included a turn along the arterial. That did work out fairly well for us. The typical closed-loop system, director, back to the Manatee county running on FSK dedicated communications, internal mod em, typical support for upload/download, status monitoring, et cetera. Mostly loops along the arterial, one video system in place. Not going into the details here, but out of the nine intersections there you can see there was minimal fieldwork required to do the implementation. It was really just 21 individual amplifiers and six dual channels, a grand total of 33 detectors put in. We installed six unit track video systems, it was quite successful working with video detection also. As you can see from the details of the field modifications it was mostly to effect main street detection not there, a single detector that had to be split into the algorithm requirement. basically we did evaluation of ACS-Light MIB, looked at all the data requirements that were I guess basically going on, required to go back and forth, felt that a master would be in the way to an extent, bog things down. We had to try to come up with master list solutions, go straight from the ACS-Light computer direct to each controller. There is remote access available to Siemens and others through the ACS-Light computer, available so we could monitor the system, man a tee and the developers. We maintained 9600 baud multi-drop communications. One good benefit of the ACS-Light system, it's not very communication intentive. We were able to maintain all on a single common m channel, very successful from that point of view.