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 module A322a: Understanding User Needs for Transportation Field Cabinet Systems Using ATC 5301 version 2. Hello, my name is Ralph Boaz, and I will be your instructor today. I am a project manager and system engineer for the ATC and NTCIP standards programs. And I, in addition to developing standards, I also help agencies and companies and other public-sector people to specify and deploy ITS standards, as well as with the training and other support. We’ll have an interesting discussion today.
First, I’d like to say that the ATC 5301 standard, which is commonly called the ATC cabinet, is 1 of 3 standards in the ATC program. The other two standards are the ATC 5201 standard, which describes the traffic controller hardware and then the API or application programming interface standard, which is ATC 5401, which describes API software that allows multiple applications to run on an ATC controller.
This is the first of two modules that we’ll be discussing. This one, we’ll be focused on building a concept of operations and the second one will be focused on developing that requirements and together these two courses will help you develop a specification for procuring ATC cabinet systems.
Today we’ll be discussing these learning objectives. It will explain the advantages of transportation field cabinet systems based on ATC 5301. This will describe the structure of the standard. Next, we’ll identify and write user needs for ATC cabinet systems. And then we’ll put this all together and in the last learning objective and create a concept of operations for ATC cabinets. Let’s look at learning objective one.
Explain the advantages of transportation field cabinet systems based on ATC 5301, and this under this learning objective will discuss the basic operations of transportation field cabinet systems. We’ll look at the evolution of, of these systems over time. We’ll talk about the history of the development of the ATC 5301. And then, finally, we’ll discuss what the construction of ATC cabinet in a generic sense and then summarize its benefits.
So our first learning objective is to explain the advantages of transportation, field cabinet systems based on the ATC 5301 standard. In this learning objective, we’ll talk about the basic operation of transportation field cabinet systems, the evolution of these systems, we’ll talk about the brief history of the development of this standard, and then we’ll go into a kind of generic representation of the standard, and summarize its benefits.
There’s a lot of good stuff in there. So here we have a representation of ITS cabinet. You know these are at all signalized intersections and these are the components of any cabinet system. We have inputs where we get detection from the street. We have a controller, which knows how to understand those inputs and safely control the intersection, do actuated single control, and other things.
We have outputs, which control the power that goes out to the signal heads or other devices that we’re managing. We have monitoring that makes sure we don’t have conflicting colors and we have more advanced monitors, monitoring it in the latest standards, that will look at the communications going on in the cabinet as well. We have power supply that, that gives power to all the devices of the cabinet and we have an internal bus, which handles the communications between the devices.
So, we’ll take a look at a basic operation of how these work, we have field sensors in the street, detecting vehicles, and we’ll just keep it to the vehicles, but we have peds (pedestrians) and bicycles and other things as well. That comes into the input functionality of the cabinet. Those inputs are mapped to different turning movements, which the controller understands, and then we’ll make the good decisions to service those vehicles.
The controller will determine which outputs to turn on and off to manage the intersection. And that will result in power going out to the signal heads, and also going to the monitoring function of the cabinet, which make sure there aren’t any conflicts. Cabinets built on newer standards, we also will monitor communications, and that monitoring also includes communications with the controller.
So something that we needed to cover to appreciate some of the benefits of this new ATC 5301 standard is the idea of input channels. Traditionally, we’ve had one channel detectors and each, each detector then manages one loop, or sets of loop, that are on the same, on the same channel. And so, each, again, it’s one detector loop detector managing a series of loops on the same channel.
And so, but we also have now two channel detectors. So, what we did with once with one detector, we can now do with two. And so here, you should see that a single detector is actually managing two loops, or two sets of loops.
Now, one line is shown here, but actually, a loop has two lines per intersection or sorry, per loop. And this is just drawn this way for to show the logic/logistical part of it. So, the same thing occurs with our output channels, how we control the displays in the street. We have single channel output switches. And they will control each switch pack or load switch, there are synonyms. Each switch pack will control one signal header or a series of signal heads wired together. But now we have two channel switch packs. And those can do the same job as two single channel ones where we can control two sets of signal heads up with one switch pack.
So, so in the same space, we can now, if you can see the advantage here, in the same space, we can manage twice as many load switches or switch packs, as well as in the case of the input rack we could manage twice as many the sensors in the street. Here, we show the evolution of transportation field cabinet systems over a period of time.
And in the forties, we had electromechanical controllers. In the seventies, we had NEMA TS 1 standard and the model 3XX specifications from Caltrans and the State of New York. In the nineties we developed the NEMA TS 2 standards and then in the mid-2000s, we had the ITS cabinet version one; the interesting thing is that in our industry today, all of these types of controllers that are cabinet systems are still in use.
Now we’re going to go through each one of these briefly. Here we have the electromechanical controllers and this, this worked like a timer for the lamps in your house had clips to trigger the outputs in the street. Here we have the NEMA TS 1 standard, it was a functional standard, you can see it was shelf mounted, had a wide variety of cabinet configurations actually defined, actuated signal control within the standard. And all the devices in the cabinet had flexibility in their physical makeup, and in the major assemblies. And also, environmental tests procedures were included.
The technology used for communication was actually electrical wiring, so you had a kind of point-to-point wiring to the controller when there was when there was actuation or when sensor was actuated, and then you also had point from the controller to the outputs to control the signal heads. This was the Caltrans specification in the New York City spec. This use[s] that same kind of technology as far as point-to-point wiring.
This cabinet was rack mounted and it was more prescriptive in how it was put together, obviously in the, so you had, you always had sections of cabinet, pretty much in the same configuration. The interesting thing here was, with this, was that software could be provided by others and that you’ll see how that plays into our ATC cabinets. So then we went to NEMA TS2 and in TS2 we expanded the scope of the functional standard that was developed in TS1.
Load switches and detectors were then interfaced in this in this standard via a serial bus, over bus interface units. So, we actually used communications between the controller and the other assemblies versus point-to-point wiring. The MMU not only looked for conflicting indications on the single heads, but it also looked at communications in the cabinet. In the 1998 version of TS2 included requirements for NTCIP 1202, center to field communications. Then, in the mid, you know, in around 2005, 2006, we have the ITS cabinet version one. It was a rack mount design and it was very modular.
You could, if you look at the right side of this blow up, you can see that there was a connectorization all up and down the cabinet that allowed you to put an assembly in almost any position in the cabinet was easy from a technician’s point of view in that regard. It had a small cabinet monitor unit, has a faster serial bus than we had in in TS 2 and the cabinet was designed to do multiple types of applications.
So, let’s look at a history of this of the ATC 5301 standard development. Again, ITS cabinet version 1 was published in 2006. There was a funded effort on version two of that standard in 2008 to 2010, we look at the industry’s needs and that included all kind of things that affected the industry, where there’s a ban on incandescent bulbs. There was mercury regulations established and other State safety regulations that were affecting our industry.
The funding eventually ran out, and we worked continued to work on a volunteer basis into 2011, and the result of that was an ITS cabinet version 2 standards requirements specification that included a concept of operations with user needs identified and high-level requirements. After that, three manufacturers continued to work to a detailed level on designs and produce working equipment, which was a great advantage.
As when we came back together, we had experience with what we had started out with, so the project, again, was funded in late 2015. Lessons learned from the manufacturers were incorporated into the standard. We changed the name from ITS cabinet version 2 to the ATC 5301 cabinet standard version 2, and sometimes it’s called an ATCC, and so that brought us all the standards together under the same family name. The standard was jointly approved in the fourth quarter of 2018 and published in March of 2019. In the process, there was over one thousand comments adjudicated and put, and addressed in the state in the standard. And so there was a lot of feedback provided. And today there’s over one thousand ATC cameras deployed across the U.S. produced by five manufacturers.
This V diagram, you’ll recognize it from other modules in the PCB program, but this is also mapped to the different milestones of the project. I won’t go into details of this, but this will be in the student’s supplement, and is also in the standard. Now, we are going to speak about kind of a general representation of an ATC cabinet so that we understand what we’re trying to specify. We had design goals in developing the standard, and that was to focus on increasing value to the end users. More capability for your money.
And then we talked about, then we put it into the standard, flexibility, so that we could provide for more innovative designs, we didn’t want to specify every nut, bolt, or screw in the cabinet and then make that cabinet only suitable for a short period of time, but we wanted to have this flexibility going forward. We wanted higher density. We wanted to have more capability in a smaller space. We were concerned about technician’s safety, what technicians to be subject to. Electrical shock, for instance. What it increased public safety wanted to do things with this cabinet system that maybe we couldn’t do before and increasing public safety.
We wanted to have enhanced monitoring. This was to help us diagnose what’s going on in the cabinet and being and helping our technicians be more efficient and have less downtime in the street. We wanted it to increase cabinet power efficiency, of course, we’re talking about overall cost to agencies and we wanted to see if we could improve that, the use of power in our cabinet systems. And then finally, we wanted to provide better LED signal compatibility since we are losing our incandescent bulbs out there. Those are mostly been replaced in the country, but still in progress.
And we’re using LED signal heads and wanted to see what we could do to, to maybe have better systems for monitoring LED signals, and then also for, maybe in future, having again, relating to power efficiency, what we could do there. Now, we’re going to go more into the content of the cabinet systems. So, in this representation of the cabinet, [we] will talk about assemblies and assembly as any subordinate element of the system that’s made up of multiple parts or components, and there’s major and minor assemblies and the major assemblies are the input assembly, the output, assembly, the field termination assembly, and the service assembly.
Now we also we also talk about components when we’re talking about the ATC cabinet. And a component is an electronic assembly with major functional attributes of the system where some level of functional or physical interchangeability is desired. So when we think about components, we’re really, we’re talking about interchangeability of those devices. The components are serial interface unit or SIU, the high-density switch pack/flasher unit, which is HDSP/FU. When this, the same device, is operating as a switch pack, we just call it the HDSP; if it’s, if this device is operating as a flasher unit, we call it in HDSP/FU.
We have the cabinet monitor unit CMU, you have the cabinet power supply, the CPS, the auxiliary display unit, which is the ADU, and a sensor unit. This is a generic way of talking about the detectors or other kinds of sensor technology, we call SU. So, here, on the left, you see that functionality we described earlier in our presentation. And now we’ll kind of blow that up on the right side in the case of the ATC cabinet and we’ll keep with the same kind of color coding that you see here on the left. So at the top, you have the controller unit, the brains of the operation. Here we have our input assembly, and you can see there’s the SIU, and the various sensor units in this assembly.
You recall, the SIU has to do with the communications serial interface unit; here, we have our output assembly and here we have the SIU for communications. We have the high-density switch packs, we have the cabinet monitor unit, and there’s other switches and things for managing the cabinet. The CMU has an optional device identified in the standard, it is called the auxiliary display or called ADU. It [gives] you an easy access to what the CMU is doing, and so most deployments I see have been including this display.
Here, we have the field termination assembly, this is where all the wire/wiring from the street power going out and the inputs coming in are attached and it’s all touch safe design. We have our service assembly, you have some GFI plug here. We have the flasher unit, and then we also have our cabinet power supply, which powers all the units, all the devices in the cabinet. Ok, so what are the benefits?
It’s a functional standard except where component interchangeability is desired. So, for instance, in this standard, you won’t see a cabinet drawing, that’s explicit about where everything goes. You won’t see a specific design for the field termination assembly and things like that. So that packaging, there’s flexibility in the standard to do all kinds of different cabinet designs, but the internals are all the same and how they communicate the signaling and such. So, we’ll show you that in a minute.
We have double the number of detector channels in the same space. So, remember that double, double the number of channels per switch pack, and a switch pack is physically smaller than previous designs. We eliminate the arc flash hazard, which can electrocute technicians if they’re close to equipment and it’s a touch safe design meaning they can’t accidentally bump into a live wire; it is all nicely tucked away.
There’s a low-voltage option for 48 VDC field wires. This is a big deal because when you have knockdowns during, let’s say, a storm of a traffic signals, you potentially could electrocute people, but 48 VDC is electrically safe for humans. Most assemblies are replaceable while the intersection is in flash, is rare, that you would have to do something like that. But you could, we’ll show you in a minute, just what you could do if you needed to service a unit during a storm, or as a result, of the storm.
There is load current monitoring for detecting dark approaches, said it just monitoring voltage. We monitor current so we can determine if a signal has, like a series of signals of signal has dropped because the current draw on the cabinet is different. We can also detect on a single signal head if we’re losing LED is in the in the LED head and can determine if we’re having problems with that, that particular signal head.
So, this load current monitoring is a very powerful thing in the ATC 5301 standard and systems based on it. We have better because of these things and lower drawing components, we have better LED compatibility and we will, we have a potential or power conservation in alternative power sources. So, I talked about this, having major assemblies being removable. Well, so, if something went wrong in this cabinet in the street, often if you have something major, you have to put, you know, get the police out there, and turn off the power.
And so the signals are all dark, and that’s a dangerous situation, but in this case, you can actually remove ADU which makes sense, because it’s an optional feature anyway. You could remove the ADU, but you could also remove the detector rack. And you could even remove the controller, and you say, well, that’s OK. While you still have that, you still have the outputs being controlled by the high-density switch packs, but you could even remove the output rack, and as long as your flasher unit is in the remaining part of the cabinet, you can keep that signal, keep that intersection in flash.
This is pretty powerful for some, it was important to some agencies, and if you’re not in a bad weather place, this might not be as critical. So these are just some examples. There are many designs. The companies that create, the manufacturers that create these cabinets will have different designs within their systems. I just brought out some examples on the left that this cabinet is from Intelight. It’s a 15-inch cabinet, so it’s a skinny cabinet, and has like 32 channels of detection has 16 channel output channels, it has the ADU, just a lot there in a skinny cabinet.
In the center, we have a cabinet here from Econolite. This is actually a 48-volt cabinet, and it has 48 channels of detection and 16 outputs, and this cabinet has actually a battery backup system built into it. Then on the right, this is the early picture of a ITS cabinet. This one was from McCain and I like this picture because it just demonstrates how much room you now have in the rack that in the, in the 332, you know, traditional 332 world was packed, full of things and this, and you can just see how much room there is. On the left there is a picture of a cabinet from MoboTrex. It just shows how an existing NEMA cabinet can be retrofitted with ATC cabinet devices.
On the right is a cabinet from Trafficware and the designs look somewhat similar but can differ in different in small ways. And then old cabinet designs can be radically different in terms of shape and size and such. But all the electrical signals are the same in all these, so if you are a technician, and, and I was working on all different types of cabinets from different companies, you could troubleshoot them in the same fashion. So this kind of summarizes the IO and cabinet kind of types that we discussed previously.
Starting at the bottom, TS1, it was shelf mount, had parallel wiring, discrete wiring between the devices eight input channels, and it had monitor output channels up to 18. The Caltrans, 332 was rack mount. Again, it had parallel or discrete wiring between devices, had a conflict monitor, it had 14 channels of output, had 44 input channels, and up to 18 monitor output channels.
NEMA TS2 shelf bound had serial communications in the cabinet, 64 input channels, and up to 16 output channels. Then, we made a big jump when we went to ITS version 1 cabinet: 120 input channels, 28 output channels, a faster serial bus; now we have the ATC cabinet version 2. ITS cabinet was strictly rack mount ATC cabinet says, hey, you could be rack mount or shelf mount whatever your housing it has a faster bus, has a cabinet monitoring unit, 120 input channels, and up to 32 output channels monitor. The big deal is with the ATC cabinet that you’re doing the same things that you did in the ITS cabinet but in about half the space.
Ok, now, we’ll do an activity, have a little quiz for you. So, let’s see what we can glean from this first learning objective. Which of the following is not a benefit of using the ATC cabinet Standard? Your answer choices are A, Low-voltage option for 48 VDC on field wires; B, Touch safe design; C, Functional standard, except where interchangeability is desired; D, The same number of channels per switch pack as the ITS cabinet version one. Please make your selection.
Let’s look, if you said D, the same number of channels per switch pack as ITS Cabinet version one, that was correct. Remember, we were saying which was not an advantage of this new cabinet system. The actually, the ATC cabinet has doubled the number of channels per switch pack than previous ITS cabinet. So, if you said A, Low-voltage option, that was not correct, the ATC cabinet has a low-voltage option that would help protect the public. In case of knockdowns. If you said B, a touch safe design, that was incorrect. A touch safe design, protect technicians from high voltage in exposed wiring. If you said C, you’re incorrect regarding the functional standard, the ATC cabinet allow[s] for innovation in cabinet designs while maintaining component interchangeability.
Ok, now, we’ll move on to our next learning objective. [We] will describe the structure of the ATC 5301 standard. It’s kind of get you a feel for the standard itself. In here, we’ll talk about the basic operation, and will go through the structure of the standard itself, will go through a high level, a functional block diagram, which is key to understanding the standard. And then we’ll talk about traceability within the standard of needs and requirements and design. Ok, so, the section of standards, we have the purpose of the document, the scope of the project. We have reference documents; we have conventions used in the document. And we have this high-level block diagram, which would go into the details.
Here we have the components, these are the electronic assemblies where we want the interchangeability and the devices we have slots are the mechanical mounting hardware and electrical connectors to hold the interchangeable modules. Interfaces, that’s how we electrically connect the system elements shown in the block diagram, and we’ll go into that. And then we have protocols, this handles the messaging that goes over the serial buses. We have a product safety and reliability requirements. We have environmental testing requirements, wire requirements, that we go into ratings of wires and conductors and splicing, etc.
We have acronyms, and we have a needs to requirements, needs to requirements design traceability, this shows our completeness, correctness of the standard, excuse me. We have nonfunctional requirements, and this is really just a priority system we invented to help us make decision design decisions during the development of the standard, and then there’s last section, is the power signal naming conventions for this cabinet system.
So, the standard earlier in the standard, it contains two high-level functional block diagrams. One is for the operation of 120 20 volts AC (VAC) and another for the voltage for the version that is a low voltage operation of 48 volts DC (VDC). It is central to understanding the detailed design of the standard; it identifies a relationship with design elements and interfaces. And then each of these design elements and interfaces are broken down later in the standard, as I talked about in the sections from the previous slide. And all the design elements, except for sheet metal have interfaces and interfaces have electrical requirements, and only some of the design elements and interfaces have mechanical requirements. This is leading to our functional standard.
Ok, so, there’s some symbols that are used that we use to help us understand the functional block diagram. If there’s an oval hatched symbol around it that indicates that an interface is defined in the standard electrically, but may require an adapter or interchangeability among manufacturers. And we’re not getting down to the interchangeability part of that. If the oval symbol has a solid line, indicates interface is used to connect physical cabinet elements. Similarly, if there’s a hatch symbol or a dash around a something in the block diagram, it says the functionality is in the standard, but the standard does not control the mechanical dimensions and if it has a rectangular symbol with a solid line indicates that that assembly is covered specifically in the standard including mechanical dimensions.
So, this is an example of the high-voltage functional block diagram, and as you can see, I’m not going to go into details of this, it’s just way too detailed, you can, you can look at it in the standard, but I did create an overlay here, which I’ll show you. That kind of shows you the difference, the functionality that’s described in the top of the diagram.
You’ll see the input functionality in this diagram is continuing with the color coding that we discussed previously in this presentation. And you can see the SIUs there, in the input functionality that handle the communication. In the center, you see the output functionality, and colored you see the load switches, which is called out there, and, again, an input, some of these sensor units.
But here, we also see this, the serial interface, its units handling the communication. And then to the right, as we go down here, you see the power functionality there, and then if you go to the left, you see the cabinet monitor unit, ADU, that is there to handle the safety aspects of the cabinet. So, this is kind of the arrangement of this high voltage functional block diagram. I will include these diagrams in the participant supplement as well, if you want to go down through it in detail.
Ok, so traceability is in the standard is found in section 14. It’s a traceability has done a bit differently than in other standards, because the user needs are formerly documented in a separate document that’s in Cabinet version 2 requirements specification.
Remember, we changed the name from the ITS Cabinet version 2 to the ATC cabinet version 2, and so that the user needs and the requirements for the standard are found in that separate document. There are still verification of requirements, there’s a use the user need for each requirement in each user need is supported by at least one requirement. And then in the standard, there is a design description that these requirements led to. So, all of this provides for verification of the standard in the development, and also provides for validation of a product when a product was built to the standard. So, I’ll just give you an example here, couple of examples of how this works.
So, there was, there was a requirement on, this particular one is number 5.13.1 called Diagnostic Display Local Display, and it says the transportation field cabinet system should contain a diagnostic display unit, which supports the local display of both historical and current cabinet status and log data collected by the monitoring system. This was done earlier. We changed the name to ADU, but this was a requirement that was in that document, and then that requirement came from this user need, which has the ID, 4.3.1. 20. User need, was the user needs, a TFCS to be of a design that reduces the time required for maintenance personnel to perform maintenance actions in the field.
So, we see that the requirement came from this user need, that's the justification for it, and then the design elements in the standard are then reference.
So, if you want to know what came about from these requirements and this need requirements, we would go down to section 1.6.5. model 2220 Auxiliary Display Unit.
So, this connects this ITS cabinet requirements specification with the standard. Other standards, other ITS standards, you’ll see how that information all within the standard, but that was not done this way, in this case.
So, another one. This talked about requirement to have low-voltage switch packs, has the specification does that requirement for the voltages, the justification for this requirement or the user need was the user needs the TFCS to provide field wiring that is at a voltage and current levels below those dangerous to humans.
References which user need it was. You could go to the ITS cabinet version 2 requirements specification, you’ll find that section in there, and it’ll show the user need, and then this leads to the design element, that’s actually in the standards that are there to meet these requirements, and that’s the field signal voltage sense inputs in the section here, on field signal outputs, and there were as many others, I just couldn’t list on this slide.
Here’s another one, two to output channels per high-density switch pack 120 and the requirement is the HDSP shall have 2 output channels and this came from the user need to support the use of output devices that have higher channel density the company deployed at the time field output devices. Source here is user need 4.3.4.1, that’s in the requirement specification and then if you look, you want to look at that design element that meets that requirement you go to the model 2202, high density, switch pack/flasher unit. So, that’s how traceability is done. It’s been done, it’s just not included in the standard but the requirements and needs are not in the standard but you can see that is done and included in this table included in Chapter 14.
So, OK, so now we have another activity. True or false? The high-level functional block diagram identifies how the ATC cabinet functions perform actuated signal control. Please make your selection. All right, let’s take a look at our answers.
You answered false, you were correct, the high-level functional block diagram, identifies the relationship of design elements and interfaces. You said true, that was incorrect actuated signal control as described in the NEMA TS2 standard. That is the operation of how we make decisions about, about signal control, and the safe handling of the intersection. That’s not in this standard. Ok, let’s move on to our next learning objective.
Learning objective three will identify and write user needs for ATC cabinet systems.
Now, I want to say, when we go into this, that we go into writing, creating a spec that we don’t need to go in and write user needs and requirements that are already in the standard. Some agencies may do a cut and paste but that’s a lot of work, and a lot of necessary, you know, handling of, a document that you may not want to do. But instead, we reference standard, I will show about how we go about doing that. We reference a standard, and then write, identifying, write user needs that are particular for our agency. And so, that’s the approach that we’re taking here.
So, we just showed you the traceability of user needs and requirements that were done in the cabinet, but again, here we’re going to be writing those for our agency. So, in this section we’ll talk about the systems engineering approach to developing the ATC cabinet specification and actually others, we’ll review the characteristics of well-written user needs and then we’ll go through some example needs for our cabinet system. So, I really love this definition of systems engineering and interdisciplinary collaborative approach to derive, evolve, and verify life-cycle balanced system solution that satisfies customers’ expectations and meets public acceptability.
And that’s what’s really powerful to this approach to actually writing our specification. So, in system engineering, we have this process of identifying and capturing user needs, and we do that for a while and then we say, we’ve gotten this to a level that we can do. And then we move on to a stage requirements development. And we developed requirements based on those user needs that we developed previously. And then we also, during this process, will often find, oh, we forgot about something. So, we go back and do a little more user-needs development, may come back and do more processing on the requirements.
So, you see this kind of moving in stages, but at the same time there’s something is cyclical about it also. Then, after we’re sufficiently happy with the requirements, then we move on to the design elements to that, to meet those requirements. And we go into, and the design elements to the extent that we want into our system. And then again, during the design, we figure out the requirements that need to be amended or added in.
And again we have a similar thing going on, where we move the stage, but there’s still an element of going back in and changing things and correcting them.
So, this is systems engineering. Well, let’s apply this to the development of our specification, in this case. We’ll start with our stakeholders. Stakeholders are used to, to establish user needs for any system, and we will want to advocate that you have a broad base of stakeholders from both technical and non-technical and we have added to your group their diverse aspects of your organization, we have IT standards that are already established. We have strategic and regional plans that have been established. And this is really important, because the public is aware of those things are what agencies and MPOs and such advertise around about the great plans that we have going forward for your jurisdiction.
And so we, we have all those flowing into this user-needs development. And this is important to include those plans as part of part of understanding what needs we have for our system and for going forward. So, when we do this user needs development, we capture this, if you know this already, from other modules in the PCB program, but to capture these user needs in a concept of operations, that’s kind of the residual part of this development of this user needs development is this concept of operations.
Well, then we move on to requirements development, OK?
So we need requirements based on these user needs, and remind you, these are user needs that the agency has, these aren’t brand new, aren’t just copies of what’s in the standards. And we may be deriving these user needs out of these regional and strategic plans as well. And then, so we developed now we develop requirements, so user needs are kind of like goals, requirements must be verifiable. So this is the concretes. These requirements become more concrete. And then from this requirements development, then we can create our agency specification and we, and we will show, in the next module, how we can use this concept of operations, right in our agency spec. And then what we have is we have this traceability that goes back to the stakeholders and the regional plans and strategic plans the public knows about it was we have this traceability through the ConOps and write to the agency specification.
Now, I talked about that not all agencies may do this, but you’re going to find that some Federal projects require a systems engineering approach to getting funding for such systems, but this is a good practice for any agency. So, the relationship, a user needs to requirements there may be a one-to-one relationship of user needs, or requirements has to be at least that. There may be one to many, which is most common, where you’ll have a user need, and it will result in multiple requirements. But sometimes you’ll have multiple user needs that is that one requirement applies to, and typically, they’ll be others more than one that to address both needs, but you just shows you a relationship of needs requirements here. So, there may be one-to-one, one-to-many, or many-to-one.
So, our System Engineering approach benefits user needs are identified by a broad base of stakeholders existing strategic regional plans already approved by policymakers, are part of the user needs development. It provides justification for investment in ATC Units that non-technical people can understand. And it shows accountability to the public, right? You’re not just, this is not the traffic engineering department, wanting a new widget that shows that, hey, this, there is a need here, and we’re following through with what this city has already decided. Those of you who have taken many of these modules will already be familiar with this, but we’ll cover it here.
We’ll talk about how do we identify user needs, and we express them in a formal way. And we call these well-written user needs. We say, they need to be uniquely identifiable. It needs to have a major desired capability needs to capture the rationale. You know, it gives us background on this need or why we need it. And it’s solution free.
It’s not like a requirement that we’re trying to specify exactly how it’s how it’s going to be satisfied. We don’t put that into a user need. Think of these more like goals.
So, here’s an example, we’ll go through some examples that I thought of. The name of this user need is modern ITS standards and specifications, so we give it a number as well. So, in this case it’s 7.1.1. And what’s going on here, I have a numbering system here that will also help us in the next module and A322B you’ll see how this fits into the outline so that’s where the number that’s coming so it’s uniquely identifiable we have a number and a name. It’s a major desired capability. So the city needs the transportation infrastructure to be based on modern ITS standards and specifications, OK?
So, here is a need that helps us draw in our ATC standard and other standards so the city has realizes that it needs the latest and greatest here. And then we have this rationale that explains that, just as much of the city’s ITS infrastructure, is based on 25 to 40-year-old technology. The technology infrastructure based on modern ITS standards provide choices for ITS solutions today and in the future, to also offers the best opportunity to leverage new technologies from for mobility and safety. So that captures the reason that we have this, that we want this capability—the rationale.
We look at this, there was no, there was no solution provided, just describe what the need was, so it’s solution free.
Let’s take a look at another one. So this one is existing foundations, it’s uniquely identifiable 7.2.1. It says the city needs TFCS to use existing cabinet foundations at signalized intersections. It’s a major capability. Let’s look at the rationale, capture the rationale here, it says, intersections outside the downtown area, have 332 cabinet foundations. The downtown area has both 332 cabinet foundations and pedestal mounts for 336 cabinets. City wants to avoid the cost of having to replace foundations when installing a new cabinet system, in this case, you could have just said, you might not wanted to say 332, but I could see, in this case that part of our stakeholders were the traffic engineers, or maybe the maintenance people. So they could give us a little more information.
We didn’t go into the description of the foundation exactly the measurements and things like that might be in a requirement, it just describes kind of the ballpark of these foundations is showing that they’re different. So, this is our rationale. And then we, again, we didn’t go into those details, so it’s solution free.
OK, here’s another one, 7.4.1, 120 VAC service power. OK, let me, we’re not highlighting these now. We’ll just move through them quickly. So, the city needs the TFCS to operate using 120 VAC service power, that talks about the numerous devices that need 120 VAC and talks about a changeable lane assignment system and the lighted crosswalks that requires high power. Again, it’s uniquely identifiable to major just a desired capability. It captures the rationale, it’s solution free.
Here’s another one. This is a procurement specification basic need. This one is called 7.8.1 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 needed to support 80 percent or more of the intersection in this configuration. The city has plans to include a UPS and the cabinet network equipment. Room is required for connected vehicles roadside equipment once the city chooses to deploy it. The city is identifying this configuration for easy procurement, OK. So, the city is going to have a bunch of cabinets that are of this configuration. So, procurement people said, let’s create a, what we call, a standard cabinet configuration, so this is a user need for that.
This, in turn, the next one is the downtown cabinet configuration, and it goes on to state that you/they want a second configuration. This is our procurement people at work here. That is suitable for intersections that are in the downtown area and then goes on to describe, describe that. And so this just shows you this, this is for ease of use are procuring the devices that they’re going to either be in one family or the other generally.
And there’s always one offs, as we say, that have some special needs, but they want to be able to buy these in bulk. It’s uniquely identifiable. A major design capability captures the rationale and solution free.
OK, here’s one, 7.4.2—multiple applications. The city needs to be used for multiple concurrent running application. City wished 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 or adjacent ramp meters, and smart city applications not yet identified. It’s uniquely identifiable. It’s a major desired capability. It captures the rationale and its solution free. We’re not telling them how it’s going to do this, but needs in this area might affect size, might affect communications that ended up being in this cabinet, etc.
And here’s one called Physical Security. The city needs a TFCS enclosure that inhibits unauthorized entry into the cabinet. This is a big deal nowadays, that, you know, there’s vandalism, etc., are going on. So that’s our uniquely identifiable and it’s also that’s our major desired capability. A rationale says, the enclosure should be tamper resistant, use technology to restrict unauthorized users, use of the common number two key in some areas of the city that resulted in an unauthorized access and vandalism, I’m not saying how that’s going to be done, but we justify this need and it’s solution free.
OK, let’s go on to our activity.
A - Rationales of user needs have proposed solutions.
B - User needs must be testable.
C - An user need is a major desired capability.
D - Only needs in ATC 5301 v02 are valid for a spec.
Please make your selection. OK, let’s look at our answers. We’re looking for the correct statement. If you said, C, you’re right, user needs are major desired capability, they’re expressed at a high level and think of them as goals. If you said A, you were incorrect. A rationale helps to understand what’s intended by major desired capability; it does not have proposed solutions in it. You said, B, user needs must be testable. That’s incorrect. Requirements must be verifiable. And one method of verifying requirement is testing system as generic user needs are not directly testable. Remember, we’re thinking about them as goals. And if you said D, only user needs in the standard are valid for a spec. That’s incorrect.
Agencies will have user needs that are based on their particular policies, area, existing equipment, and other things, and, in fact, we suggest that you don’t put the user needs that are in the spec, I’m sorry, in the standard, in the spec, and unless there’s a particular need from the standards development that meets directly to a need you discovered in your own needs development process.
Great, finally, we’re down to our fourth and final learning objective: create a concept of operations for ATC cabinets. In this section, we’ll talk about the structure of a ConOps, we’ll talk about the organization of user needs, and then we’ll talk about traceability to user needs to sources. Here’s an example of an outline from the FHWA system engineering guidebook and slightly modified for our purposes of the structure. We have a purpose of the document, the scope of the project, reference documents, background for the system, concept for the proposed procurement, user oriented operational description, user needs, and appendices. We’ll go down through this.
So, the purpose of the document is, here we don’t need to think about we’re creating an encyclopedia, here. We want to be brief and to the point as much as possible, but we want to also make sure we cover everything we need to, but the purpose of the documents, a brief statement, a couple of paragraphs, we want to hit in a higher-level expected operations of the system. We want to state that this is an instrument for stakeholder discussion and consensus, and then have you know, maybe a paragraph, or you know, some sentences on the remainder of the document, the contents, attention, audience, and such.
So, the scope of the project, it’s like another couple of paragraphs, the brief overview of the system that you’re wanting to procure. The part that you talk about, the departments that are involved in other agencies involved, directly and indirectly. So how, how big is this project? Reference documents, we talk about the documents and other resources that are useful in understanding the operation of the system, so, we want to get those documents, and here we also want the strategic plans or regional plans referenced in here that create or influence the user needs for the procure.
Background, there’s a brief description of the equipment, how it’s used, and its drawbacks. So you’ll be talking about, you’re laying the foundation here for why you’re going after this, this particular Family of cabinet systems. You’ll want to talk about maybe the drawbacks of your current situation. You want to have reasons for proposed procurement, and the general approach to improvements. So, what you can do is a steal from those benefits that we had in the first learning objective here for your, some of your background information.
Concept of the proposed procurement. You want to discuss alternative concepts and why they’re not optimal. The high-level description of the ATC cabinet in use and the justification for the approach, again, that that you can go back to the previous material and draw from that. So, the background is probably more oriented towards what’s going on. Currently, in the concept of the proposed system, this is where you are.
OK, so here, this, in section six here in the ConOps, we talked about user-oriented, operational description. Here you talk about how the goals and objectives are accomplished currently, describe strategies, tech as some policies, constraints, again, this is how you’re operating now, these first two bullets. The next bullet is describes a stakeholder’s, this is all who’s involved now, and what they’re doing, and then also to describe in the next bullet, describes the personnel, the organization, those kinds of things that are involved in this project.
OK, and chapter seven, remember all the user need[s] start with seven. Well, that’s because we have that’s where we’re putting our user needs here in the ConOps. Description are vision, goals, and objectives, the user needs are well written, as discussed in our previous learning objective. And then in the appendices, we have our traceability matrix. I’ll discuss that in a minute. Glossary, any other backup or background material for the previous sections or any other notes. Sometimes groups who develop ConOps, we’ll find that they keep kind of running notes in a version of their ConOps to maybe add in sections later or address issues, and this might be a good place to put it.
So how do we organize user needs? Well, first, I’d like to say that this is just an organization of the user needs, and we’re just using this for an example, but every agency will have probably an organization that best fits well with what they’re doing.
It’ll cover, you need to cover all the areas somewhere, but they don’t have to be by these names or in these bundles. So just to be clear, this is just one organization for user needs.
So, in this arrangement, the quality and construction needs might cover a broad range of things: the material, electronic mechanical quality requirements. Agencies may already have; you may already have a standing specification for such things. Housing needs: those could reflect conditions and constraints as we already established, with the width, some of the packaging requirements that we spoke about previously.
Communication needs, you know, what kinds of communications are coming in, what the cabinet may be required to do that goes into the application needs, you know, are you going to need more space than maybe in some cabinets because of your planning. So, the manner which you’re going to be using the cabinet can go, excuse me, any of these application needs.
Then we have maintenance needs, they may reflect on how the wiring is done, etc.
There’s a lot in there in the cap in the ATC 5301 standard but there may be special things that are reflected in that agency and you’ll want to put those there. Environmental testing needs. There’s some in the ATC cabinet but you may have special environmental testing needs for your agencies. A lot of the major cities have their own labs and things that they do there.
Warranty needs: this is where you may express needs that will be spelled out specifically later in the requirements specification, or I’m sorry, in your procurement specification, but you may put some high-level needs statements in here to add support to that. The procurement needs, its packaging, etc., that we’ve discussed a couple needs there, and then other needs: this is just some bucket to put things that we didn’t cover otherwise.
OK, we talked about traceability, and in our ConOps, we put this into one of the appendices. In this traceability, you can see here on the left, we have our user needs identified, and then in the next column, we have name of the user need, and then in the right column, we have the sources of that. So, section 7.1.1, modern ITS standards of specifications, well, we probably got that from our ITS strategic deployment plan that talks about how great our transportation system is going to be in five years or some plans go 20 and 50 years. So, the point here is, as you see that the sources there.
We have 7.2.1—existing foundations. We have an user need, so that was brought up by some of the stakeholders, let’s say, the guys that are in public works and maintenance people. Let’s jump down to 7.4.2 multiple applications. Well that came from our livable community plan. And it references the section in that plan, where it talks about, hey, we don’t want to have a lot of junk in the streets, so we want our cabinet systems, to cover more territory than just one intersection. So, you can see here that the needs, it’s really great to have the needs identified, but it’s also great to have the sources of those needs identified. This shows this accountability and a relationship of are planning to what we’re trying to propose here in this ConOps and then later, in our specification. Ok, now, let’s go into our activity.
Which of the following is a benefit of building a ConOps for an ATC cabinet?
Answer choices:
A - Are a provides justification for investment in ATC cabinets.
B - Only technical stakeholders are necessary to produce it.
C - Strategic or regional plants are unnecessary.
D - The organization of user needs is the same for all agencies.
Please make your selection.
OK, let’s look at our answers. If you said A, it provides justification for ATC cabinets, you were correct it, the ConOps is written from a user perspective. There’s traceability to existing plans, and user needs are formerly identified. That’s really a big deal about including those sources there in the traceability. You said B, you are incorrect. Said, the technical stakeholders are only technical stakeholders are necessary to produce ConOps, and that’s incorrect. User needs for the comments come from a broad base of technical and non-technical stakeholders at various levels. If you said, C, strategic or regional plans are unnecessary, that was incorrect. Existing plans become a source of user needs that justify the investment in ATC cabinets. And if you said, D, or organization and user needs is the same for all agencies, that was incorrect agency should have user needs organized in a manner that is most effective for their agency.
Well, you’ve done well. In this module, we explained the advantage of the transportation field Cabinet System based on the ATC 5301 standard. We describe the structure of the standard and we identified and wrote user needs for ATC cabinet systems and then we created a concept of operations for ATC cabinets.
In our next module, the second module on the subject, it’s entitled, it’s a module A322B: Understanding Requirements for Transportation Field Cabinets Systems, using ATC 5301 version 02. In this module will describe and go into more details about the assemblies and components and options for ATC cabinet.
So if you’re more of a, you want to look at the nuts and bolts of these things that will get down into more details there. It will demonstrate how to develop requirements for ATC cabinets based on the user needs we identified in this module and then that module will show how to create an agency ATC cabinet specification and how to verify that it is complete.
Thank you so much for participating in the PCB program or for taking this module, we ask that you please provide feedback on the link below to help us improve and or encourage us in any way, that we can improve all the training as well.
Thank you very much, this concludes our module.