Module 39 - A307a

A307a: Understanding User Needs for Advanced Transportation Controllers Based on ATC 5201 Standard v06

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, the director of the U.S. Department of Transportation’s Intelligent Transportation Systems Joint Program Office. Welcome to our ITS Standards Training program. We’re pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience without the need to travel. After you complete this training we hope you’ll tell your colleagues and customers about the latest ITS Standards and encourage them to take advantage of these training modules as well as archived webinars. ITS Standard training is one of the first offerings of our updated professional capacity training program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener. You can find information on additional modules and training programs on our website at ITS PCB Home. Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments and thank you, again, for participating and we hope you find this module helpful.

Narrator: Throughout the presentation this activity slide will appear indicating there is a multiple choice pop quiz following this slide. You will use your computer mouse to select your answer. There is only one correct answer. Selecting the submit button will record your answer and the clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice.

Today’s module is A307a Understanding User Needs for Advanced Transportation Controllers Based on ATC 5201 Standard Version 6. Your instructor is Ralph Boaz. He is a transportation engineering and marketing consultant. He was formerly vice president of Econolite Control Products and transportation section manager for Ball System Engineering. He has been a project manager and consultant at ATC and NTCIP standard programs. He’s president of Pillar Consulting Inc. in San Diego, California.

Ralph Boaz: Thank you for that introduction. It’s my pleasure to be your instructor today. As you can see, we are trying to address a broad audience. Hopefully, you’ll find something interesting in this module so that you can take it with you back to your agencies or organizations. These are some recommended prerequisites. I’d like to highlight A202 Identifying and Writing User Needs when ITS Standards Do Not Have SEP Content. We’ll be talking about user needs today. A couple of others, A207b and A208 which talk about the ATC 5201 Standard and the ATC 5401 Application Programming Interface Standard. These are essential to understanding this module. Here’s a graphic illustration of the curriculum path and you can look at that if you care to. And we’ll talk about the learning objectives for our module. We’re going to talk about the advantages of transportation controllers built based on ATC 5201 standard v.06. This is a review of the previous courses we just mentioned. We’ll describe a systems engineering based ATC specification development process. Now, for those of you that have taken some of the NTCIP modules, this won’t be new except in this case we’re talking about building an equipment specification. And for those of you that have done such things for your agencies this will be a new teaching, so to speak. Third, we’re going to talk about identifying and writing user needs for ATCs and then we’ll put those user needs into a concept of operations and learning objective four.

Identify the advantages of transportation controllers based on ATC 5201 standard version 6. We’ll discuss the purpose of the standard, we’ll identify key elements of the standard and the architecture of the device, and then we’ll describe how the standard works with other ITS standards.

Let’s talk about the purpose of the ATC 5201 standard. It provides a general purpose field computing platform for transportation applications. We want it to be open architecture, that means any manufacturer or software developer can build products conforming to the standards. We want it to be modular, that’s to reduce maintenance costs and increase its testability. And then we want it to be multitasking and multi-application. We want to be able to do many things at the same time and use for diverse application purposes. And that’s accomplished using the ATC application programming interface, which we mentioned previously.

Other things that we want involved in our standard here is we wanted to be able to define equipment that can grow with technology and so built into the standard, there is an evolution of technology built into the standard but staying within the same framework. And then we wanted to be able to upgrade legacy transportation field cabinet systems, so we don’t want users to have to replace their cabinet systems in the field but we want to provide contemporary performance and capabilities in those older cabinet architectures.

So traditionally, for the last 30 years or more, we’ve had traffic controllers that ran a single program at a time. So when you talked about the traffic controller you are automatically assuming a traffic signal application, or a ramp meter application, and in some instances a data collection device.

With an ATC it is capable of running multiple application programs simultaneously so we see this long list of applications and this is not even by no means restrictive, this is, I just wanted to list the diverse possibilities of using this equipment in the field. And the point is that when it’s running the API software, which we’re assuming for this presentation all of these different applications could be running simultaneously on the same unit. Let’s talk about some key elements of the architecture. It’s based on an engine board concept and that’s where all of the processing capabilities, memory, et cetera, are on a smaller board that can be built into various architectures. It has a computational capability that can grow with technology as there’s new developments, new engine boards, more powerful engine boards can be built and plugged right into the same controller architecture. It uses the Linux operating system, which is open source and is multi-process and multi-application and it’s well known throughout the computing industry. It has mechanical specifications but those are primarily for physical interfaces only. It’s not so prescriptive as to declare where each bolt, nut, or washer should go in the controller. The architecture it works with all of the major transportation field cabinet systems standards and specifications. Again, you can build a controller that will work in any of those types of cabinets. It provides for source code portability for application software. Now, there is some compiling and such that needs to be done to do that but it really facilitates the ability to move applications or to run the same applications on hardware built by different manufacturers. And then, again, we have multiple concurrent application programs running because of the API. Here’s a graphic illustration of the engine board. You see Ethernet ports. There’s two on the engine board. It ends up being four when you get to the actual external plugs on the controller. There’s a USB port. There’s a real time clock, memory, there’s the CPU and that CPU is running the Linux operating system and there’s multiple serial I/O ports for doing the various things you need to do in the cabinet. Here’s the illustration of using that same engine board on two different types of host modules, one would go here in this example, we’re showing one that would go into a 2070 controller and on the right we’re just showing an example of how a host module may be built for a NEMA controller. And, again, the same engine board can run in either host board.

ATC 5401 defines API software which allows concurrent application programs. So this software has a front panel management system. If you think of your PC and you have different windows running different programs you have Word and Excel, they’re running at the same time but when you want to interact with one you bring it up and we call this bringing the window into focus and you operate with that program. But the other programs such as your browser, as well, are all running simultaneously and it’s running in the background at that point. We want to be able to share the field input and outputs of the cabinets. For instance, we want detectors to be able to be shared across application programs so they can see what’s going on in the field and then we allow the allocation of load switches, which control the signal heads or other devices in the intersection and we allow those to be allocated to different application programs. So in this case, unlike with traditional architectures we can have multiple programs operating on the cabinet’s inputs and outputs.

The API also provides real time clock management. Traffic applications are all about time and so we want the applications to be able to set the clocks and manipulate the clock per their application. We also provide some utilities, there’s an ATC configuration window that’s much like your control panel on a PC and it allows you to do systems settings by default you’re able to set the system time to set up the Ethernet ports, select different services, and you can retrieve the Linux and API information. What’s really great about this it’s extensible so you can add other utilities. Let’s say vendors provide a Bluetooth application, or something like that, you can add that and it will show up in the configuration window much like other utilities on a PC which show up in the control panel.

Here’s just an example of the front panel manager window. This allows us to go to the various applications. You see a ramp meter program, a signal program, an emergency manager program, a data distribution program, a system checker program—these are all running simultaneously in this example and the signal program has a star indicating that that will be the program that appears when the controller is first powered up and that can all be set by the user. You can also get to the configuration window from here by hitting next you can get to this window from any application by hitting star star (**) escape, (Esc), so there’s more to this, but we won’t go into the details of that today, I just wanted to give you examples of ATC units that are currently being sold today and being deployed today. Of special note, is that each of these manufacture these are just a single example of the ATC units from each of these manufacturers, they will sell other units for the various cabinet systems that are out there.

So how does the ATC 5201 standard work with other ITS Standards? Well, it provides the capability to run multiple applications using the various NTCIP communications that are available. So you might have a signal program which you would use the ASC or ramp meter program that would use the RMS standards within NTCIP. And, again, the API gives us that capability. The standard provides the interfaces and computational power for advanced applications such as adaptive control and connected vehicle. It provides the internal cabinet interfaces for a Model 33x Cabinets, a TS1 and TS2 cabinets, and, as well as the ITS cabinets. So it plays within the major transportation cabinet architectures that are available today. And this is an important point. The last one here was that the ATC standard itself describes a more rigorous environmental testing requirement than the major TFCS standards. And why that’s important is if it did not do that when you were testing a cabinet for the other standards you may fail the ATC controller. So the ATC controller is made more rigorous so it’s sure to adhere to the other cabinet architecture standards.

Now, we’ll go through an illustration of what we just discussed. Here you see ATC units in different types of cabinets. We see it in a model 332 cabinet, an ATC unit, and here’s a different ATC unit in a NEMA TS2 cabinet, and we’ll see how these standards work together. So the standards and specifications that we’ve previously shown are defined outside of this course and outside of these standards, but we’ll show how this ATC 5201 standard works with this is because these controllers can be built using this engine board concept. And then because of the engine board running API software, which is defined by ATC 5401, we now have all of those capabilities that the ATC software, API software provides. And then we can have application programs that are running simultaneously for different purposes. Here we show a single control app, a ramp metering application, a field master application, and we also have a connected vehicle single phase and timing message service that is sending infrastructure information to the vehicles on the road. Now, what’s a really neat feature here is that not only can these all run on a single cabinet architecture but simply recompiling these programs from their vendors these same applications could be run on a totally different cabinet architecture built by some other vendor.

Now, we have an activity for you—put on your thinking caps. Which of the following features of ATC units allows them to run on concurrent application programs. Is it a) has a computational capability that can grow with technology, b) works with all major transportation field cabinet systems, c) works with NTCIP standards, d) runs API software? Please make your selection.

Our question was, which of the following features of ATC units allows them to run concurrent application programs? If you said d) it runs the API software, you are correct, and that software is defined by ATC 5401. And it runs on ATC units and allows them to share the resources, the controller and the cabinet system. If you said a) has computational capability that can grow with technology, you are incorrect. Although, that’s a really important feature of the ATC units and that mitigates obsolescence it gives power to do more advanced features in the future, but, again, the capability of sharing all of the resources of the cabinet come from the API. It works with all major transportation field cabinet systems and yes it is true that it does that but that feature allows the ATC units processing power, contemporary processing power, and capabilities to be used in older cabinet systems. And if you answered NTCIP standards that was incorrect for this quiz. The ATC units provide computing resources for NTCIP communications but the applications determine their use.

Okay, so if we summarize our learning objective that we just covered, identifying the advantages of transportation controllers based on ATC 5201, we discussed the purposes of the standard, we identified key elements of the standard, and we described how ATC 5201 works with other ITS standards. While we were doing this course previously some questions came in I wanted to address one of them at this point. Someone asked what is the status of the standards? ATC 5201’s standard version 6 is to be published by the fourth quarter of 2015. ATC 5401 standard on the API version 2 has been out for a number of years and we’re currently building a reference implementation that’s going to be available by the end of 2015. And this reference implementation can be used by the manufacturers and software vendors to build their programs so that we have the best chance of portability and compatibility and interchangeability of those application programs.

Let’s move on to learning objective 2. Here we’ll describe a systems engineering based ATC specification development process. We’ll talk about traditional approaches that are used in developing transportation controller specifications. We’ll talk about the systems engineering approach to doing a specification. We’ll talk about the benefits of this development process and then also the challenges of a good ATC specification. So this will be review for some but we’re going to put in some interesting points that you may want to consider even if you’re somewhat familiar with this concept. Now, this presentation presents a systems engineering approach. Agencies who are able to procure units in a more traditional manner without the justifications and support consensus of a concept of operations, which we’re going to go into in this module, they may choose not to go through it. Agencies who intend to proceed without doing this step, however, are cautioned to consider the rationale justifications that doing this kind ConOps provides. So that’s just a little bit of a warning and encouragement to give this a try.

When we’re talking about traditional approaches to developing a transportation controller spec it’s usually not based on formalized user needs and requirements. Often it’s something that’s copied and pasted from previous years of specification and so they may go back, they may be quite out of date, they may also just be what the traffic ops people thought were important—what was important in a point in time. Remember that we have a much broader base of stakeholders and they have different needs, and the problem with doing that approach is that you’re not getting their needs built into this unit that’s going to be a general purpose machine out on the field. One of the big things about this is funding. Sometimes policymakers and senior managers just assume that the traffic controller is a relatively simple device and the real thinking is done at a higher level. And now we see with the ATC the solutions can be pushed right down to the field in many instances. So the problem here is that traditional thinking then they don’t see this potential solution offered by the ATCs. And then in traditional approaches the hardware and application procurement are combined for a single purpose as we discuss previously, it might be a signal control, ramp metering, or data collection application.

So our systems engineering approach will develop a concept of operations with user needs, will develop the requirements based on user needs, and then we’ll show the traceability of user needs in an ATC specification. Now, we’ll go into further detail about that in A307b. Here’s a graphic illustration of this kind of portion of the systems engineering process. We have user needs development and that’s kind of an iterative thing in itself. And then we improve on those user needs as we go into the requirements development and then, again, as we go into the design we’ll also discover other requirements and this is kind of the the iterative within the process as we go to the next process approach that system engineering provides. I want to read this definition for systems engineering: “an interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balance solution that satisfies customer expectations and meets public acceptability.” Our stakeholders for ATC deployments are going to be broader. It’s no longer just the traffic operations people and so the stakeholders that we need to satisfy, or the customers we need to satisfy, are much broader and it even gets to the point where we have public acceptability and we have to remember that the public is aware what is technologically possible and we need to be able to show that we are keeping their safety and mobility in mind.

Now we’ll modify that general approach we saw in the previous slide to our specification development. So we have our user needs process and our requirements process, but we’ll see during user needs that we have inputs from previous strategic or regional plans and we could take a look at those to discover what user needs we’ll be having in the future. And this is really important because our managers and planners that create strategic plans and regional plans, they will have really set a direction. There’s usually a disconnect on how that direction is going to actually get implemented. And so this is an opportunity for us to show how the ATC can help fulfill those plans. So as we develop the user needs, we record those into—I’m sorry—as we identify the user needs we record those in a concept of operations. Then as we develop requirements we record those that we can put into the agency specification. And then what we show is we show this traceability between the user needs and the requirements that are shown in the agency specification.

We’re recommending in this class that you might want to keep the concept of operations separate from the agency specification but that’s really up to the user’s discretion.

There’s different relationships of user needs and requirements. Sometimes you’ll have a single user need going to a single requirement. Other times you’ll have a single user need that is fulfilled by multiple requirements. And sometimes multiple user needs may be fulfilled by a single requirement.

Some of the benefits of taking this approach is that user needs are identified by a broad base of stakeholders, existing strategic or regional plans already approved by policymakers are part of the user needs development, and it provides justification for the investment in ATC units that nontechnical people can understand. Again, it shows accountability to the public.

Challenges in preparing such a specification is that we have internal resistance to change. We have maybe the fear factor or the learning curve to overcome for ourselves but we’ll also have that within our own immediate organization, or department, or workgroup. And then we’ll have resistance to change from those outside your immediate sphere of influence, those in groups either parallel to you or above you. We’ll have procurement schedules that were built on a traditional approach that may not allow the time and effort to go into doing this more rigorous process. It’s sometimes hard to identify and get stakeholders together. Just because somebody is in a particular department doesn’t necessarily make them a good participant for your workgroup. You want to identify the best contributors you can. And then just as you add more people, getting everybody together is difficult. And then once you get the stakeholders together they tend to describe their user needs in very specific ways, for instance, traffic ops people may say I really need this type of flasher in my cabinet. That’s an exaggeration but that actually happens. They don’t understand that these user needs are bigger and broader and those get down to design issues. And then just as we develop our procurement specs many of the people in our agencies just are unfamiliar with the systems engineering processes, so we need to get training and education to the different parts of our organization, all of the people that are involved.

So now we have another activity. Which of the following is not a good source for discovering user needs? Is it a) regional plans, b) integration and testing, c) stakeholders, or d) strategic plans? Please make your selection. Let’s discuss our answers. Which of the following is not a good source for discovering user needs? If you said integration testing, you are correct. It’s not a good practice to depend on integration testing to discover user needs. That is way down the development process. If you discover some user need when you’re actually integrating equipment then you probably need to defer that user need or you may have to re-scope your project. Often, however, any user needs that are discovered at that point are probably implicitly covered by what you have already. If you said regional plans this is incorrect. Regional plans provide insight to the future and they’re a good source for discovering user needs. Of course, the stakeholders these are the most important people contributing to your user need development and so of course we need them. And just like the regional plans, the strategic plans provide insight to the future and are good source for discovering user needs.

Summarizing our learning objective, describe a systems engineering based ATC specification development process. We discussed traditional approaches to developing a controller procurement spec. We discussed the systems engineering approach to developing an ATC procurement specification. We talked about the benefits of the specification development process. And we talked about the challenges to preparing a good ATC spec.

A question that we had come in previously, when talking about the challenges in an agency, how do you overcome them? I think one of the big things is awareness. You all who are taking this module need to talk about what you’re learning, tell your colleagues, your staff, your superiors, it’s fantastic for you to be the person who delivers the latest practices that are going on in the industry. The second opportunity is just training. Have people take these modules, take the PCB module program. Or, what’s really valuable is to bring in a consultant and have them teach a class for your agency. Other departments also, you need to keep this in mind, other departments outside of your immediate group may help pay for the infrastructure that you want. We are using in Southern California here, in Orange County, we’re bringing in representatives from the fire department, from the police, from emergency management. Others that could be brought in, for instance, from homeland security. But those other public sector departments have funds which may help in building your transportation infrastructure.

So we reviewed the advantages of ATCs and we discussed the systems engineering specification process. Now, we’re going to talk about learning objective 3, which is to identify and write user needs for ATCs. We’ll discuss the sources of needs. We’ll discuss the characteristics of well written user needs and we’ll show you that user needs are a process of discovery.

We mentioned that stakeholders were the most essential source for getting our user needs, and, again, that’s a broad base of stakeholders. We have derived user needs that we can glean from the strategic and regional plans and then maybe existing or planned operational applications, so there may be things that are already in the works and we can add those to our list of user needs. When we get our stakeholders together we’ll find out things that are really architectural constraints and those could be the fact that you have existing field cabinet systems so those become a constraint on the ATC equipment. The constraints are similar to needs but they’re not subject to the prioritization in deferring, as I had mentioned previously that sometimes user needs are deferred, that architectural strength for a procurement would not be something you could defer. And then another good kind of constraint that you’ll find is what kind of communications are existing or planned. And then we can also derive user needs from the ATC 5201 standard, actually 5401 as well, and these user needs can be used in your specification called out specifically.

So instead of physical system if we talked about this being the ATC unit we’re used to the operational people, types, having control over that and developing the specs for that but that can be a narrow view. They certainly are critical and probably have the most experience but now we see with others involved including other stakeholders such as first responders and emergency management, et cetera, that the containing system may be, actually be, overlapping. And so we have other stakeholders than we would traditionally consider and you can even find stakeholders and champions going out to the wider environment and I think it’s a great thing to get a champion at numerous levels within your organization.

Characteristics of well written user needs, they are uniquely identifiable—they are a major desired capability. We capture the rationale why this is being included. And we don’t want to limit the possible solutions. So we want this user need to be expressed in a way that’s solution free.

Let’s look at an example. This user need is 7.8.2.1 traffic signal control. The user needs to safely control the flow of traffic through the city’s signalized intersections. There are over 100 signalized intersections within the city limits. The city uses pre times, semi-actuated, and fully actuated modes of traffic signal operation. Traffic signals may be operated as a standalone intersection or in coordination with other intersections. First of all, is it uniquely identifiable? Well, yes, we have 7.8.2.1 traffic signal control. We’ll have no other user needs that will have that numbering or title. Is it a major desired capability? Yes, this is pretty major. We want to safely control the flow of traffic through the city’s signalized intersections. Now, I have adopted in this module a structure to the user needs where I put the rationale in italics just to make it easier to identify. So does it capture the rationale? Yes, it provides the background information that the stakeholders developed to support this major desired capability. Now, do we tell them exactly how to do that? Do we tell them which brand of control or which style of controller? No, at this point we’re not trying to give the solution, so yes it is solution free.

Let’s take a look at another example. Here we have one that’s 7.3.5 keypads. The user needs the controller to have keypads as described in section 9.4.2 of the Caltrans TEES 2009. TEEs is the specification that’s used by the state of California. The city has no maintenance issues with these types of keypads on their existing controllers. The keypads work well with the city’s existing signal control software. Now, let’s first of all look at this. Is it uniquely identifiable? Yes. We have 7.3.5 keypads. Now, is it a major desired capability? No, it’s probably not, and the way it’s stated, it is effectively a design level kind of statement versus a user need. The major desired capability in this area would probably refer to the ability to use a field application program, something along those lines. So as stated it’s not a major desired capability. Does it capture rationale? Not really. Well, first of all, this rationale is all about this keypad and it seems to be more centered around supporting their current product and application software. If their issue is reliability then they could invent or they could identify a user need that addresses reliability, in general, versus something addressing just the keypad. And is it solution free? No, it’s not. It specifically tells the reader that they want to use a particular keypad on the controller device.

You will remember this that user needs are a process of discovery. All inquiry circles have periods of action and reflection—action to move forward and reflection to consider whether the work is complete and going in the right direction or whether redirection should be considered. We discover the user needs in working with our stakeholders and then we document what we discover and then we validate that the user needs can exist with the other user needs we’ve already identified. And we also check to see if the user needs are well written.

Now, we’ll go through a case study that kind of demonstrates that. This section uses examples from the Orange County Intelligent Transportation Systems Strategic Deployment Plan, update 2013. This SDP was developed by the Orange County Transportation Authority and Metropolitan Planning Organization for Orange County California. The SDP uses ITS strategies to provide a context for the agencies and the private sector who are deploying technology today and for the following ten years. Strategies are organized as follows. They have traffic management and multimodal. It goes by MM. Traffic management, TM. Incident management and emergency response, IM. Traveler information, TI. Performance monitoring, PM. Communications and connectivity CC. Safety, SF. And institutional strategies are IN. This is just the nomenclature they used in identifying these different strategies. Others may have different approaches to doing that but we’re going to use this in our user needs development. So we have a couple of strategies here from the SDP. We have one MM2 bus rapid transit. It says roll out BRT service in a two-step implementation process. Technology applications can include TSP, real time bus arrival information, automated fare collection. So in all of these different strategic plans, they may have different ways of saying things, expressing things, and what we want to do is by taking these plans we want to look at them and see what we can draw from them. Here we have a second one here MM5 that says support for pedestrian and bicycle travel and it’s local deployments of pedestrian and bicycle safety, bike sharing, and information technologies. So what can we maybe draw on for user needs for our system—for our ATC? Well, here’s one that I came up with, 7.8.3.3 increased public use of transit buses. The city needs transportation controllers that can be used to help increase ridership of transit buses. The city needs to improve customer service and ridership experience through the use of field applications it may include TSP, real time bus arrival information, and automated fare collection and others. In that example, I did not put all of the rationale in italics there. The next one, 7.8.6.1 we talk about nonvehicle modes of transportation. We have the city needs, transportation controllers that provide for pedestrian and bicycle application. This is to reduce vehicle congestion, improved safety, and promote non-motorized travel. So there is a couple of user needs we developed from the strategic plan that was written long before we went into this ATC development process. Here’s a couple of others from the SDP. CC1 is countywide communications master plan. The city wants to have a physical and logical connectivity to support multimodal and multi-agency operations and data sharing needs. I have another one that’s CC3 provide a connected vehicle’s platform and that is to allow for the future possibility of connected vehicles in order to capitalize on the robust local environment and further enhance the existing infrastructure or foundation. So let’s draw out a couple of user needs from that. So we have one called multi-network ready. We see the city needs transportation controllers equipped with communications capabilities to accommodate connectivity with multiple systems and communication networks and then we have our rationale. The city has legacy center-to-field communications. We talk about the majority of the arterials that are supported by Ethernet communications and it’s expected that some applications will share a physical network while others will require separate networks. So there’s a background information there from our—that our stakeholders develop by reviewing the SDP. Here we have another one. This one is on connected vehicle communications. The city needs transportation controllers that have the processing power to perform connected vehicle-to-infrastructure communications. The connected vehicle application has the potential for a major advancement in integrated traveler information safety transportation management and eco driving. So there’s our rationale for the connected vehicles. And our stakeholders recognize that not only did we need possibly multiple communications and multimodal type of applications, we also needed the power within our controller to perform such tasks.

Now, we discussed that the ATC could be used to upgrade your existing infrastructure. Well, this is an example architectural constraint. And, again, this is an architectural constraint or constraints, in general, are those things that aren’t subject to deferment or renegotiating, maybe as a way to say it as we go down through the systems engineering process. So here’s our architectural constraint 6.5.1 traditional transportation field cabinet systems. The city needs transportation controllers equipped for existing transportation field cabinet systems. The city has 70 percent of its TFCSs that are NEMA TS2 and 30 percent of its TFCSs that are NEMA TS2 type 2. The transportation controller should be suitable for these cabinet systems. So clearly our stakeholders don’t want to go out and change the cabinet systems they have out in the field—that’s very costly—so this becomes an architectural constraint for our ATC specification.

Now, we could derive user needs from ATC 5201. And we need to remember that ATC 5201 version 6 did not go through a formal system engineering process. It does contain a section called representative usage where user needs are expressed as features. Features are organized into three major categories, managing and configuring applications, managing external devices, and facilitating the ease of maintenance and future hardware and software updates. I won’t go down through all of the sub-features for these but you can read those. This is for managing and configuring applications. Here’s some more that have to do with that major feature.

Now, we’ll look at managing external devices. There are a couple of sub features listed in the standard for that. And we have facilitate ease of maintenance and future hardware software updates. And we have some sub-features and you can read those in the standard itself.

Now, let’s talk about converting some of these features into user needs that we’ll include in our concept of operations. So we had the feature install update application software quickly and efficiently, that was 2.3.1.1 from the standard. This feature allows a local operator or a remote computer to install or update the application software resident on the ATC. That’s pretty important. So we developed this user need. The user needs to be able to install or update the application software resident on the controller unit. Our rationale is users may not use the application program from the original manufacturer. All application programs need maintenance over time. Depending on the user’s organization application updates may be performed directly on the controller unit, from a computer connection or remotely through a network. So we take that and let’s dissect it. Was it uniquely identifiable? Yes. Is it a major desired capability? Yes. We really need this in our city and does it capture the rationale? Yes, we capture that rationale? And does it say how we’re going to do it? No, it doesn’t, so it’s solution free. It is stating a need, it’s solution free.

Here’s another one, the feature is maintain update controller hardware. This feature addresses the need for controller unit hardware to be maintained and updated as technology changes and additional functional performance capabilities are needed. So we turn that into a user need and we said the user needs are a controller unit to be upgradeable. Controller units are commonly in the field for seven years or more. This leads to obsolescence. The user needs to be able to upgrade the controller unit as technology changes and additional functional performance capabilities are needed. So if we dissect that—let’s make sure it’s well written. Is it uniquely identifiable? Yes. Is it a major desired capability? Yes. Does it capture the rationale? Yes it does. And is it solution free. Yes, it is. We don’t say how that’s going to be done here. We just say that this is a need for our agency.

We have another activity for you. Which of the following is not a source of user needs for the specification development process? Is it a) a brand of control or equipment currently used by the agency, b) existing type of transportation field cabinet systems, c) existing strategic or regional plans, d) stakeholders. Please make your selection.

Let’s go over the answers, which of the following is not a source of user needs for the specification development process? If you said a, you were correct. The fact that an agency is using a particular brand of equipment should not become a user need. We want the software applications written for ATCs to be portable across vendors. If you said existing or plan types of TSCSs that was incorrect because this is an important constraint—type of need for the controller equipment. If you said existing strategic regional plans, we discussed quite a bit that these higher level documents help provide the vision for the agency and our sourced from which user needs can be derived. And, of course, we talked about the stakeholders as being the primary or essential source of user needs for our equipment.

Now, we had a question come previously and I’ll repeat that here. It says how many user needs should I have? Well, that’s a very good question. You could have about ten or so basic features from the ATC 5201 and 5401 standards. You’ll have the user needs that go to the benefits of the ATC architecture. You may have user needs that come from the stakeholders and from strategic and regional plans. Often these plans will help you identify applications that will be running on your controllers. And it’s not so much the details of those applications that are important at this point, but it’s important to see that you will have multiple applications running on your controller. Now, if your spec is going to include application software in it then you may want to expand on those as well in your ConOps. That’s just a little side note for you. And something to remember here is that your document, your ConOps here is not just for the team preparing it. This is making the case for others that may be outside of your organization or your superiors that may influence what kind of equipment you will get. So in summary, probably the answer to the question is, I’d say somewhere between 15 and 30 user needs may come out of this process. Five is definitely too little and 100 is definitely too much, so I would guess at this point that about 15 to 30 user needs should be in the ballpark.

Now, that we have developed our user needs let’s discuss the ConOps for our ATC deployment. So we’re here at learning objective 3—I’m sorry—this is a summary slide that we talked about the sources of ATCs, we talked about the characteristics of well written user needs, and the user needs as a process of discovery.

Learning objective 4 is developing a concept of operations. We’ll discuss the structure of the ConOps, organizing user needs, and traceability of user needs to sources. Here’s a structure of the ConOps. This particular example comes from the FHWA System Engineering Guidebook version three. It’s slightly modified for our purposes. And I just thought that this particular outline served us well when we were doing equipment specifications. Now, keep in mind that this is not a ConOps in the traditional sense. The ATC unit is in a system until an application is put on. So since ATC is a general purpose device it may host multiple programs that are part of many systems simultaneously. And as I said on the previous slide, it should be noted that some agencies will purchase control units as part of some sort of central system deployment. In that case the user needs developed for the controller would be included with the user needs of the field application for the central system.

In this ConOps outline we didn’t include operational scenarios because, again, that has to do with the applications that are running.

So the content of the ConOps, first we have the purpose of the document and that’s just a brief statement, one to two paragraphs. I’ll highlight the expected operations of the system. We want this to be an instrument for the stakeholder discussion and consensus, and we want to describe the contents and intention and the audience and these last couple of bullets could be in one paragraph.

The next section was scope of the project. Again, this only needs to be a couple of paragraphs, discuss the overview of the system, in this case, the controller equipment to be procured. And then list out the departments that are involved and other agencies that are involved directly or indirectly.

Next section was reference documents, the list of supporting documentation used in our ConOps and later to be used in our specification. And those that are useful for understanding the operation of the system and then any operational documents, strategic plans, or other kinds of documents that drive the goal of the procurement.

The background, this could be also another two paragraphs, a brief description of the current equipment, how it’s used, and its drawbacks, what’s causing you to go on to an ATC type of equipment. And then the reasons for the proposed procurement and your general approach to improvements. Then you’ll have your concept for the proposed procurement and you’ll just discuss alternative concepts and why they’re not optimal. We’ll have your high level description of an ATC and you can go back to learning objective 1 and steal items from there. And then lay out your justification for the approach.

Then we’ll have the user oriented operational description. This section focuses on the goals and objectives. It describes the strategies, tactics, policies, and constraints so your constraints that you have on your project would go into this section. Describes the stakeholders and what they want to do. And the personnel and your capabilities and organizational structures, et cetera.

Next section will be user needs, that’s where you have the vision and goals and objectives and the personnel to drive the requirements for the system. Your user needs will be listed in this section. They’ll be well written as described in our previous learning objective. And it’s recommended that the user needs are organized in a fashion similar to that of the requirements in the specification. Now, that’s important because it will help with the understanding that your user needs are arranged similarly to those requirements that you’re going to have in your final spec. So make an effort to think about that.

We’ll have appendices. You’ll have a traceability matrix there, a glossary, any other background or backup material or references to that, and any notes. That kind of goes to the concept of a live document where you might want to carry notes or changes, possible changes or expansion of ideas in notes before you actually go through a formal update of the ConOps.

So here’s our organization of user needs and this will correspond in the next course to kind of the organization of our requirements that we’ll talk about in A307b. Again, this is just one way of organizing user needs. There’s multiple ways to do it and we just chose this for this module. So we have quality construction, the TSCS user needs, user interface needs—like how big is the display or is it a color, et cetera—some user needs maybe, we’re trying not to get too specific here. Actually, those may be not the best example but you get the idea that we’re putting the user needs we discussed previously in the module into these sections.

Now, what we want to do is, we want to show the traceability of the user needs to their sources. Now, why is this important? Well, this is important because when we complete our ConOps and we have these user needs and then we go on to create our specification, somebody might say “why are we including this?” Well, this helps us understand why we’re doing that. We’ll track the user needs. If we come back to our ConOps here, we can take these sources and say hey this is where it came from. In the case of the SDP, the strategic deployment plan, we can say hey, our bosses said that they wanted to have this to support transit bus applications or our bosses said that we’re going to have this communications infrastructure deployed, different things like that. So here’s a table that shows the user needs mapped to the sources. On the left, we have the user need ID. We have the name of the user need and the sources. And so in this case, the first one, maintain and update controller hardware, the source of that user need came from the ATC 5201 standard section 4. Traffic signal control came from the stakeholders. And then we had these other applications such as transit buses and nonvehicle modes of transportation, those came from our strategic deployment plan.

Here’s our last quiz. Which of the following is a true statement? A) there’s only one way to organize user needs in a ConOps, b) a ConOps for an ATC is written from a vendor’s point of view, c) consider your specification when organizing your user needs, or d) a ConOps is just busy work. Please make your selection. Let’s review the answers. The question was, which of the following is a true statement? If you said, consider your specification when organizing your user needs that was correct. By doing that it will help in understanding the user needs and requirements and doing the traceability so this is a great practice to do. Otherwise, it can be quite—it can be a little process to try and track down how these are arranged or what they might apply to. But the traceability does work even in that kind of situation. If you said a) there’s only one way to organize user needs, no, that’s incorrect. There’s different methods that we can use. This is just the method we used in this module. B) ConOps is written from a vendor’s point of view. No, the ConOps is written from the users’ point of view or your stakeholders’ point of view. D) a ConOps is just buys work, that’s incorrect. A ConOps focuses the users and the stakeholders to think of what they need and express it in terms they understand.

Summarizing learning objective 4. We discussed the structure of the ConOps. We discussed organizing user needs, the organization of the user needs, and we discussed traceability of user needs to sources. We had a question that came up at the end of this section. This person said, “I’ve never done a ConOps for an equipment specification. It seems like a lot of work.” And yes, you do need to give more time to doing this because not only is it probably a step you didn’t do but it involves multiple people. And, of course, that takes more effort to do that and gain consensus. You don’t just sit down and do what you did before because we’re trying to show the justification for getting these advanced transportation controllers. And it’s also that we’re trying to gain confidence and understanding throughout our organization by going through this process of what we can do with this new technology.

So, what we have learned today—thank you all for continuing here—we have the ATC 5201 Standard Version 6 and ATC 5401 application programming interface. We saw how they work together so that ATC units can run multiple application programs simultaneously. Secondly, we saw that a systems engineering specification development process provides traceability from user needs in a ConOps to requirements in the agency specification, and we’ll discuss that more in A307b. Third, we showed that well written user needs are uniquely identifiable, a major desired capability that it captures the rationale and is solution free. Finally, we showed that the sources of user needs and the ConOps can demonstrate the connection of user needs to the agency’s regional and strategic plans.

Here are the resources that we used for this module. There are others that will be in the student supplement. You can take a look at those. And our next module will have the module A307b Understanding Requirements for Advanced Transportation Controllers Based on ATC 5201 Version 6 and the concepts taught in the module will be describing a systems engineering process based on the ATC specification development process. This will be a review of what we did today. Then we’ll write requirements for ATCs based on the user needs. We’ll describe a specification based on the ATC 5201 standard and then we’ll talk about verifying the procurement specification.

Questions? I will go through one more question. We’ve hit questions along the way. When should I start a process such as this? I assume this means the development process? Well, the ATC Standard Version 6 is available by the end of 2015. The reference implementation software will also be available by the end of 2015 and as we discuss this can be more of an involved process for getting to where we want to be. And so there’s no time like the present. You can start your organizing. Some agencies are doing this already because they have procurements coming and so this is a really good time to start this process. The other point is in 2015, the USDOT’s asking new deployments of transportation controllers be connected vehicle ready. What that means is that they’re going to need to have at least a couple of Ethernet connections and the processing power to do the connected vehicle messaging. So especially when so many users need to be aware of this. So let’s get started with that. Thank you so much for your participation in this program and for taking this module. This concludes our training on module A307a.

#### End of A307a_Understanding User Needs for Advanced Transportation Controllers Based on ATC 5201 Standard Version 6####