Module 44 - A307b

A307b: Understanding Requirements 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'm 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 standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program, we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener. You can find information on additional modules and training programs on our website at www.its.dot.gov/pcb.

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.

This module is A307b, Understanding Requirements for Advanced Transportation Controllers Based on ATC-5201 Standard, Version 6. Your instructor, Ralph Boaz, has been a project manager and consultant to the ATC and the NTCIP Standards Program. He is a member of numerous ATC and NTCIP Standards working groups. He is a chairman of the Transportation Sensor Systems Working Group for NTCIP, and in 2002 he founded Pillar Consulting, Inc., where he assists companies and agencies in ITS planning, implementation, deployment, testing, and training.

Ralph Boaz: As you can see, we have numerous roles of people who take this course. Depending on your background, you may find different parts of the presentation more applicable to you. It is our hope that there is something here for everyone who is taking the course.

We have recommended prerequisites. I'd just like to highlight A103 and A203. These courses go into writing requirements and would be helpful as a review before you take this course. We also have A207a and b and A208 and, of course, A307a, as prerequisites, and this course really ties all those courses together to be able to present a method of creating an ATC specification. This is a graphical version of what we just discussed. We are going to have four learning objectives in this course. We have— describe a systems engineering-based ATC specification development process. We have writing requirements for ATCs based on user needs. Third, we'll describe a specification based on the ATC 5201 Standard, and then our fourth learning objective will show you how to verify your ATC procurement spec.

Learning objective 1, describing the systems engineering-based ATC specification development process. This is a review of what we had in A307a, and we'll try to move through this quickly. We'll talk about traditional approaches to developing controllers' procurement specs. We'll talk about the systems engineering approach. We'll talk about the benefits of using this specification development process and the challenges to preparing a good ATC spec.

Traditional approaches to developing controller specifications—historically we've not based our specifications on formalized user needs and requirements. Often the agencies use an existing specification they've either used before or found someplace else, copy it, and distribute that. And there is no connection to other stakeholders who might have user needs that apply to the transportation controller. And that may have been okay in the past, when the controller was only doing the—just traffic control, but the ATCs, as you know, are meant to be a general purpose field-computing platform so there's lots of other potential stakeholders. When we're going out to get such equipment, we can find that there's funding problems because policymakers and managers don't see the relationship between their strategic and regional plans, and the potential solutions offered by Advanced Transportation Controllers. In the past, hardware and application procurements were combined for a single purpose. You bought a traffic controller that was running a signal control program or a traffic controller running a ramp metering program, et cetera. So those were the traditional issues that you deal with.

Now, in the systems engineering approach, we develop a concept of operations with user needs, continuing user needs. We develop requirements based on those user needs, and then we capture those requirements and show traceability to user needs in an ATC specification. So this is simple in concept, harder in practice, but better in the long run. If you see in this graphic here, we've illustrated that left part of the system engineering lifecycle. There are three of those steps here. When you've categorized them as processes—we're displaying these as processes—we have user needs development going on and that leads into requirements development, and sometimes there is iteration between those, and then requirements development leading into design development, and you have this iteration within that. And I really like this definition from IEEE systems engineering, "an interdisciplinary collaborate approach to drive, evolve, and verify a lifecycle-balanced system solution that satisfies customer expectations and meets public acceptability." The public in general is getting much more aware of the technology that should be available to ITS. Also, as we expand our user needs, it's going to require more visibility into the process, and more accountability, and again, we want to be able to make sure we're taking advantage of the equipment and systems we have.

Looking at the specification development process, we've removed the design stage in developing a spec at the bottom right, and replaced that with agency specification. So, if we start from the top now, we have strategic regional plans where those maybe have been long established, and have been saluted by various people, even possibly politicians have talked about all the great things they're going to do—but they don't. There's always been this disconnect between that and what you're actually getting done in your systems and field devices. And so, what we do is we use those plans as part of our user needs development, and again, involving the broad-based stakeholders that might have interest here. And in developing those user needs, we capture them in a Concept of Operations, which you can see here at the bottom of the page. As we then continue in our process, we develop requirements, and again, that's an iterative thing leading back into maybe finding some new user needs and develop your further requirements, and then we capture those requirements in agency specifications.

Now here's the thing that's really, I think, important to think about is that we really encourage this traceability all the way back from the strategic or regional plans, through the Concept of Operations, and to the agency specifications, so that interested parties can understand, "Hey, we did not just invent this thing down here because we liked it. We specified it because it was part of our original plans that we set out for prior."

There are various relationships of the user needs and requirements. We have a need to, a requirement, a one to one. We have a one to many user need to requirements. We can also have user needs satisfied by a single requirement. The benefits of the system engineering specification process is that user needs are identified by a broad base of stakeholders. Existing strategic and regional plans already approved are covered by the user needs. We provide justification for investment in ATC units that nontechnical people can understand. And again, it shows accountability to the public. In short, the agencies are zeroing in on what they need and providing the framework to get what they want.

Challenges to preparing a good spec? Well you have this internal resistance to change, right? People would like to do what they've always been doing, and that can be especially the case when you're dealing with technicians who have had a lot of training on the existing equipment and things like that. But then you can have external resistance to change, and that may be in how the agency's processes run, or how they've allocated time for different steps in that process. For instance, it may have procurement schedules that don't allow for the time and effort to do this rigorous process that we're talking about here. It's also difficult to identify and get stakeholders together. You want to find champions at various levels or all the levels that you get participating, but identify who that is and getting them to clear their schedules to participate can be difficult. We can have the stakeholders, especially those that are close to the equipment, they tend to describe their user needs as design requirements. They really call them user needs, but they're actually design requirements, like we have to use a special connector here. We have to use—you know, things they've fought for in the past and want to make sure that they're still in there. Sometimes we get too specific.

And then that often is the case that people procuring the equipment are unfamiliar with this SE process and that's the purpose of these courses, to help us understand what you're getting when you do this.

And we're going to have an activity. An agency specification comes out of what part of the systems engineering specification development process? Is it a) concept of operations, b) requirements development, c) strategic plan, or d) user needs development? Please make your selection.

Okay, let's review our answers. The question was, "An agency specification comes out of what part of the systems engineering specification development process?" If you answered b) requirements development, you're correct. The requirements are stated in the agency spec, remember that it comes out of the bottom of that requirements phase. If you said a) concept of operation, that was incorrect. The concept of operations is a result of or the placeholder for the user needs development. If you said, "strategic plan," that's incorrect. The strategic plan may be an input to the user needs development process, but that's done much earlier in the agency's plan. And if you said, "user needs development," this is incorrect, a lot like a) user needs are stated in the concept-of-operations.

So summarizing what we just learned, we described an SE-based ATC spec development process. We discussed the traditional approaches. We discussed the systems engineering approach to develop a spec. We talked about the benefits of the spec development process, and we talked about the challenges to preparing a good ATC spec. We had a question come in that I'll read to you here. Generally speaking—I'm sorry, this isn't a question, this is just a point, is that generally speaking, when we go through the remainder of this presentation, user needs will be starting with the number seven, and that corresponds with the section we discussed in our ConOps in the previous module. And in our specification, the requirements will be numbered starting with a five, because that's the section they would show up in our proposed outline.

Okay, let's go on to learning objective 2. Here we'll discuss writing requirements for ATCs based on user needs, talk about the structure and characteristics of well-formed requirements, writing requirements for ATCs based on the user needs and resolving conflicting requirements. We want to define a well-formed requirement has different parts—actor, action, target, constraint, and localization. The actor, that identifies who or what does the action. The action is what's going to happen. The target is what receives the action, and constraint identifies how to measure success or failure, and localization identifies the circumstances under which the requirement applies. It is important to note that localization and constraint portions are important but not all requirements will have both. In my practice, we find constraints occurring a lot more frequently than the localization parts of it.

So here we have an example of a well-formed requirement, and we're going to step through that now. So, we have the requirement is called Color Graphics Display, so it says the transportation controller shall provide a liquid crystal display that is capable of color graphics. So we have the actor is the transportation controller. Our action is shall provide. And the target is a liquid crystal display, and our constraint is that it is capable of color graphics. Now there's more to writing well-formed requirements. We also want to have characteristics of these requirements. And before I move on to that, I just want to reiterate here that if a requirement can't be stated in this kind of simple format, you probably need to use multiple requirements.

Okay, now the characteristics of well-formed requirements. They need to be necessary. They must be useful and traceable to user needs—concise. We suggest using the "shall" statements as we just discussed in well-formed requirements. Attainable, it needs to be realistic. It can't be something very abstract. Stand-alone—we don't want the requirement spread in multiple places. We want it stated completely in one place. It needs to be consistent. We don't want it to contradict itself, nor any other stated requirement. We want it to be unambiguous, susceptible to only one interpretation, you know, really striving for clarity here and testability based on that, and then verifiable requirement can be met through inspection, analysis, demonstration, or test. So that's very, very important. The requirement must be able to be met through inspection, analysis, requirement, and test.

Now we're going to again visit this case study where we look at what's going on in Orange County, California. I had the opportunity to participate in a project there. I'll read this to you. This section uses examples from Orange County Intelligent Transportation System 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 context for the agencies in the private sector who are deploying technology today and for the following 10 years. Strategies are organized as follows: Transit Management and Multimodal (MM), Traffic Management (TM), Incident Management and Emergency Response (IM), Traveler Information (TI), Performance Monitoring (PM), Communications and Connectivity (CC), Safety (SF), and Institutional (IN). Other strategic regional plans may have different names and different methods of expressing desired capabilities.

So we have this strategy from the strategic deployment plan that was labeled CC1, Countywide Communications Master Plan, Physical and Logical Connectivity to Support Multimodal and Multiagency Operations and Data Sharing Needs. So we developed this user need in a previous module called Multi-Network Ready. We said the city needs transportation controllers equipped with communications capabilities to accommodate connectivity with multiple systems and communications networks. Then we have the rationale of the user need. The city has legacy center-to-field communications to some arterials. The majority of arterials are supported by Ethernet communications through fiber or high-speed radios. It is expected that some applications will share a physical network while others will require separate networks. Again, in the italics, that represents our rationale. So that's our user need. Let's look at a possible requirement based on that user need. So we call this dual Ethernet capability. The transportation controller shall provide a minimum of two Ethernet ports supporting 10/100 Base T communications with RJ45 physical connectors. Now let's step through this. So we have our actor is the transportation controller, shall provide is our action, and we have a minimum of two support—two Ethernet ports, that's our target. And using RJ45 connectors, that's our constraint.

Let's take a look at another strategy from the SDP. Here we have CC3, provide a connected vehicles platform. Allow for the future possibility of connected vehicles in order to capitalize on the robust operational environment and further enhance the existing foundation. So we developed this user need, again, back in the previous module. Connected-vehicle (V2I) communications. The city needs transportation controllers that have—sorry, that will be capable of performing connected vehicle-to-infrastructure communications. Connected-vehicle applications have the potential for a major advancement in integrated traveler information safety, transportation management, and eco-driving. Its anticipated legacy controller units that were installed over eight years ago will not have the processing power to perform V2I communications. So this is an agency that's looked at hey, what's out there in the field, and that there's legacy equipment there that may not be capable of doing this communications, and they explained the rationale there.

So if we go to our well-formed requirement, we see we have one called processing power. The transportation controller shall have a CPU with a minimum CoreMark Benchmark of 600 per specification by the chip manufacturer. Now you need to understand, this is a little bit techy here, but CoreMark is a way of—is a benchmark of a way of measuring CPU performance, and what happens is manufacturers will state what their CPU is—CPU they're using in their unit and then you can find out from a website what is the CoreMark value. So we have our actor, the transportation controller. We have the action, shall have. We have the CPU as our target, and the CoreMark benchmark of 600 as our constraint.

Okay, here we have another strategy, less rapid transit. Roll out BRT service in a two-step implementation process. Technology applications could include TSP, real-time bus arrival information, automated fare collection. So you see multiple applications going on here. User need is to increase public use of transit buses. The city needs transportation controllers that can be used to help increase ridership of transit buses. The rationale is the city needs to improve customer service and ridership experience through the use of field applications that may include TSP real-time bus arrival information and automated fare collection and others. So there's our rationale for doing this.

Now this is interesting. We note that there's multiple applications being used here, and I want to make a special note of the fact that they talked about using real-time bus arrival information. Well, if you could imagine the operator of this transportation controller that's looking at the different programs that it's running, and now you're having schedules displayed on the front of the screen, well he's going to potentially want more visibility on that screen, or as we call it, more "real estate." So we created this requirement called screen size. The transportation controller shall have a minimum screen size of 16 lines by 40 characters. The default minimal screen size in the standard, the ATC standard, is eight lines by 40 characters. So this is a case where the user has made a note that he wants a larger screen. So we have the transportation controller as the actor, shall have is the action, the minimum screen size is the target, and we say 16 lines by 40 characters is our constraint.

Okay, not to confuse terminology but besides requirements, we can have special requirements that are called constraints. So what those are, are requirements that are kind of like inconcrete, that are not part of maybe a priority process where you're adjusting which requirements to meet in your spec. This is kind of a foundational thing. So we have this requirement called NEMA TS 2 equipment. So, we're stepping out of our previous example from the case study. This is separate from that.

The city needs transportation controllers equipped for its existing transportation field cabinet systems. The city has 70 percent of its field cabinet systems that are NEMA TS 2 Type 1, and 30 percent that are NEMA TS 2 Type 2. The transportation controller should be suitable for these cabinet systems. So that's a constraint. Now that constraint we can turn into a requirement. And here we have NEMA TS 2 Type 2 interfaces. The transportation controllers shall provide physical interfaces per NEMA TS 2 standard version 206 Section 3.3 for Type 2 controller units. Now you might say, "Hey, wait a minute, that doesn't satisfy our Type 1." Well, if you look at the NEMA standard, these Type 2 interfaces, NTS2, will allow the controller to also work in Type 1 cabinets. It's a little insider information. So we have an actor who is the transportation controller. We have the action, shall provide. We have the physical interfaces as the target, and we have the constraint where we reference here the standard, the NEMA TS 2 standard in section.

Let's give you some additional guidance. As I said at the beginning, I suggest that you review module A103, learning objective 2, avoiding the pitfalls when writing requirements. There must be at least one requirement for every user need identified in the ConOps, and requirements that pertain to optional portions of the ATC 5201 Standard must be written in the specification, and we'll talk about this in learning objective 3. But anything optional you need to identify and nail down in your spec. The requirements that pertain to non-optional portions of the standard may or may not be written in the specification, and that is really up to you. You will have something in that spec that says the controller unit shall conform to ATC 5201, so that will cover these non-optional portions. But I've seen where agencies want to make sure that all the requirements are explicit in their specifications. So that's what this last bullet is about.

Okay, resolving conflicts of requirements. So a reminder is that the ATC 5201 Standard describes a minimal level of capability for the controller units. Specifications based on that standard are a composite of standards—or other specifications—or referenced documents. This composite may consist of explicit requirements developed by the agency, explicit requirements gleaned from referenced documents, referenced requirements or sections in the referenced documents, and inherited requirements for reference documents with an established document precedence. In other words, the standard isn't used alone because to create your spec and for vendors to supply a controller to you, they have to know what kind of cabinet system the traffic controller is going to go into.

And that leads us into this next slide about establishing precedence between the various reference standards documents that are in your spec. So I suggest something like this: In the case where there is a conflict between the requirements in reference documents that is not directly addressed by a stated requirement—that's one of the ones you put in there—the precedence of the reference document shall be as follows: The agency specification requirements, the ATC 5201's standard requirements, and the transportation field cabinet system requirements, sample name is TS 2, Model 332, in the ITS cabinet. So, this is a suggested ordering of these. It is important to know that the ATC 5201 Standard has higher environmental constraints than any of the field cabinet systems that are out there so that it is designed to operate within the environmental limits of those field cabinet systems.

Sometimes an agency requirement may go beyond the standard. Here's an example on Ethernet ports. The transportation controller shall provide a minimum of six Ethernet ports supporting 10/ 100 BasedT communications with RJ45 physical connectors. Well, that exceeds the ATC standard because the ATC 5201 Standard requires four, but this is totally okay because it is still conforming to the standard, the ATC standard. Here's another one from ATC 5201, we see the ATC shall provide two internal 100-based TX store-in forward Ethernet switches. Switch one provides two Ethernet connectors and switch two provides two Ethernet connectors, and again, that's what I just said, that there are four required in the standard. And such instances are not considered conflicting, and the specification is still conforming.

Now in our requirements process, we should watch for requirements that subsume others as it can cause confusion. For instance, we have this requirement, generic serial port one. The transportation controller shall have a general purpose serial port using a male DB9 connector. And another place we have a requirement, called NEMA TS 2 Type 2 interface, is the transportation controller shall provide physical interfaces per the NEMA TS 2 standard. So in this case, the physical connections described in TS 2 standard provides this DB9 serial connector. So it's confusing because we don't know if that will suffice, the one that comes as part of our NEMA TS 2 requirement, or if the agency is wanting to actually specify a second one. So we need to watch for those things and decide, for instance, if that was enough then we wouldn't need the generic serial port requirement.

We have another activity. When a requirement is well formed, which part of the requirement may not be present? Your answer choices are a) action, b) constraint, c) target, or d) actor. Please make your selection. Okay, let's take a look at our answers. The question was when a requirement is well formed, which part of the requirement may not be present? If you said, "constraint," you are correct. Well-formed requirements may not have a constraint that provides the bounds of the requirement. You will recall that our other option is localization, and we'll get to that in a second. Action, if you said, "action," that was incorrect. There's always an action in a well-formed requirement. The X shall do this. Target, that's incorrect. There's always a target that receives the action in the well-formed requirement, so that was incorrect. And then actor, that was incorrect, because there's always an actor in a well-formed requirement. Typically a system, subsystem, or name thereof. Again, you need to remember that localization that identified the circumstances under which the requirement applies. That was the other option.

So, let's summarize what we just learned. We discussed writing requirements for ATCs based on user needs. We talked about the structure and characteristics of well-formed requirements. We wrote requirements for ATCs based on the agency user needs, and we discussed resolving conflicts—resolving conflicting requirements.

A question that came in was that the person said this seems more low-level than requirements for systems and in fact, that is correct. These, when you're dealing with devices and the interfaces on the devices, we have to get more specific. When we're talking about interfaces on systems, we get very specific about the communications if you recall from our NTCIP modules. So this is where it gets a little more nuts and bolts kind of thing in these requirements.

Learning objective 3, we're going to describe a specification based on the ATC 5201 Standard. We'll discuss the structure of the standard. We'll propose an outline for specification based on the standard, and then we'll discuss the essential areas that must be addressed so the controller unit conforms to the standard.

These are the sections of the ATC 5201 Standard: Introduction, overall description, et cetera, has the engine board details, which you may recall from A207B, and physical and user interface details parallel and serial I/O, environmental and test procedures. Performance and material requirements, quality control, and then there's the Linux operating system, and the required device drivers that vendors need to include on it, and there's a short historical background on traffic controllers. This is an important thing to remember, that the transportation controller specifications that come from agencies are subject to the agency's procurement process. So many of the agencies will include their specifications in their standards—so that—include the procurement specifications in the spec with the controller or the other devices that they're getting. So there's two ways the agencies may do this. They may create a specification based on a particular project, or the agency may have a standing spec for use over multiple procurements. We're seeing more of the latter. Agencies may have prequalified vendors list or a single vendor selected through a bid process so they may, out of this standing spec, they may keep an approved vendor list or approve a vendor through a bid process and then just go back to that vendor for a period of time.

Here's a proposed outline that we've developed for the ATC spec. Nothing is written in stone here. It fits nicely with our previous module when we were talking about user needs. So we have the purpose of the spec, the scope, and that's where we're talking about what's covered and not covered in the spec, references, background information. When we get to requirements, we talk about general requirements that might apply to the overall device, maybe, you know, thickness of metal if, in some cases, people get into that. Maybe electronic requirements, maybe quality requirements that you have. They may be in there. Then we have the transportation field cabinet system requirements. You know, what kind of equipment is it going to go into? We have the user interface requirements. That's what you want the user to be able to do on the front panel, or in the case of controllers that have backdoors, what you want to go on the back panel. I/O requirements for the controller, performance requirements, environmental testing requirements, warranty requirements. That's very important, is to get as much warranty as you can, and you may, kind of in the same vein, you may want get software contracts for any software you get on the controller. In fact, you may want to have a software support contract for the Linux operating system that is operating on the controller. Other requirements may be packaging, delivery, documents you want to have sent with the equipment, et cetera, things that would normally go into an agency spec.

Okay, there are areas we need to address that are optional, or meant to be minimums and expected to be addressed by agencies. One of these are operational voltages. There's options for that in the standard, depending on the transportation field cabinet system that is being—that the controller is to run in. There's user interface requirements that are different. The minimums may not be what the user wants. We had a requirement previously that showed that a user wanted a 69 display. It's possible to have a graphics display. It needs to support the text-based display also. You have I/O requirements for the controller. And those—and then we have the CPU performance and memory requirements. Again, there are minimums in there and the agency may want to choose a, you know, some contemporary processor. Again, the standard is designed so that it can grow with technology. If you recall, the processor can advance, the engine board can be replaced. And so over time, you may want to change these performance and memory requirements, and I'm not talking about every year. I'm talking about, you know, when you do some next major deployment.

There may be other requirements that you want to include that further identify the kinds of things you specifically want in your standard, or in your specification. So here we have the—some example operational voltage requirements. In this case, it's a NEMA cabinet, so we have requirements for operating voltage, operating frequency, and power interruptions. There are user interface requirements, and these are the minimums for an ATC unit. The unit front panel needs to have a CPU LED indicator on it, right, so we know the controller is working, is operational, and it should have an Ethernet port and a USB port. Now we used to require those be actually on the front, but now in ATC 5201 version 6, the Ethernet port and the USB port can be on the back for units that might go into a 332 cabinet or ITS cabinet. There always needs to be either a D serial connector for a console, or an 8P8C modular jack serial connector for a console. So, if you wanted to have an external console that plugged into your controller, you could do this over a serial line and the 8P8C modular jack actually looks just like an RJ45 jack, but in this case it's used for serial.

So in addition to this, we want to have a connector for the front panel that actually is sitting and residing on the controller itself or having a special controller that goes—that can be used, for instance, by the guy standing next to the machine, sort of an external front panel. So that is—for the external front panel, it is the 9 pin D connector, and if you're going to have a traditional front panel on the controller, you need to have a keyboard, the LCD, and a bell.

Now here's some user interface options, and we call these—the committee calls these—user interface options because they have to do with what the operator sees or works with on the controller. You may say, "Hey, this sounds like a memory thing," but just roll with me on that. So here's some optional features. We have a data key. That's kind of a memory thing. Different type of format than your standard USB devices. 2070s have that option available. You have AUX Switch. Again, 2070s have—2070 controllers have this AUX Switch available, and it only makes sense to have that switch available if there's a keyboard and LCD involved. Then there's power optional features. You know, some companies, you just plug it in and the controller runs and others have units where they actually have an on/off switch, so the power switch is an option. And power LEDs show the health of the power supply and so those are optional whether an agency wants to have them or not.

So the user interfaces will have some restrictions based on the architecture they've selected, and the—but the standard itself allows the agencies to expand on the minimum requirements in the standard and add additional features that you want. Now, in doing this, I want to caution you that if you get a high-res graphic interface, it needs to operate in a mode that supports the basic ATC 5201 and ATC 5401 standard interfaces, and again, 5401 is the API standard. And then also, you are cautioned that required manufacturer-specific front panel keys in your spec will restrict the option of the ATC providers that are available to you. So, be careful about specifying, you know, certain shaped keys or certain kinds of keys, because that may lock you into a particular vendor. So here's an example user interface requirement, kind of combined together here. The transportation controller shall provide a user interface with the following and then you see our requirements listed out there.

Now let's talk about the serial and parallel I/O requirements. As we said, the TFCS standard, that's the cabinet standard, that's the cabinet itself if the controller is going to go in to, will have requirements for serial and parallel I/O, and additional serial ports may be specified by the agency based on your needs. Another caution here is to not unnecessarily require communications ports as it can drive up costs and limit your choices of vendors. Here's some examples: generic serial port 1, the transportation controllers shall have a general purpose serial port using a male DB9 connector. The second one was the transportation controller shall have a general purpose serial port using a male DB25 connector.

Now, these are CPU, memory, and performance requirements, and this is harder to do because initially when you get your controllers and they're general purpose machines, they're going to be much more powerful, maybe a couple thousand times more powerful than a 170 and hundreds of times more powerful than a 2070. And so you're going to have to decide: What is the minimum requirements that I am going to need? Now the minimum CoreMark of 500 is what's in the standard, and the minimum DRAM, that's your traditional memory you have on your PCs, is 64 megabytes. Short-term, non-volatile memory, or SRAM, is one megabyte minimum. SRAM is kind of like the cache on a CPU that you get on your home computer. It's very fast, but very expensive, and so it's kept at a minimum. And then your long-term storage, which is flash memory, is 16 megabits in the standards. And your flash is like your hard drive, in this case, on your PC. Agencies are cautioned not to arbitrarily require the highest number of MIPs of memory available as it can drive up costs and again limit your choices of vendors. So here's an example of memory requirement, DRAM memory, the transportation controller shall have DRAM capacity of 128 megabytes minimum, and this is double what the minimum was.

Now we have some examples of other requirements. Here's some software requirements, and these are very important to address in your spec. Application tool chain: The vendor shall identify in writing the tool chain, that's the compiler and C libraries used to create application programs for the engine board of the transportation controller. Right, we want to be able to run other programs on the transportation controller we buy from company A, and to do that, though we need to know how to build those programs so that it will run on company A's controller, so you need to get that in writing. The Linux Board Support Package tool chain: The vendor shall identify in writing the tool chain—that is again, the compiler and C libraries, used to create the Linux Board Support Package for the engine board of the controller. So this has to do with not the applications, but actually the Linux environment that's on the engine board of the controller. And then the Linux BSP source code: The vendor shall provide access to the source code used to produce the Linux Board Support Package environment for the engine port. This kind of thing you are getting into intellectual property kinds of things so you need to make a special arrangement for this with your vendor. It could be you could have a similar one that you've had with the other ones, that they just tell you. In other cases, they may want to have an escrow—or I should say—they may provide that software for you, not just tell you but provide that software. But in other cases, they might want to have some sort of escrow account. That's to protect you if the company that provided the unit goes away.

Here's one if you're going to be specifying software. Well, when—this is important so that you can buy other software. It says the vendor shall provide operational API software for their transportation controllers once the API reference implementation is available from AASHTO-NEMA, and ITE. There is a project underway to build a reference implementation of the API Standard 5401 and then vendors can take that and run that in their controller, so it should be available to everyone, and our target is by the end of 2015. And so, if you were to purchase units now, you'd want them to have, in your spec, that the API software will be provided once it's available. And you can go back to the slides on creating a specification based on the 5401 standard, and additional guidance from procuring application software module A208.

So we have another activity. Which of the following is not an essential part of an ATC specification? Is it a) optical disc requirements, b) CPU performance requirements, or c) Transportation Field System Requirements, or d) user interface requirements? Please make your selection. Let's review our results, or our answers. Which of the following is not an essential part of an ATC specification? If you answered optical disc requirements, you were correct. There is no mention of optical discs in the ATC 5201 Standard. If you said, "CPU performance requirements," you were incorrect. CPU performance requirements should be set by the user. If you said, "TFCS requirements," you were incorrect. The agency needs to let the vendors know what kind of TFCS architecture the unit will be run in. And if you said, d) user interface requirements, that was incorrect. There are various user interface options provided by the 5201 Standard and these requirements should be explicit.

Summarizing our learning objective 3, we described a specification based on the ATC 5201 Standard. We talked about the structure of the standard. We talked about the components of the specification based on the standard, and we talked about essential areas that must be addressed so the controller unit conforms to the standard.

A question came in. Where do you put the application requirements we may have discovered in developing our ConOps? Well this is very good. During the ConOps development process, not only are you getting your user needs—you're identifying your user needs, but you also find, "Hey, what kinds of programs are we going to be running on this, and what kind of software and what kind of capabilities are we going to want?" That's all going to come out of that process also. Now I would encourage you to put those kinds of things in a separate document or a separate section of your specification, because potentially those application programs could be provided by multiple vendors separate from the vendor who supplied you with the hardware platform.

Let's move on to learning objective 4, verify an ATC procurement specification. Talk about verifying the specification using traceability and verifying conformance and compliance. Verifying the spec using traceability. We, in our specification, we create a matrix of tracing user needs to requirements. It's a tool to help verify completeness and correctness, and we suggest capturing this traceability through the requirements development process. In other words, as you're generating requirements, if you recall back to our process, when you're generating those requirements, you should be—you may find that you've actually created a requirement that didn't have a user need. So by always tracing back what user need your requirement went to, you'll capture user needs that you may have missed in the user needs development process.

In doing our needs-to-requirements traceability, we need to make sure that every user need is addressed by at least one requirement. Every requirement must trace to at least one user need, and any need that is not addressed by at least one requirement means that the requirement was missed, or that the user need must be reevaluated. Then any requirement that does not address at least one user need, this is kind of a reverse of what we just said, the requirement must be reevaluated, or a user need was missed. Every aspect of each user need should be addressed in the requirements. It's important to look at the rationale to understand what the user need was intended to address, and make sure that the salient parts of that need are addressed in requirements.

Here's an example of a needs-to-requirements traceability matrix. You will have seen such things in other modules in the PCB program and here you see the user need ID, the user need, the requirement IDs that address that user need, and the requirement names. The bottom one that has kind of a pattern through it, I was just showing that this is part of a bigger table of needs and the corresponding requirements.

So this is—we're using this traceability to verify conformance. So conformance is a condition that exists when an item meets all of the mandatory requirements as defined by a formal standard. So this is about a relationship between something and the standard. So typically a procurement spec or physical device is said to conform to a standard, so you may have a device that conforms to a standard. You may have your spec that conforms to the standard, but the conformance to the standard is not enough to achieve things like compatibility, portability, interoperability, and interchangeability, right, because the standard has options in it. So we need to get specific so that we can do that and keep our options open and keep the power of the system and the increased life expectancy by being more specific. So, verification of conformance of a procurement spec is performed by inspection, comparing the specification to the ITS standard. So, when we're developing our spec, and we go back through this traceability and we call it by inspection, we're making sure that it conforms to the standard.

Now compliance is the term we use when we're talking about a procurement specification. It's a condition that exists when an item meets all the requirements of a procurement spec. Typically devices, software, communications are set to comply to the agency spec, right. We talked about conforming to a standard, and now we talk about complying to the spec. Agencies should write their procurement specs so that you're specific and you can have the opportunity to have compatibility, portability, and all the rest. Verification of compliance of a device, software, or communications is performed through inspection, demonstration, analysis, and testing. You'll remember those from some of our other modules. So these are the ways that we—verify compliance—inspection, demonstration, analysis, and testing. Again, we're comparing the item to the specification that's compliance.

Okay, we have another activity. Which of the following is a true statement? A) agencies use standards so they don't have to use specs, b) there should only be one requirement per user need, c) demonstration may be used to verify compliance, or d) traceability is not used in verifying specifications. Please make your selection. Our answers—the question was "Which of the following is a true statement?" If you answered d) demonstration may be used to verify compliance, you are correct. The other methods were inspection, analysis, and testing. If you said "A," that was incorrect. Agencies use standards to write their procurement specifications. The standards are not a substitute for their specifications. If you said "B"—there should be only one requirement per user need, that's incorrect. There may be multiple requirements needed to fully address a user need. And if you said "D"—traceability is not used in verifying specifications, that's incorrect. Traceability is used to help determine if the specification is complete and all the user needs are identified—needs identified are addressed.

Let's do our summary of learning objective 4. We talked about verifying an ATC procurement specification. We talked about verifying the specification using traceability, and then we discussed verifying conformance and compliance. I had this question come in previously—how many requirements should I use in my specification? And, to be honest, you can't really answer that question, because some agencies will create volumes for their specifications and other ones will create briefer documents, so it really depends on the agency and your procurement practices and how much information you want to include in your spec itself. I encourage you to make an assessment of what you want to put in your spec based on some of the constraints you may have in developing it, such as time, et cetera. This also goes to your education of the people around you of what you're trying to accomplish in preparing an ATC specification, and the approach we've discussed in this module.

So what we've learned—in a systems engineering development process, the agency specification is the result of requirements development. Two, specifications based on the ATC 5201 Standard are a composite of standards and/or other specifications. Three, areas that must be addressed in an ATC specification are operational voltages, user interface requirements, input/output requirements, CPU performance, and memory requirements. Three, we learned that agencies should verify that their ATC specification conforms to ATC 5201 version 6, and verify that vendors provide controllers that comply with their ATC specification.

Here are resources. There's a larger list in the participant supplement. We had one other question—well, just one comment I have is that this module really ties together ATC 207a and b, A208, A307a, and of course, this module, and it really puts together everything you need to know about creating an ATC specification. I'm not saying that's it's easy to do. It has a lot more rigor but the benefits long-term, you'll find them in that fashion. And this concludes our module.

[#### End of 307b.m4v ####]