Module 28 - A207a

A207a: Building an ITS Infrastructure Based on the Advanced Transportation Controller (ATC) 5201 Standard (Part 1 of 2)

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Nicola Tavares: Welcome to the ITS Standards Training. Throughout the presentation this activity slide will appear indicating that there is a multiple choice pop quiz following this slide. The presentation lecture will pause at each quiz section to allow you to use your computer mouse to select your answer. There is only one correct answer. Selecting the submit button will record your answer and the clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice. Please help us make even more improvements to our training modules by completing the post course feedback form. This module is A315a: Understanding User Needs for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard. Your instructor Ken Vaughn received his bachelor's degree from Tulane University and his master's degree from Texas AMU. He coordinated traffic signals in Los Angeles County in the early '90s and his graduate research study, "The Performance of Actuated Signals in Coordinated Systems". In 1994 he became involved in ITS standards and was the founding member NTCIP Joint Committee in 1995. The next voice you will hear will be of your instructor.

Ken Leonard: ITS standards can make your life easier. Your procurements will go more smoothly and you will encourage competition but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards based ITS systems. I am Ken Leonard, the Director of the U.S. Department of Transportation's Intelligent Transportation Systems Joint Program Office. Welcome to our ITS standards training program. We are pleased to be working with our partner the Institute of Transportation Engineers to deliver this approach to training that combines Web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience without the need to travel. After you complete this training, we hope you will tell your colleagues and customers about the latest ITS standards and encourage them to take advantage of these training modules, as well as archived webinars. ITS standards' training is one of the first offerings of our updated professional capacity training program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener. You can find information on additional modules and training programs on our website at ITS PCB Home. Please help us make even more improvements to our training modules through the evaluation process. We will look forward to hearing your comments and thank you again for participating and we hope you find this module helpful.

Ralph Boaz: Hello. It is my pleasure to be your instructor today. This is part of the professional capacity-building program, and it's been a pleasure to be a part of the entire program, and I hope that you have found value in it. Up to this course you probably already have, so let's go on. The target audience is broad. We have engineering staff, Traffic Management Center and operations staff, signal maintenance staff, system developers and software developers, and private and public sector users, including manufacturers. So we have this broad audience, and this lays a foundation so that we understand why we need this ATC program. And so part of this course will be review for some of the people, like the traffic signal maintenance staff and some of the operations staff, but it is set forth so that we have a foundation from which to understand subsequent learning objectives. Listed here are the recommended prerequisites. I would like to just highlight the bottom two here, identifying and writing users' needs when ITS standards do not have SEP content. This is a great prerequisite. I want to make sure that all of you have this one before you continue here, and the same thing with the next one, introduction to ITS standards, requirements and development. A couple more that I want to make sure you have is A203. This module provides guidance on how to write requirements if they're not articulated within an ITS standard. And then course C101 explains the NTCIP framework of protocols. It's the National Transportation Communications for ITS Protocol. And you undoubtedly have seen that abbr used quite a bit in the PCB program. Here's a graphical representation of what you just saw in the previous two slides. We won't belabor this, but the point here is we are in module A207a. It is part one of a two-part module. A207b will go more into the ATC standards and specifics. Part two-- sorry. Part two will go into specifics. Part one is background information so that we understand the why for the ATC program. These are the learning objectives for both A207a and b. First is to explain the purpose of the ATC family of standards. Secondly, identify the basic components and operation of transportation field cabinet systems. Third, identify the features of the ATC 5201 standard. Fourth, describe the ATC 201 architecture. Fifth, describe how the ATC 201 standard works with other ITS standards. And sixth, specify the ATC equipment for system and equipment procurements. Again, we will be focusing only on the first two learning objectives in this module, and it may be review for some of you, but we hope you will still glean some things out of the presentation that you'll be able to carry forward into A207b. Our first learning objective, explain the purpose of the ATC family of standards. Here we'll discuss uses for transportation controllers. We'll see how the transportation controllers have evolved over the last 30, 40 years. We'll have a brief overview of the ATC family of standards, and then we're going to clear up some misstatements that have occurred during the development of the ATC standards so that everybody is clear on what's an ATC, etcetera. The definition of a transportation controller. A transportation controller, also known as a controller, controller unit, traffic controller, is a field-hardened computational device that runs application programs as part of a transportation field cabinet system. Often when we use the term "transportation field cabinet system" we call it "the cabinet," and I may slip up and do that, but I'm sure that you'll catch that. So essentially this is the computer for the field cabinet field equipment for transportation. Here are some of the uses that have been identified for transportation controllers. Of course there's traffic signal control and management, ramp metering, data collection, transit and light rail priority, emergency management, lane usage, access control, advanced traveler information systems. Usually in this case they're part of gathering the information that's needed for those systems. And then now that's emerging is the connected vehicle applications, and they have to do with safety, eco-driving and platoon management. When we say "platoon" here we're not talking about some military thing. We're talking about the management of vehicles or groups of vehicles through the arterial or corridor. And this is kind of a graphic illustration of what I just described. We have the transportation field cabinet system here in the middle of this graphic, and we show that there is different kinds of applications that will be done by that field equipment. So controllers are actually part of this TFCS, and there's other equipment in the cabinet. The cabinet itself is considered a system, but we don't want you to confuse this kind of system with the center-to-field communications systems we've talked about in NTCIP modules or maybe the center-to-center communications there. This is a system that is in the street or on the street and in the cabinet. Now, the fact is that most NTCIP center-to-field standards refer to devices that are located within or partly within a transportation field cabinet system. If you notice here in this diagram you see field devices on the right. You see a dynamic message sign and a video detection camera, a microwave detection device and maybe a closed-circuit television, traffic signals and many other things. Well, parts of those kinds of devices or systems, if you will, are located within the transportation field cabinet system. And so what may happen is that when you're talking NTCIP communications from a central location the standards that you see here listed on the left will be used in talking to the TFCS or they'll pass through the TFCS even though some of the devices are actually located physically on the street. Here this is representative of a downtown area, and we see a five-by-five cross-section of a street. We call it a grid. And on the left is a building representative of our transportation management center. So sometimes and often we have transportation field cabinet systems out on the street running an intersection, and they are not influenced or controlled by any other device other than the traffic controller in the cabinet, and it decides what is safe to do, and we call those standalone TFCSs. Now, other kinds of architectures use a central control to those cabinets, and so that's illustrated here in our diagram. And so the dots that go to the cabinet are representative of communications. Then there's something we call a closed loop system, and here you have a particular transportation field cabinet system that has a device we call a field management station, which coordinates, for instance, a boulevard of many cabinet systems, and that's illustrated here. And then there may be some sort of hybrid. That's where there is a central control as well as some other kind of architecture used in the street. In this case it shows a field management station. And now today we're even talking about peer-to-peer communications, and that's illustrated here with the communications from one intersection being communicated to the other intersections around it so that those intersections can adapt to the flow of traffic. This shows a very, very high-level evolution of transportation controller equipment. On the left in the 1940s we see electromechanical devices. Those devices are just like simple timers used in your houses today to control a light switch when you're gone or a light, and they have cams in them, and there are still approximately 1,500 of these devices being used in New York City. I'm not sure of other places, but they are being removed readily. In the late '70s we had NEMA TS1 standard, and in the early 1980s we had the Model 3XX, often called the 332, but there's a family within that numbering scheme. NEMA stands for the National Electrical Manufacturers Association, and they are a group of manufacturers that came out with that standard. And then in the Model 3XX that was done by the state of California and the state of New York. Then in 1992 a second NEMA standard came out. That was the TS2 standard, and it was unique in that it used some serial communications within the cabinet, and then again it came out in 1998, and that used NTCIP communications within that standard. And then in 2006 we had the ITS cabinet, and it was kind of a mixture of these predecessors, and we'll talk about that in a minute. The important thing to understand is because of all the equipment that is in the field in the United States is that when we were developing the ATC standards we wanted to be able to support all of the legacy field cabinet systems that are out there. So the purpose of the ATC family of standards is to provide a field computing platform for transportation applications. We talk about it being open architecture. That means that the standard is built so that anyone that wants to do it or has the means to do it can build this equipment. By modular it means it has an internal infrastructure or internal structure so that there's separation in the functions and subsystems and assemblies, and this adds flexibility and reduces time to configure a system and may reduce field maintenance, etcetera. The next one is that these standards are multi-process and multi-application. Multi-process means that it can do multiple things at the same time. Multiple application means that it can be used for different purposes. And, again, this can all be done simultaneously. And one of the big issues with our field systems, our field equipment is that when they are issued and people build to them they are stuck in the timeframe in which they were developed, and even by the time some of these standards are ratified some of the equipment may be obsolete, or at least on the low-power end of their life. So we wanted to build a standard that can grow with technology, that can advance with computing technology. And then we wanted to be able to upgrade legacy transportation field equipment. We didn't want to leave our agencies in the lurch and say "Okay, everybody has to move all of their equipment into some new kind of architecture," but we wanted to be able to provide a path to get contemporary performance out of our older-architecture field cabinet systems. Okay, we have an activity here. This will give you an opportunity to test what you've just learned. Which of the following is not an application area that has been identified for ATC controller units? Your answer choices are A, emergency management, B, personal computer backup systems, C, traffic signal control and traffic management, or D, connected vehicle systems. Please make your selection. Okay, let's review our answers. If you said B, personal computer backup systems, you're correct. There are more effective alternatives for backing up personal computers. If you said A, emergency management, this was the incorrect answer because emergency management has been identified as an application area supported by ATC controller units. And the same can be said for traffic signal control and traffic management and emerging connected vehicle systems. Now, as the ATC family of standards has been developed over many years there has recently been a change in how we identify the documents. So what we used to just simply call the Advanced Transportation Controller, that was confusing because the whole family is also called the Advanced Transportation Controller, so now we refer to it as ATC 5201. And previously we had called-- and many of you may have seen Model 2070 units that had an ATC logo on it, but we're now referring to the Model 2070 as ATC 5202. And some of you are familiar with the ITS cabinet standard, and now that standard is referred to as ATC 5301. And then we have the Application Programming Interface standard, and we refer to that as ATC 5401. So let's talk about these. So ATC 5201 describes a transportation controller, and as we said this is the smarts of the field equipment. Generally it's a functional standard, and we don't go into specific size and shape. Some standards that had been used previously by different agencies get very specific on that, and this is a functional standard. It defines a capability, and the standard works with any of the existing TSCS architectures. In the standard we provide a minimum computational power, and in this case the minimum is 60 MIPS, and that's millions of instructions per second, without limiting future advancements. Well, the fact is if you buy a contemporary processor today it's hard to find something that's slower than 60 MIPS. You can still get outdated processors that are slower than that, and we'll talk about that in a minute. So in addition to this we provide external interfaces. This is to control things like traffic signals or any other external device, signs, etcetera, or to communicate to the outside world, so the standard provides for these external interfaces, such as Ethernet and serial interfaces and the field IO systems of the cabinet. And then a big deal is the fact that it uses the Linux operating system, and I think most of you have heard of that. It's very common around the world. It's supported by the computing community. It's an open-source operating system, which fits well with our open architecture standards. Open source means that anyone can download the source of this operating system and use it. There's no runtime licenses for it, and all that needs to happen, which is the case for the ATC, is that we define the features that we want to use in the ATCs. And then of course we already talked about being multi-process and multi-application. Many of you are familiar with the Model 2070 standard, and we refer to this as ATC 5202, and it was originally developed as a replacement for the Model 170 controller that was first put in the field in the early 1980s. It's very prescriptive in size, shape. It has thumb screws, etcetera, very prescriptive in that, so it's different from the ATC 5201 standard in that that was more functional. This is more prescriptive. There are slide-in modules that will slide into the back of the units that provide numerous options. However, the national standard, the Model 2070 standard, only has a selected set of the most commonly used options. There are many companies that have come up with particular cards that could be slid into the Model 2070, but we only use the most common cards that are used across the country. Now, the thing to note is that in the Model 2070 most Model 2070 units use an old CPU and old operating system, and so you have limitations there. Now, some agencies have added parts of the 5201 standard to their Model 2070 specifications, but currently there is no Model 2070 specification that meets the ATC 5201 standard. Here we're talking about ATC 5301. The ITS cabinet standard describes a cabinet system. It uses the strengths from the rack mount systems and the serial systems of the preceding standards and specifications. The rack mount assemblies allow things to be secured in place. It's a very clean appearance on the front of the cabinet. The serial cabinets have fewer wires than parallel communication cabinets, and we're going to talk about those differences, and they tend to have more capability, and so those serial cabinets that came previously from the NEMA standards are combined in here. They have some of those kinds of features and capabilities, and they make a powerful cabinet standard. Now, each assembly is relocatable within the rack. It has a higher-speed serial communications bus than the NEMA standards, and it's been designed for ease of maintenance. ATC 5401 Application Programming Interface standard. This standard defines a software environment for both application programs and user interfaces for the controllers that meet the ATC 5201 standard. And what this does, this software that's described by this standard, it allows programs from different vendors to run concurrently on a controller, so you can get third-party programs that can run on a controller. You can buy your controller from one vendor and buy your traffic signal program from another, and so it allows this kind of open environment so that we aren't restricted to just what the original manufacturer provides us. It allows concurrent application programs to share the input and output resources of the cabinet system. We're going to talk about those in the next learning objective, but typically those are restricted to a signal program, and we'll show that in the next learning objective. And then because there's multiple programs running on the controller we allow the front panel to be shared, and we do that by creating a window-- we call it a windowing system. It's not Windows as in Microsoft, but a windowing system that allows operational users to flip between the programs that are running in the controller. So let's talk about the status of these standards. If we look at ATC 5201, actually below that version five has been published and it's been out since September of 2006. Currently version six is in progress. It is being reviewed by the ATC controller working group and going through comments that were submitted in July of 2012, and we're still going through those. Version 6.10 is the current version, and many manufacturers are already building to that standard. We look at ATC 5202, the Model 2070 standard. It was published in December of 2012. ATC 5301, the ITS roadside cabinet, back in 2006 version one of the standard was published. Version two was started and made significant progress, but it stalled from lack of funding, so we're in a process of holding right now while we gain that funding and will continue development. And then ATC 5401 is the Application Programming Interface, and version two was published in September of 2011. Now let's talk about these standards in terms of their system engineering content. And from a user's point of view the system engineering process and content can make for a more understandable standard, and it also provides for needs and requirements that can be used in agency specifications. So we'll just talk briefly to that here. The ATC 5201 standards, they do not contain system engineering process information, and as I said there is an update of version five. We call it version six obviously, and that's going on right now. The Model 2070, it does not contain system engineering process information. ATC 5301, version two of this standard, which is in process but on hold for the time being, it does use a formal system engineering process, and again it's in progress. If we go to ATC 5401, the Application Programming Interface, it was developed from the beginning using a formal system engineering process and content. Here is where to find the ATC standards, and an easy way to do that is just go to www.ite.org/standards, and that's kind of the place where you can branch into any of these standards. Be sure to be looking at version twos of these standards if they exist, or in the case of the ATC controller look at version six. And now let's clear up some misstatements that have developed, let's say that, through maybe some assumptions and things. All of the standards we've spoke about on the previous slide are part of the family of ATC standards. Now, some Model 2070 controllers by special provision by the agencies have added portions of ATC 5.2b into their specifications, but in truth there's no current Model 2070 standard or specification that fully conforms to ATC 5201 version six or 5.2b. So the point here is no matter what the controller says on the outside, whether it's 2070 or some other controller, get written confirmation that the product is ATC 5201 version six conformant or ATC 5.2b conformant. So let's have another quiz. Which of the following is not in the ATC family of standards? Your answer choices are A, Application Programming Interface standard, B, ITS roadside cabinet standard, C, Model 170 standard, or D, Advanced Transportation Controller standard. Please make your selection. If you said Model 170 standard you are correct. The Model 170 is not in the ATC family. It was a specification developed by the states of California and New York. If you said A, Application Programming Interface standard, that answer was incorrect. ATC 5401 allows application programs to share the resources of the controller. If you said B, ITS roadside cabinet standard, that answer was incorrect. Recall that the ATC 5301 design uses the strength of both rack-mount and serial cabinets. And then if you said the Advanced Transportation Controller standard this is incorrect. We call this ATC 5201, and it provides a functional standard for a transportation controller, and that can grow with technology. We have another quiz question for you. It's a true-false question. Specifying an ATC 5202 Model 2070 controller unit guarantees conformance with the ATC 5201 standard. Answer choices are true or false. Please make your selection. Well, if you said false you're correct. Specifying a Model 2070 does not guarantee conformance to ATC 5201. Users must make special provisions to conform to the ATC 5201 standard if you are going to use a Model 2070 controller. And again there is no current standard or specification of a Model 2070 that meets the ATC 5201 standard. And so that's the answer to the previous one. If you said true that was incorrect for the reason I just said. Okay. In this learning objective we explained the purpose of the ATC family of standards. We identified uses for transportation controllers. We talked about the evolution of transportation controllers. We had a overview of the ATC family of standards, and we tried to clear up misstatements that are used in the industry. Now, a question that has been asked in the past in performing this module was "Why are there so many architectures?" And I think I alluded to this earlier, was that agencies are reluctant to change architectures or sometimes even brands because of the expense to do so. Think about all the equipment that's going into the street, and it's not just the cost of the equipment. It's the labor that's involved to get it out there. Now, what you will see in the next module, in ATC-- sorry, in A207b, is you'll see how the ATC 5201 and ATC 5401 standards are used to mitigate some of those issues. So that's the reason why agencies tend to make the best choice they have at a certain point in time, and they deploy that field equipment and then they stick with it for many years, sometimes a decade, sometimes 10 years and sometimes 25, 30, 40 years, a few cases. So now I'll discuss our second learning objectives, identify the basic components and operation of transportation field cabinet systems. And here we'll talk about traffic terminology, basic transportation field cabinet system components and the differences in the transportation field cabinet systems. Again, this will be review for some, but it's important for those less familiar with field equipment to have this information so they can understand the issues discussed in A207b. So traffic terminology. We have what we call a detection zone, or sometimes it's just called a zone, and that's an area in which traffic parameters can be measured or traffic data can be generated. We have something called a vehicle phase or simply a phase, and that's any combination of traffic movements receiving right-of-way simultaneously during one or more intervals, like a green, a yellow or red. So here we see a common four-way intersection, and we have these detection zones in the street identified, and there's different kinds of technologies that can be used in the field. Many of you have seen cameras. There's what we call inductive loops in the ground. But they're all there to gather the information about vehicles coming, and there's also other different kinds of detectors too for pedestrians as well as bikes and things. Zone locations are also usually more sophisticated than this, but these were just used for illustrations. Now we see a graphic illustration of vehicle phases, and we give them the numbers or the numbering. This is not every intersection. This is what we just call the standard quad. The straight-through movements are given in this case even numbers, and the left-turn movements are given odd numbers. So phase one is southbound but then turns eastbound, etcetera, and you can make your way around the intersection. So let's look at the components of a TFCS. There's the inputs. That's where the zone information is gathered and put into a fashion and the controller can understand it. There's the controller. That's the brains of the operation. We have the outputs that control the field devices and monitoring that looks at the health of the cabinet, and there's a power supply, and that provides power to the cabinet system. And then we have a internal bus, and in the older standards and specification that internal bus was simply electrical wires, and in newer cabinet architectures that was a communications bus. So inputs. That has the on/off states of the detection zones reported through detectors, and these are typically housed in a detector rack or input assembly or input file. It all depends on what standard or specification you're using. There's many different sensing technologies used, loops, video, radar, many others. We take a look at two of our TFCS architectures. On the left we have the NEMA TS2 cabinet, and you see at the top there is what we call a detector rack at the top, and those assemblies are used to house detectors that slide into those assemblies to bring in the zone information into the cabinet. On the right you see a ITS cabinet version one, and in this cabinet we see the input rack here, and it does contain some detectors in it, as illustrated. As we talked about, the controller is a field-hardened computer. It runs the traffic control application program, and as we'll see in A207b it can do a lot more than that. It takes the detection zones that are associated with phases within the controller. It receives-- well, I'm sorry. It has detection zones associated with the phases in the controller. It receives inputs from the detectors, then it determines how to safely provide service to the vehicles. It sends information to devices we call load switches or switch packs and also to a signal monitor. So on the left we see the NEMA TS2 cabinet with a particular brand of controller. The NEMA of these controllers, it's more of a functional standard, so the controllers may have a multitude of looks and appearance, and the NEMA TS2 controller is shown. On the right is an ITS cabinet, and it's usually a Model 2070 unit in this case. You see that identified at the top of this picture. Okay, the outputs. As we said, those consist of load switches or switch packs that receive the field display states-- in other words, what the color should be out in the intersection-- and they receive those from the controller. Now, these load switches are kind of like the switch on your wall for your light. They control the 110 volts that go to the signal heads, so the controller does not communicate at 110 volts to the load switch, but it controls whether the load switch is allowed to send that power out to the signal heads. Now, these load switches may be plugged directly into a cabinet back panel or load bay or terminal and facilities area, or they may be housed in an output assembly or output file. And it all depends who you're talking to what these are called, but I wanted to bring out all the terms, because this is one of the problems with getting used to this type of operation in the cabinets, is depending what part of the country you're in or what kind of equipment your agency uses they may use different terms. But those who have been around the industry for a while will automatically do the translation and understand what's being talked about. Here we see a load bay, if you will, of the NEMA TS2 cabinet. Those are load switches, and you can see the different colors there. Those identify the colors going out to the signal head with the different LEDs. And then on the right you see an ITS cabinet where the switch packs are in a output assembly, and there again they have various signal head indications there. Okay, we did talk about monitoring. Now, monitoring is done to make sure that combinations of displays that are dangerous to the motorists are not allowed, so it's preprogrammed by the agency or consultant for the agency so that in a given intersection signal heads won't be activated that could cause an accident or be the cause of the accident. So these monitors also ensure that the controller is operating. In some cases there's simply kind of what we call a watchdog, "Hey, is there power coming from the controller?" kind of deal. In other cases that may be more sophisticated messaging. It also ensures that the cabinet and output voltages are within allowable parameters. As I said, in the serial cabinets many of the monitors have more advanced features. And if there's ever a problem detected by a signal monitor it puts the intersection into a flash condition, so often if you see a signal in a flash condition in a few cases those are programmed by the agency to happen during times of day, but in most cases that's when there was some sort of failure detected and the monitor took over and made it safe for everyone. And these signal monitors go by different names. There's a MMU or Malfunction Management Unit, the Cabinet Monitor Unit called a CMU. In the old days it was called the Conflict Monitor Unit, CMU, and now we kind of generally call all of this monitoring-type devices-- we call them Signal Monitor Units or SMUs. On the left here you see the TS2 monitor, and it's connected to the controller. And, again, it makes sure that conflicting colors are not being allowed to go out to the field devices, field displays. And on the right you see the cabinet monitor unit. On the left, we call this a MMU. And then on the right we see the CMU of the ITS cabinet version one. So let's review this whole thing. So out in the field we have field sensors, and they're looking at various zones on the road. And we also have our field displays <inaudible>. Obviously the signal heads are part of that. And so these field sensors bring data in as inputs into the cabinet. The inputs go to the controller, who has them associated to the different phasing, the different turning movements that are to be supported in that intersection. The controller determines what is the best way to service the vehicles. It actually does this every tenth of a second. It then signals to the outputs, the load switches that are part of that, to change the colors accordingly. That allows power to go out to the field displays. At the same time the monitoring is observing that power and making sure that no conflicts are coming out of the outputs to the field. And in the serial cabinets there is communication from the monitor back to the controller that can be used for diagnostic purposes. Okay, let's look at kind of summarizing everything here. Let's look at the differences in our field equipment. NEMA TS1 was shelf-mount. It used discrete wiring between all the devices. It used a conflict monitor, and then it had eight input channels. And by input channels that's how many inputs can be monitored as part of the input element of the cabinet. And then the monitor then has three, six, 12 and 18 monitored output channels, and by output channels we refer to how many signal heads, red, yellow, green, that can be monitored. Caltrans had a similar kind of setup being a parallel cabinet. However, it was rack-mounted, had more input channels and equivalent monitored output channels. The NEMA TS2, it was shelf-mounted. It added a serial communications, called it a malfunction management unit, has 64 input channels and 16 output channels. And then the ITS cabinet version one is rack-mounted. It has a higher-speed serial bus. We call it a CMU. The signal monitor is a CMU. Had 120 input channels and 28 monitored output channels. And, again, the ITS cabinet version two is in development. So let's take a quiz. Which element of a TFCS determines the sequence of traffic movements to provide service to a vehicle? Your answer choices are A, inputs, B, controller, C, outputs, and D, monitoring. Please make your selection. Let's review our answers. If you said B, controller, you are correct. The controller runs the operational program, which includes the traffic signal software. If you said inputs this was incorrect. Inputs refers to the detection zone information that comes into the cabinet system. If you said outputs this was incorrect. Outputs refer to load switches, which provide power for the appropriate indications on the field displays. And then if you said monitoring this was incorrect, because the monitor verifies that the state of the field display do not represent-- or do not present an unsafe condition. So let's summarize our learning objective two, which was to identify the basic components and operation of the transportation field cabinet systems. We talked about traffic terminology. We talked about basic transportation field cabinet components, and we talked about the differences in transportation field cabinet systems. Now, we had a question from a previous presentation of this module. Someone asked "What is the best cabinet architecture to date?" And I think that's a very subjective question according to which agency you belong to, but the agencies tend to buy the best architecture for their needs at a given point in time and then stick with that architecture for a very long time, 10 years or more. So what we have learned today. We learned that there are various standards and specifications for transportation field cabinet systems. We learned that the basic components of a TFCS are inputs, controller, outputs and monitoring. And then we learned that the ATC 5201 standard can be used to specify ATC controller units that can operate in any major TFCS. Now, we'll talk about the opportunity that the ATC 5201 standard provides in the next module, and then we'll also talk about even expanding that even further when we talk about the subsequent module that speaks to ATC 5401. Here are some resources that you can go to to look at some of the items that we talked about today, especially if you were looking at wanting to see the various components of these field systems. One that I mentioned earlier that's not listed here is www.ite.org/standards, and that's where you'll get access to all of the activities in the ATC family of standards. Here we'll review a couple questions that came in in previous presentations of this module. Someone asked "How do I follow what's going on in the ATC standards work?" I talked about the standards Web site. There's also a Listserv where announcements and meetings and developments in the ATC program are sent out, and you can find that at list, L-I-S-T, .ite.org, and you can sign yourself up to receive those messages <inaudible>. A second question that came in was "Does the USDOT expect that everyone will just move their equipment to these standards all at once?" And no, the USDOT is providing this as a service to our industry, provides these standards, and it's an opportunity for the agencies, but these standards have been designed so that they can be added to existing infrastructures so that everything does not have to happen at once. It can occur as a step-wise introduction into your transportation infrastructure, or it can go along with some project or grant money that you get, and it can be done in a larger scale. The next course module that we'll be discussing is A207b, building an ITS infrastructure based on the ATC 5201 standard, and that'll be part two of two. So, again, this module was just the beginning. And here our learning objectives will be identify the features of the ATC 5201 standard, describe the ATC 5201 architecture, describe how the ATC 5201 standard works with other ITS standards and how to specify ATC equipment for system and equipment procurements. In the future we're going to have a couple other modules, A307a and A307b, and these modules will cover the writing and user needs requirements for ATC 5201-based specifications. This ends our module for today. Thank you for participating.

#### End of 2013_10_07_13.45_A207a_Final_Recording.wmv ####