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.)
Ken Leonard: ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll 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, director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new 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 that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the 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 which improves livability for us all. You can find information on additional modules and training programs on our website, ITS PCB Home.
Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.
Ralph Boaz: This is PCB (Professional Capacity Building) module A322b: Understanding Requirements for Transportation Field Cabinet Systems using ATC 5301 version 2. My name is Ralph Boaz, and I’m a project manager, systems engineer, and subject matter expert for the ATC and NTCIP standard programs. In addition to creating ITS standards, I also help agencies and private companies in the planning, specification, deployment, testing of ITS equipment and systems. It is my pleasure to be your instructor today.
As we spoke about previously in A322a, this ATC 5301 is one of three standards in the ATC family of standards. In the previous module, we created a concept of operations that contain user needs, or our pseudo agency, that is trying to procure ATC cabinets. In this module, we’ll get more specific and establish requirements for our cabinet systems and create a specification. Specifically, our learning objectives today will be to describe the features of ATC 5301, write requirements for ATC that we’ll include in our specification. We’ll create a procurement specification for ATC cabinets and then we’ll verify the specification.
This is our first learning objective. Describe the features of ATC 5301 standard v02, transportation field cabinet systems. In this part of the presentation, we’ll review the benefits of ATC cabinets over other field cabinet systems. We’ll review a generic representation of the cabinet system, and then we will discuss the assembly’s components and options within the standard. We’ll take more time during this learning objective. It will be a little bit longer than the rest of them, because we want you to know what is all in the standard, and all the benefits that you can get.
So, this is a very compelling cabinet system, as you’ll see here. It’s a functional standard, except where we desire component interchangeability. So, this allows manufacturers to innovate and create many, many designs of these cabinets, and still be within the standard. We could take advantage of the detector technology that’s out there and use a double and even quad detectors in the same space that was used in older standards. We double the number of channels per switch pack, and the switch pack is physically smaller. Sometimes they’ll say load switch, depending on your background. A switch pack and a load switch are similar devices that control power to displays and other devices in the street. Then most assemblies are replaceable while the intersection is in flash. We talked about this in the previous module, where you could actually take out the controller, take out the input assembly and the output assembly, and the intersection would stay in flash. That’s a big safety feature, should someone need to replace those assemblies in the street.
We have load current monitoring, and that allows us to detect dark approaches. So, for instance, in older systems that just checked voltage, you would not know if a signal or if two signals were on the same channel, you wouldn’t know if one of those signals went out, because there’s still a circuit going. But, in this case, we are measuring current, so we can detect that one of those signals actually went out. We eliminate the arc flash hazard that’s identified in NFPA 70E. What that is, is if you have something, let’s say has high voltage or power running through it, it can actually jump across to another conductor that’s grounded, and across the air. So, if that other conductor, that other grounded conductor, is a person, it can create serious injury and even death. So, this eliminates that arc flash hazard in this cabinet. We also have a touch safe design. What that does, is it keeps any wiring that goes into the cabinet is secured in a fashion that eliminates accidental touching.
So, there is also—so those previous two items are more for the technician, but this actually helps us, this next thing, a low-voltage option of 48 volts DC going out to the field wires, this actually helps protect the public, because if you have a knockdown of a traffic signal during a storm, for instance, and you have 120 volts going out to those signal heads, that’s a very dangerous situation for anybody. With 48 volts DC, UL states that this is safe, this is electrically safe for humans.
The other benefit of this 48 volts DC going to the output wires is, we can have alternative power sources, so that maybe we can keep signals up longer and running better. The other part of this is that there’s better LED compatibility. Right now, all our LEDs are designed for 120 volt systems, but the LED manufacturers are on board to help us look at this relationship between the cabinets and the field systems to potentially save in power.
Now we’re going to do a little bit of definition here. In the cabinet system, we have assemblies. Assembly is any subordinate element of the cabinet system that’s made of multiple parts or components. By that definition, that’s just about everything that isn’t, you know, a screw or a nut or something that’s just a very discreet element. We have major and minor assemblies in the cabinet system. The major assemblies are the controller. The controller is not defined in this standard. That’s defined in ATC 5201 and ATC 5401. We talk about the controller, but we don’t define it here. We have the input assembly. That’s where detection comes in. We have the output assembly. That’s where controls, or the power goes out to the signal heads. We have the field termination assembly. That’s where wires connect into the cabinet, and we have the service assembly. That’s where power comes into the cabinet. The minor assemblies would be things like drawers, fans, lighting control. These things are common in all cabinet systems and we won’t go into those in this presentation. Okay, so that was assemblies.
Now we also have components. This is a term used in the standard. A component is an electrical assembly with major functional attributes of the cabinet system, where some level of functional or physical interchangeability is desired. So, these components are called out specifically. We have the serial interface unit for communications. We have the high-density switch packs/flasher units. That’s written HDSP or HDFU, depending on what it’s doing. It’s the same unit, but depending on its placement, it changes function. We have the cabinet monitor unit, that makes sure that our cabinet’s running properly and there’s safe signals going out, safe indicators out on the street. There’s the cabinet power supply or CPS. We have the auxiliary display unit or ADU, and we have sensor units, which are also, we say sometimes detectors.
I want to say something here about the cabinet power supply and the ADU, is that the cabinet standard actually calls out specific options for these units within the standard, so that an agency may reference these by model number. However, the standard also allows for manufacturers to innovate here and create their own designs as these elements. So, that allows for innovation. The signals are the same in these units, but the mechanicals, maybe connectors, may not be the same. So, again, you just want to make sure you understand that if you’re going to allow manufacturer-specific designs, you may not have interchangeability of these particular units, but those manufacturer-specific designs may have something the agency really wants. So, you make your choices.
So, here on the left here, we have definitions of things we’ve just talked about. Here we’re going to do a generic representation of the cabinet. So, these are the rails of the cabinet. We have the controller, and again, that’s defined in ATC 5201 and ATC 5401. We have the input assembly, and here in this diagram, we see we have the SIU, or serial interface unit, which handles communications between the controller and the sensor units. Here we have our sensor units or detectors here in our input assembly. Then we have our output assembly and it also has the serial interface unit. Then we have our high-density switch packs. Then we also have our cabinet monitor unit, keeps everything safe. So, that is our—there’s a little tech panel to the left there that I won’t discuss, but that’s our output assembly.
Then we have our auxiliary display unit, or ADU, and what this does is it allows us to see what the CMU is doing and the reports in the CMU, and it’s a great tool for the technicians. We say it’s option, because the ADU is not required for operation of the cabinet. It’s a tool for the technicians when they’re diagnosing things and such.
So, then we have the field termination assembly. This is where the wires, input and output wires going into the cabinet are secured, again in a touch safe fashion. Then we have our service assembly. This is where power comes into the cabinet. You can see the similar color to the HDSP is the HDFU or high-density flasher unit, which is used to put the signals in flash when there’s a failure or there’s service going on, so that’s identified here, as shown. Then we have our cabinet power supply. Again, this is no particular manufacturer’s design or look. I tried to keep it generic, because there’s lots of options here, even in the parts or arrangement of the parts of the standard.
Let’s talk about options. So, the standard allows for many configurations and the number and arrangement of assemblies and components will vary. Some assemblies or components may not be used. For instance, you may not have—I think I may have shared this already—but we may not have an output assembly if we’re just a data-collection system along a freeway, and so we’re just collecting inputs and the controller’s reporting traffic flow. So, the standard identifies some options or assemblies or components.
So, these options may be defined in the standard, or there may be an option for a manufacturer-specific design. This last part’s really important. Where the ATC standard defines options, the agency specification; that’s what we’re building here through these courses should remove the ambiguities. So, you should have requirements to select one of the defined options in the standard, or state that a manufacturer-specific design is allowed. Even if you do have a manufacturer-specific design, you may want, for instance, for a power supply, you may want to reference the power properties of one of the models that is in the standard and say that, that is a minimum requirement for the manufacturer-specific design. But we need to remove ambiguities when there are options in the standard.
Let’s talk about the assembly. So, we won’t talk about the control over here. We’ll talk about the input assembly. The main functions of the input assembly is to house the sensor units that do the on-street detection, the SIU which does the communications for the detection to the controller, and to provide—this also provides communications between the sensors and the SIU. So, our options. The number of sensor units supported per input assembly varies. Twelve sensor units per assembly is the most common and that’s if you take 12 sensor units and they’re dual channels that makes 24 output channels. That is probably the most common arrangement that you’ll see. But you may use additional input assemblies or other packaging in your cabinet unit. For every 24 input channels, an SIU is required, and that’s 120 input channels total.
So, choices. Manufacturers make multiple designs of input assemblies, and we suggest that the agencies determine the number of input channels they need, and allow the manufacturer to provide the appropriate input assembly packaging. This allows for innovation. So, you decide how many input channels you need, instead of saying, you shall have this many slots in your input assembly, or you’ll have this location for the SIU, etc.
So, here’s three pictures, or three photographs, of input assemblies. The one on the upper left here, you’ll see that I just showed the location of the SIU in here. The rest are all sensor units. They look like they’re all dual sensor units, so this is exactly what we described, 24 channel input assembly. Here we have, on the right, we have actually an input assembly that supports 48 inputs. You’ll note that we have two SIUs here, as highlighted. One’s on the left and one’s in the middle, and these are four channel sensor units, in one input assembly.
Now this is interesting, this next one down below, is this is actually a 15-inch, I believe, a 14- or 15-inch wide cabinet system, so it’s kind of a skinny cabinet system. It actually has 32 inputs, and that’s because they’re not getting status messages back. But I just wanted to show you that lots of innovation can occur, and we also have the SIU, in this case, it’s on the right.
Okay, let’s talk about the output assembly. Main functions are to house the high-density switch packs, control power signals, and other devices. House the cabinet monitor unit, that ensures there’s no conflicting signals and other safety monitoring. House the SIU that does the communication between the switch packs and the controller. And this output assembly provides communications between the switch packs and the SIU, and provides communications between the switch packs and the cabinet monitor unit. So, the options. So, the number of high-density switch packs supported per output assembly may vary among manufacturers. Eight HDSPs per output assembly is common, so that’s 16 output channels. They may use an additional output assembly, or a larger output assembly if more channels were required. You need an SIU for every 16 output channels.
So, what are our choices here? We have, manufacturers may make multiple designs of output assemblies. We suggest, as in the input assembly, that agencies determine the number of output channels they need, and allow the manufacturer to provide the appropriate output assembly packaging. So, here we see, in this upper left, you see the cabinet monitor unit on the right side of this assembly, and then we see the SIU. On the lower left here, we see that the SIU is on the right side of the output assembly, and the cabinet monitor unit on the left. Then on the right, this is actually an output assembly that holds 16 HDSPs, will control 32 output channels. Here you see, the upper left there of the unit, we see the cabinet monitor unit. Because we have 32 channels of detection, we have to have two SIUs. Now in the input assembly, as well as in this assembly, the signals are all the same, but you can see the mechanics are different. This is, again, just an illustration of how the standard allows for innovation.
So, the field termination assembly, the main functions are to provide shielded termination for input and output wiring. The design of the FTA is a manufacturer option. There’s lots of choices. Manufacturers may make multiple designs of FTAs. Some have split input and output FTAs, just depending on how they want to design their cabinet. You see on the left here, you have rows of, looks like three wire terminations. In the middle there, the terminations are going vertically. I believe those are six per terminator. Then there’s a really dense one here on the right. This is the other one. The signals are the same, but the design is up to the manufacturer.
Okay, and here’s our service assembly. The main functions are to provide power service from the utility company, as breakers, suppressors and filters. It has a ground fault circuit interrupter, GFCI, which you may have in your bathrooms at home. That plug is usually used for technician tools, etc., but also to protect the technician here. The options. The design of the service assembly is a manufacturer option. It houses the high-density flasher unit in most cabinet systems, but that location for the HDFU is also a manufacturer option. You can see here on the left, I highlighted this, so you can see the HDFU. Then actually, in the right here, we have two high density flasher units. I believe that this actually—this service assembly went to the other output assembly that had the 32 channels. So, they have two flasher units. Again, this is all a manufacturer option.
Now we’re going to go into the components. We have the serial interface unit or SIU, provide communications between the system components, between the controller and sensor units, between the controller and the switch packs. It automatically adapts to its functionality, based on the position of the cabinet. I might just also remind you, the HDFU and the HDSP, they are the same device and it would adapt to its functionality based on its position in the cabinet. There are no options for this part. It’s model 2218. So, essentially, without this unit, without the serial unit, we don’t really have a cabinet system.
So, here is our HDSP/FU. It provides power to control signals and devices on the street. It automatically adapts to functionality based on position. Call it an HDSP and HDFU to reflect the functionality. There’s no options. We show two units here, but one is for a low voltage cabinet, that’s the one on the right, and we have the more common one, at least today, the high voltage option, that controls 120 volts to the streets. Most agencies are still using that. So, depending on the output voltage, you’ll use one of these two units.
You have the cabinet monitor unit. The main functions are to monitor the various aspects of the cabinet system and put the system in flash, under certain conditions. There’s 120-volt AC monitoring. That’s for the high voltage version of this, the 2212-HV. It does monitoring of the 48 volts DC, 24 volts DC and 12 volts DC, that are in all the versions of the ATC cabinet system. We have serial—it catches serial bus errors, communication errors. It looks for conflicting channels and diagnostic errors and it’s just a long list of things that this small unit does. So, there’s no options and it’s determined—whichever unit you pick is determined by voltage. There’s two versions that are high-voltage and low-voltage option.
We have our cabinet power supply. Main functions are to convert service power to power for the subassemblies within the cabinet. It creates control signals for orderly power up, power down, and timekeeping. It helps with the controller. There’s various options identified: 2216-24, it’s used for high-voltage cabinets and it also provides 48 and 24 volts DC. The 2412 unit, that adds 12 volts DC in the cabinet, if there’s some reason that you want to have 12 volts running in the cabinet for some other devices and some old, old detectors use 12 volts.
Model 2217, now this one’s interesting. It’s similar to the 2216-24, but the 2217 is a card-mounted unit, so that manufacturers may use this unit. Instead of stretching across the entire cabinet, 19 inches, you may want to use this as part of another power system. For instance, one of the vendors creates a battery backup system and uses this card, this 2217 within that to create their power system for the cabinet. Then there’s the 2248. The 2248, what that’s used for, it takes in high voltage but it is used to also power 48 volts to the displays on the street. Again, manufacturer-specific designs are also allowed.
Here we have some pictures of it. So, your job as an agency is to choose a unit from the standard that meets your voltage requirements, or allow a manufacturer-specific design. Left, you have the 2217. It’s set as a card mount. See the other two units, 2412, 2216-2412 and the model 2248, that’s used for low voltage output. I put a little box here just to remind you that you can have a manufacturer-specific design. Then we have the auxiliary display unit, and that provides user interface for the CMU, to view status, configuration, and logs. It’s four rows, 20 columns, LEDs for channel output status and navigation buttons. It’s not required for the CMU to operate. So, the options, there’s options within the standard. There’s model 2220 that you can select, or you can allow a manufacturer-specific design, or you can have no ADU. A laptop or tablet computer can be used during maintenance, or as we go forward here, there may be some application running on a controller that could also perform this function.
Here’s some of our choices. The top picture shows the 2220 that’s described in the standard. The unit below is a smaller unit and fits, I believe, in a 15-inch rack, 14- or 15-inch rack. This is a manufacturer-specific design, because it’s not in the standard.
Sensor units, these detect vehicles, bicycles, pedestrians, light/heavy rail, all kinds of things, whatever we’re trying to gather information about. Actually, these detectors that are listed are defined in NEMA standards and also in the Caltrans TEES. We won’t go into the details of these. You can look back at them or find the details for these sensor units in those documents.
Here we have an activity. Let’s see what we’ve retained. Which of the following is a true statement? A) ATC 5301 defines a controller as part of the cabinet system. B) ATC 5301 defines all mechanical specifications of each assembly. C) Serial interface units are optional in ATC cabinets. Or D) Where there are defined options in ATC 5301, the agency specification should remove ambiguities. Please make your selection.
If you selected D, you were correct. Options in the ATC 5301 standard, the agency should remove the ambiguities. This helps the vendors not only to know what you need, but also know where they may innovate. If you said A, this was incorrect. The controller unit or ATC unit is defined by the standards ATC 5201 and ATC 5401. If you said B, that was also incorrect. Mechanical specifications are only included where element interchangeability is desired.
Remember, as we were describing them, there were lots of places where those mechanical specifications vary between manufacturers. If you said C, the SIUs are optional, that is incorrect. Serial interface units are required for communications within the system. Very good.
Okay, now we’re going to go on to learning objective two, write requirements for ATC cabinet systems. Here we’re going to review our systems engineering development process. We’re going to discuss the form and characteristics of well written requirements, well-formed requirements, and then we’re going to write some requirements from the user needs that we identified in the previous module.
You’ll recall this slide. I use this in many of my presentations. It’s the definition of systems engineering, one of the definitions, from IEEE, an interdisciplinary collaborative approach to derive, evolve and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability. We have this process of identifying user needs, and that’s an iterative process in itself, but then we move from user needs to requirements, and we develop requirements from those user needs. Sometimes we have to go back and adjust those user needs, and then continue with our requirements process. Then when we get satisfied with our requirements, then we go on to the design stage, do the same iterative process, and sometimes we have to adjust the requirements and come back to the design. I think the solution here, satisfying customer expectations and meeting public acceptability, is a big deal here in our world today. We need to—and that’s what we’re trying to accomplish with these two modules.
This is a definition of a well-formed requirement. It has different sections of it. The forms are almost the same. There’s two forms identified here, where we have this item called localization, it’s sometimes at the end, and sometimes localization is at the beginning. So, we have the actor that identifies who or what does the action. We have the action, that identifies what is to happen. We have the target, identifies who or what receives the action, sometimes called the object of the action. We have the constraint that identifies how to measure success or failure of the requirement. Then we have the localization that identifies the circumstances under which the requirement applies. So, localization and constraint are important parts of this, but not all requirements will have both of those.
So, here we’re going to pick apart this particular requirement. This is from an ATC specification. It says—so this is requirement 5.3.7. color graphics display. So, we have the transportation controller shall provide a liquid crystal display, LCD, that is capable of color graphics. So, our actor is the transportation controller. Shall provide, that’s the action. A liquid crystal display, that’s the target. That is capable of color graphics, that’s our constraint. So, it can’t just be a monochrome text LCD. This is an example of a well-formed requirement. We didn’t have localization. We might have said, you know, under certain conditions, the transportation controller shall provide XYZ kind of thing, so that would be a localization. If a requirement can’t be stated in this simple format, you probably need to use multiple requirements. Often, the requirements become compound.
So, let’s talk about the characteristics of well-formed requirements, are necessary. Why have it if it isn’t? Must be useful. Must be concise, not long and confusing here. Understandable, expressed in declarative language, like shall statements. Attainable, it needs to be realistic. Standalone, stated completely in one place and it’s not a compound requirement. It needs to be consistent, it does not contradict itself nor any other stated requirement. That’s very important here, take the body of the requirements together. It must be unambiguous, susceptible to only one interpretation and must be verifiable. It can be met through inspection, analysis, demonstrate, test. Those are the characteristics. Let’s talk about the relationship of user needs and requirements.
So, let’s talk about the characteristics of well-formed requirements, are necessary. Why have it if it isn’t? Must be useful. Must be concise, not long and confusing here. Understandable, expressed in declarative language, like shall statements. Attainable, it needs to be realistic. Standalone, stated completely in one place and it’s not a compound requirement. It needs to be consistent, it does not contradict itself nor any other stated requirement. That’s very important here, take the body of the requirements together. It must be unambiguous, susceptible to only one interpretation and must be verifiable. It can be met through inspection, analysis, demonstrate, test. Those are the characteristics. Let’s talk about the relationship of user needs and requirements.
Remember that user needs are kind of like goals and we establish those things, the user needs are examples here in these two modules. We established those in the previous module. Here’s a relationship. We can have a one to one relationship, where we have a need and a requirement that fulfils that need. We have a one to many, and this is the most common condition, where you have a user need and multiple requirements are used to address that need. Sometimes you’ll have multiple needs addressed by a single requirement. That is a many to one relationship.
Just to show you that we have done this engineering approach here for ATC 5301. So in the tables, in the standard, there is an appendix that shows this, or at least, a later section. So, the requirements stated, and this was requirement 5.13.1, diagnostic display, local display. This was before we thought of the name ADU. It just describes that there’s a requirement for a diagnostic display unit. Then we show that the justification for that requirement was a user need that was previously identified. The user needs the TFCS to be a design that reduces time required for maintenance or personnel. Then we have that user need identifier there. Then, within the standard, we also then show what design elements were covered in the standard to address this requirement, and that’s identified. So, you see this traceability that was used in creating the ATC 5301 standard.
Let me give you some guidance on ATC cabinet requirements. The requirements that are in the standard were developed in the creation of the standard. Requirements must be developed for a specification—that’s what we’re building here—to ensure that the cabinet design or configuration will meet the agency’s needs. So, then there’s no need to repeat requirements that are already in the standard in your specification, unless it’s clarifying an option that is in the standard, or it relates to an agency user need for which the agency wants to show traceability. So, you don’t need to duplicate the standard. You need to create a specification that gets you what you want. Really important also though, is this idea of showing traceability, because if during your process, you have potentially politicians, or higher upper management expressing needs that get carried forward, you will want to show this traceability to your specification, so that you have shown publicly that you’ve addressed that. (Cough) Excuse me.
Okay, we’re going to go through some user needs now that were created in the previous module, and we’ll be creating requirements for them. So, this one was called modern ITS standards and specifications. The city needs the transportation infrastructure to be based on modern ITS standards and specifications. That is the stated user need. So, now we have the rationale. Much of the city’s ITS infrastructure is based on 25-40 year old technology. Infrastructure based on modern ITS standards provides choices for ITS solutions today and in the future. It also offers the best opportunity to leverage new technologies for mobility and safety. That’s our rationale to help us understand the need. So, we created this requirement, ATC cabinet conformance. So, it says the TFCS shall have a certificate of ITS conformance to ATC 5301 v02 from an agency approved test facility. So, here we created the requirement to meet this need. So, we’re not going to say, we’re not going to go—in this requirement, we’re not going to tell them how to test it, but we’re going to say that it is conformed based upon a facility that the agency has.
Let’s go to another user need. This one’s called existing foundations. The city needs a TFCS to use existing cabinet foundations at signalized intersections. That’s the need. Now the rationale. Intersections outside the downtown area have Caltrans 332 cabinet foundations. Downtown has both Caltrans 332 cabinet foundations and pedestal mounts for the Caltrans 336 cabinets. The city wants to avoid the cost of having to replace foundations when installing a new cabinet system. So, here we have a good explanation. The city wants to save money. So, we’re going to have two requirements here. We have what we’re calling a standard cabinet foundation. The TFCS shall have a cabinet shell and mounting compatibility with cabinet housing 1B, as defined by the Caltrans TEES 2009. Now this is not a compound one, because the shell and the mounting are both discussed as part of cabinet housing 1B. We’ll also have another requirement. We’re going to call it a downtown cabinet foundation, even though there’s also standard cabinets in the downtown area. We’ll call this a special one, as a downtown cabinet. The TFCS shall have a cabinet shell and mounting compatible with cabinet housing 2, with pedestal adapter, as defined by Caltrans TEES 2009. Here we have two requirements coming from this need.
Here’s one talking about power. The city needs the TFCS to operate using existing 120 volts AC service power. Numerous on street devices require 120 volts AC, including traffic signal displays and the cities changeable lane assignment system, CLAS system, and lighted cross walks. So, the city is not really ready to move into the 48 volts DC type of thing, and this is where most cities are at right now. So, we’re identifying that this is going to be a 120 volt cabinet system. So, the TFCS—here’s our requirement—the TFCS shall accept a nominal service power of 120 volts AC at 60 hertz. Here’s another user need. This one’s called standard cabinet configuration. The city needs a TFCS configuration that is suitable for intersections that are outside the downtown area. The number of inputs and outputs—this is the rationale. The number of inputs and outputs needs to support 80 percent or more of the intersections in this configuration. The city has plans to include a UPS in the cabinet and network equipment. Room is required for connected vehicle roadside equipment once the city chooses to deploy it. The city is identifying this configuration for ease of procurement. So, this user need came from the procurement office, because they were going to buy a lot of this configuration. They wanted to make it easy for purchase.
So, we have—in the user need here, it called out it needed—they wanted to have 80 percent of the number of inputs and outputs. So, then what happens is, we get our operations guys out there and they came up with some numbers for us. So, for standard cabinet input channels. For standard cabinet configurations—that’s a little localization there—the TFCS shall have an input assembly with a minimum of 24 sensor channels. We also define the outputs here. Standard cabinet output channels. For standard cabinet configurations, the TFCS shall have an output assembly with a minimum of 16 output channels. This is actually a very common configuration for all the manufacturers.
Now we’re also going to have a downtown cabinet configuration. The city needs a configuration that is suitable for intersections that are in the downtown area. The number of inputs and outputs need to support 80 percent or more of the intersections in this configuration. The city has plans to include a UPS in the cabinet and network equipment. Room is required for the roadside equipment, once the city chooses to deploy it. The city is identifying this configuration for ease of procurement. Here we’re going to define that for the downtown configuration, the TFCS shall have an input assembly with a minimum of 16 sensor inputs. And for the output channels, the downtown cabinet configuration, the TFCS shall have an output assembly with a minimum of eight output channels. (Cough) Excuse me.
Okay, here we have another user need. Multiple applications. City needs the TFCS to be used for multiple and concurrently running applications. The city wishes to operate multiple concurrent applications on a single controller unit, as part of the TFCS. The city may have a single TFCS operate multiple intersections simultaneously, adjacent ramp meters, and smart city applications not yet defined. So, how do we address that? So, we have a requirement that says that—we have a requirement, advanced transportation controllers. The TFCS shall use a transportation controller that conforms to ATC 5201 version 06A. We have another requirement, the application programming interface. The TFCS shall use a transportation controller that is equipped with API software that conforms to ATC 5401 version 02A. At the time of this recording, this is the latest standards.
Finally, one more here. I think this is the last one we’re doing. We have a user need for physical security. The city needs a TFCS enclosure that inhibits unauthorized entry into the cabinet. The enclosure should be tamper resistant, and use technology to restrict access to unauthorized users. Use of the common number two key in some areas of the city has resulted in unauthorized access and vandalism. So, we have our requirement that says, cabinet locks. The TFCS shall have a cabinet locking mechanism that uses a programmable key.
Okay, let’s do another activity. Which of the following would complete a well-formed requirement for our specification? The TFCS shall: A) be weather resistant. B) Certify conformance to the NEMA TS2 standard. C) Utilize a model 2220 auxiliary display unit, as defined by ATC 5301. D) All of the above? Please make your selection.
Let’s review our answers. If you said C, you were correct. Utilize a model 2220 ADU. This requires that the cabinet system use an ADU as defined in the standard, so we’re selecting this unit right out of the standard and making that part of our specification. If you said A, this was incorrect, because this is not specific enough to be verifiable. We have to define what weather resistant means. And, if you said B, conform to the NEMA TS 2 standard, this is incorrect because it’s inconsistent. A cabinet system cannot conform to both the TS 2 and the ATC 5301. TS 2 uses BIUs, it doesn’t use SIUs, and various other things. (Cough) Excuse me. So, if you said D, all of the above, that was incorrect, because A and B do not make well-formed requirements. Now we’ll move on to learning objective three, create a procurement specification for ATC cabinets. Under this learning objective, we’ll discuss considerations when building a specification and we’ll review a proposed ATC cabinet specification outline using the work that we did in the previous module.
Okay, here’s some considerations in creating a procurement spec. Agencies may have a standing specification for multiple projects, or have a specification for a single project. For instance, the State of California has a qualified product list, QPL. Other agencies have something called an approved product list, same kind of thing, where they set up products or a standard that is used for the agency for many, many projects. But a project, you may have a new project here that’s doing a corridor or something like that, and you may create a specification for that, just for that project.
A small number of agencies create a specification with complete detail on electrical, mechanical, and communications requirements. There’s only a few of them that do this, such as Caltrans, New York City, where placement of devices and screws and things like that may be called out. We’re not recommending that here. But an agency may have reasons for doing that, so we’re not prohibiting that, of course. 3) Sometimes agencies spec-in a particular vendor. Now there be some good reasons. There may be technical reasons, like there’s certain things about the agency’s cabinet systems that others are not doing, or there’s a certain fit in the cabinet that other manufacturers don’t mount to, etc.
So, there may be technical reasons to spec-in a particular vendor, and that’s what we mean by spec-in. Put something in the spec that actually zeroes in on a particular vendor. But also, sometimes there’s nontechnical reasons, and there may be good nontechnical reasons. There may be a certain—maybe a couple of vendors and there’s a couple of vendors that have proposed units, but one of the vendors doesn’t have the certification that you need, or they haven’t been in business long enough, or there may be nontechnical reasons for excluding a vendor. But if your choice in vendors is because somebody is your friend, that’s not a good reason. You just want to be aware that there are good reasons—there may be good reasons to spec-in a particular vendor, but there’s also bad ones.
Mind you, if you spec-in a vendor, a particular vendor, you may be limiting your choices in the future, so you need to be careful, very careful, about doing such things. I think one of the big things about using standards in general is that agencies have choices. So, try not to spec-in a vendor unless there’s a good reason for it.
So, fourth, the content of a specification may be influenced by how the project is awarded. So, a project may be low bid. In a low-bid situation, you’d better be probably very careful and make sure that you get all your features listed out in that specification, because whoever’s going to win is just going to be the lowest bidder. So, if you don’t specify everything you want, you may not get it. So, another method is a scoring method, and there’s others. These allow the agency to potentially select the best value for their needs. I think these are preferred methods, and if you can stay away from a low bid situation, I think the other methods are superior. So, the content of the specification may be influenced by how the project is going to be awarded.
The fifth here, we recommend that requirements in a specification are written to a level of detail that is necessary, not more. For instance, mounting, how the cabinets are going to be mounted, that’s pretty necessary. You need to make sure that the supplier is going to be able to mount to your foundations. Sometimes these foundations may be very old and not conform to any current standard, so that would be more reasons why you need those requirements in there. But you need to also be careful if you’re putting items in there that have mechanical drawings, that you aren’t driving the design of the cabinet system when you don’t need to. So, you need to be very careful with mechanical drawings.
So, this is the ConOps outline that we had from our previous module, where we captured our user needs. You can see that in section 7 of the outline. We had the scope, the purpose of the document, referenced documents, background, etc. The user-oriented operational description, and appendices. So, we have the user needs there in section 7. What we want to do is we want to take our requirements. We’re going to add, after section 7 there, we want to add a section for requirements, so we’ll have an outline such as this. So, we have user needs at 7, now we have requirements 8, and the appendices. Appendices is where we’ll have notes, we’ll have traceability and other things.
So, how do we arrange the requirements? Well, this is just one outline for the requirements. Agencies may already have previous specifications where they have different groupings of things. But in this outline, we have—this is section 8 of our specification. 8.1 is general requirements. Those will be requirements that affect the entire unit. Sometimes quality requirements are in there. We’ll have housing and mounting requirements. We may or may not have controller requirements in our specification.
ATC 5301 does not cover the controller requirements, but an agency may still have controller requirements in some sort of standing specification, or they may have a separate specification, specifically for the controller. I just put this in here as a measure to remind you of that. That was 8.3. 8.4, the input assembly requirements, 8.5 the output assembly requirements, 8.6, the field termination assembly requirements, 8.7, service assembly requirements. So, another outline might put 8.4 through 8.7 all in the same section. We have 8.8, environmental and testing requirements. We have 8.9, warranty requirements. Why do we put that in there? As ATC 5301 has no warranty requirement. Warranty is something that is put out there by the agency or by working with the manufacturers, etc. 8.10, we have documentation requirements.
Different agencies want different kinds of documentation with each unit shipped. Certificates of conformance and various things. Some agencies want two sets of documentation for each unit shipped. So, it’s just, whatever your documentation requirements, you’ll want that. Then 8.11, procurement requirements. This may be the biggest section in here, because you may have requirements for any part of the procurement process in your specification. Some agencies have a separate document for this, but some agencies put their procurement requirements right into their procurement spec for their devices.
So, what’s important? Whatever is not covered in ATC 5301 v02, or is tailored for the agency should be included in the specification. Just think about that. Maybe lots of processes have not been written down that you may need to end up putting in a spec, or at least writing them down someplace.
Okay, let’s do another activity. So, which of the following is a correct statement? A) It’s best to use warranty requirements found in ATC 5301. B) Requirements are a major part of the ConOps. C) Almost any part of the procurement process may have requirements in a procurement specification. D) Most agencies create specifications with complete electrical, mechanical and communication details. Please make your selection.
Let’s look at our answers. You said C, you were correct. Almost any part of the procurement process may have requirements in the procurement specification. Agencies need to strive to make the procurement process clear and to set expectations. If you said A, that was incorrect. There are no warranty requirements in ATC 5301. If you said B, that was incorrect. That was a little instructor trickery here. Requirements are not a part of the ConOps. User needs are. So, if you weren’t paying attention there, you missed that. And if you said D, most agencies create specifications with complete detail, that was incorrect. Most agencies only need engineering details in select areas, based on their needs and requirements.
So, let’s go on to our last learning objective, which is to verify the ATC cabinet specification. In this learning objective, we’ll look at our process one more time. We’ll talk about walk-throughs. We’ll do an exercise and then we’ll verify the specification using traceability.
So, let’s review this systems engineering approach for developing our procurement spec. So, we already have in our agencies, we already have strategic and regional plans, and there’s ITS standards out there, and we have our stakeholders. We need to get used to stakeholders are not just part of operations but stakeholders will be users and departments and maybe other companies or agencies that have adjacent systems. There may be people of various sets of skills. There may be even a politician or an assembly person that’s taking up the charge for helping advance transportation in your area. So, you have this broad base of stakeholders where needs may come from. So, all these go together and during user needs development. Again, that’s an iterative process there, where we identify the user needs and put in a rationale.
So, we capture all that in a concept of operations, which we did in the previous module, and we go onto requirements development, where we will take our stakeholders and also help us build the requirements. Now some of the stakeholders may not—some of the higher-ups may not participate in the detailed level of requirements development. We may also add other stakeholders that have more skills in this area or more knowledge of systems, as part of this requirements development process. So, when we do this requirements development for our specification, what we’re going to do is we’re going to create our specification from that.
Now we’re not going into tons of details of the design of the cabinet, because that is already done in the standard. But the user requirements, and we already discussed how all the different kinds of requirements we have. So, because of this process then, is we can have this traceability between strategic and regional plans and ITS standards, and from the stakeholders, and we can capture them in concept of operations. Then we can also have this traceability from the user needs to our specification.
So, let’s talk about walk-throughs. Now during different stages of the development process, we have a meeting to systematically walk through a document design or software. In this case, we’re walking through our document. The purpose is to find anomalies, improve our product, consider alternatives, and ensure completeness and correctness. Primarily, it’s performed, in this case, twice during the development, that’s during the development of user needs and the development of the requirements.
So, the specification developer or, there’s a specification developer or walk-through leader, leading the meeting and there’s potentially different audiences, reviewers for each stage. You have the larger body of stakeholders for the concept of operations and then to get into the requirements, we have maybe selected stakeholders.
So, a workbook, a walk-through workbook is created. That, along with in the case of the ConOps, you develop the ConOps, you would also send out a walk-through work group for a period of time before you have the meetings, so that people can do their own homework. Then you’ll come together for the meeting and you’ll have this book, and you’ll actually walk down through the document. It will have a checklist here. In this case, for the ConOps walk-through here, we’ll have a checklist for each user need.
For instance, is it a major desired capability? Is the rationale accurately captured? We can write comments or revise this on the fly even. When you get down to the requirements, you may leave the user needs right there and create a workbook then that just adds in the requirements. So, here we have a requirements walk-through matrix here, where we have—and we have a checklist of things. Is it well formed? Is it logical, consistent with the user need? Is there a user need relationship to a requirement? Back and forth. Is it feasible? All those different things. So, then we’ll have our requirements listed and we’ll take our notes. That will allow our specification developer, or developers, to go back and make enhancements to our document.
Okay, now we’re going to do a little exercise here, showing how this process, and what might happen during a walk-through.
So, we had our user needs, 7.8.1, standard cabinet configuration. The city needs a TFCS configuration that is suitable for intersection[s] that are outside the downtown area. The number of inputs and outputs need to support 80 percent or more of the intersections in this configuration. The city has plans to include a UPS in the cabinet and network equipment. Room is required for connected vehicle roadside equipment once the city chooses to deploy it. The city is identifying this configuration for ease of procurement. Remember, we had then two requirements. I didn’t write them out here. One for standard cabinet input channels, and standard cabinet output channels. I believe that was 24 input channels and 16 output channels. However, in stepping down through this during our walk-through, we discovered something and said, “Oh, we didn’t address this other part.” The city has plans to include a UPS in the cabinet and network equipment. Room is required for connected vehicle equipment once the city chooses to deploy it. So we didn’t really cover that. So, we needed to create a requirement to do that.
What’s important here is that we talked about the user need. It needs to cover every part of the user need, but also, the rationale that’s part of that user need can be a source for requirements that we need to cover as well. Because that’s exactly what the rationale is to do, is to help us understand what is intended. So, we created this new requirement here, 8.2.5, standalone cabinet reserve area. For standard cabinet configurations, the TFCS shall have a reserve space that is a minimum of 14 inches high and 3.25 cubic feet of space as shown in figure 8-1. So, sometimes a picture is just the best way to describe this and get the point across and that’s what we’re doing here.
This is where a mechanical really is helpful. So, here’s a mechanical drawing. It’s not to scale. It even says that, it’s not to scale, but it gets the point across that we want this reserve area in our cabinet space for our other equipment. Here’s where a mechanical became very helpful.
Okay, now in this though, now let’s think about this, now there’s also another ramification. The user needs for the downtown pedestal mount cabinets must be re-evaluated. So, the user need for the downtown cabinet configuration had the same requirements regarding the UPS and other equipment. The problem is that the downtown cabinets include those that are pedestal mount and roughly one-third of the space of the standard cabinet. So, what are we going to do? We’re going to either a) remove the statements about the additional equipment from user need 7.8.2, or b) have a smaller reserve space for the downtown cabinets, or c) we may have to bite the bullet and remove the pedestal mounted cabinets from our user need of existing foundations and the subsequent requirement.
So, here’s a case where we’re going to say, well, we may have to remove that need as well as the requirement. This is just an illustration of the process and it gives you a little feel of what happens.
Let’s talk about verifying the specification using traceability. We create a traceability matrix of user needs to requirements. We do this while we’re developing our requirements. It’s a tool to help verify completeness and correctness and again, we suggest capturing this during the process.
So, every user need must be addressed by at least one requirement. Every requirement must trace to at least one user need. Any user need that’s not addressed by at least one requirement means that a requirement was missed or the user need must be re-evaluated. Right? So, if we didn’t find any requirements, then we need to say, “Wait, did we really have this need, or did we just miss a requirement?”
Here we have our requirements continued here. Any requirement that does not address at least one user need means the requirement must be re-evaluated, or a user need was missed. Every aspect of each user need should be addressed by requirements, as we already illustrated. That’s needs to requirements. So, we create this table that’s sometimes shortened to NRTM. It’s a matrix here. We have our user needs on the left. We have the requirements identified, their identifiers all used there, and the names of the requirement identified. This is an NRTM.
Now if we put this together, what we developed in our traceability in the previous module, where we had our user needs and we had them traced to the sources of those user needs, and we put that together with our user needs to requirements, what we’re showing here, through tables, is we’re showing this connection to things that have been established by the agency through the planning and blessed by community leaders and other stakeholders. We’re showing how our specification fits into that and traces back to those things that they desire.
Let’s do our activity here. Which of the following is a true statement? A) The rationale of a user need should be examined for requirements. B) Every user need must be addressed by at least two requirements. C) It’s best to wait until the end of the requirements development to start a traceability matrix. Or D) All of the above. Please make your selection.
Let’s take a look at our answers. You said A, the rationale should be examined for potential requirements, that was the correct answer. As we went through our exercise, we showed that. The rationale provides understanding that can be a source for requirements. You said B, every user need must be addressed by at least two requirements. That was incorrect, because every user need must be addressed by at least one requirement. And C, it’s best to wait until the end of the requirements development to start a traceability matrix. That’s not the best way to do it. It’s best to capture traceability throughout the requirements development process, so that you make sure that you are capturing all the coverage a requirement may have to user needs, and that you catch holes early on. So, if you said D, all of the above, well, that’s not the right answer because B and C were false statements.
Okay, this has been a great time together. I appreciate the opportunity to lead you through this process of creating a specification for an ATC 5301 cabinet. We had four learning objectives. We described the features of ATC 5301 standard. We wrote requirements for the ATC cabinets. We created a procurement specification for ATC cabinets, and we showed how to verify the ATC cabinet specification. What we did here is we had an interdisciplinary collaborative approach that satisfied customers’ expectations and met public acceptability. Thank you so much for taking and participating in the PCB (Professional Capacity Building) program.