Module 7 - A202

A202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

(Extended Text Description: Large graphic cover page with dark blue background with the title in white letters “A202 Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content” At the middle left is the “Standards ITS Training” logo with a white box and letters in blue and green. The words “Student Supplement” and “RITA Intelligent Transportation Systems Joint Program Office” in white lettering are directly underneath the logo. Three light blue lines move diagonally across the middle of the blue background.)

A202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content

Table of Contents

Learning Objectives 2

Understanding the Role of User Needs 3

Understanding the Structure of Standards 7

Analyze Concept of Operations for User Needs 10

Write a User Need 13

Extract User Needs from other Relevant Standards 16

Validate User Needs 26

References 28

Learning Objectives

The following six learning objectives are designed to guide users to explore the standards for user needs to prepare a specification for standards-based ITS systems. This step is necessary because certain earlier ITS standards did not use the systems engineering process (SEP) and hence standard documentation does not provide the standardized definitions of user needs and requirements.

This supplement provides additional materials on the following six learning objectives.

1. Understanding the Role of User Needs
2. Understanding the Structure of Standards
3. Analyze Concept of Operations for User Needs
4. Write a User Need
5. Extract User Needs from other Relevant Standards
6. Validate User Needs

Understanding the Role of User Needs Definition of a User Need

IEEE standard 1362 defines user need as: "a user requirement for a system that a user believes would solve a problem experienced by the user." (Note: the use of word "requirement" here does not imply system requirements)

The NTCIP family of device standards refers to user need as 'The business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use." While this is termed a "user need' within the NTCIP community, it reflects needs of all stakeholders."

By establishing user needs, users declare what they want from the intended system and the system must satisfy stated user needs. If this step is not taken carefully, the outcome could be an incomplete system and a non-interoperable system may result. To avert such adverse outcomes, we must ensure that user needs for all concerned ITS standards are identified and properly written in the specification.

Figure 1 helps us to understand four key points related to the user needs role in preparing specification for standards-based ITS systems.

• First, it shows how ITS standards are organized and the related training modules.
• Second, as shown on the left, standards with SEP have documented user needs and are addressed by Modules A102 and A201. Users simply select user needs for a project.
• Next, the right side shows standards without SEP content and is addressed by Module A202. In this situation user needs are inferred and written using criteria. This is a key theme of this course.

(Extended Text Description: A graphic box starts with heading ITS Standards Data-Communications-Equipment. Underneath this box on left there are three rectangular text boxes and there on right side. Both are separated with a line down the middle. Boxes on the left are indicating SEP based standards content. First box states with SEP Content, second box states user needs documented, last or second box states Agencies Select User Needs. On the side of these boxes a vertical text says Modules A102 and A202 addresses these discussion in the boxes. Similarly arranged on the right side, first text box states without SEP Content, second box states User Needs NOT Documented and last /third box states Agencies Infer User Needs. On the right side vertical text A202 is shown.)

Figure 1: Understanding ITS Standards User Needs

• A procurement specification may include both types of standards to meet system requirements. Particularly a regional large system project may include a wide variety of mixed standards and will require collecting user needs from both sides in the above chart to obtain a desired set of functionality. In such a situation one must distinguish user needs (SEP-based) from functional requirements (Non-SEP standards).

As users we must learn to deal with both types of standards as they are often mixed in operational environment and applications. Agencies often have to procure systems that may deploy standards with both SEP content and without SEP content. This situation occurs particularly in large integrated ITS projects. The following examples illustrate how the use of mixed standards may be needed as shown in the above chart. These user needs will require use of two types of standards: NTCIP DMS v2 standard with SEP content and NTCIP 1205 vl CCTV standard without SEP content.

The following example user needs from the Oregon Department of Transportation specification (see the references section) illustrates this situation. The specification will need to take two initial steps: tailor (select) user needs from the already existing DMS v2 standardized user needs, an easy process; and the CCTV standard needs, conduct an extraction process suggested by this course to derive user needs from the Conformance Groups (CGs) and Management Information Base (MIB) content.

User Need 1.1

"Traffic operations and management has a need for a common system software package to access remote field devices (Traffic signals, CCTV, DMS, and RWIS)."

User Need 1.2

"TMC may also need to communicate messages with other centers in the region involving these devices."

Role of User Needs in an ITS Project

Systems engineering experiences have shown that generally user needs tend to remain stable over time (if needs changed frequently it would be impossible to build a system interface to satisfy those needs). It is this inherent stability in the user needs that binds the scope of the system interface. Well written needs describe one or more system features and the intent of the said need in addressing a user problem or responsibility. User needs then drive the requirements definition and allow development of complete and correct requirements (Ref. IEEE 1512 Guide and NTCIP Guide).

The user needs identified in the NTCIP device standards do not reflect all the possible user needs that may be desired for that device. The user needs listed only reflect those features that are commonly desired by stakeholders and thus are supported by the device standard. Each procuring agency may have additional user needs not identified by the standard, and those user needs will have to be expressed in the procurement specification.

Requirements

IEEE 1233 standard defines a requirement as a condition or capability needed by a user to solve a problem or achieve an objective. The NTCIP family of device standards defines the requirement describing a condition or capability to which a system must conform; either derived directly from user needs or stated in a contract, standard, specification, or other formally imposed document (a desired feature, property, or behavior of a system).

Distinction between User Needs and Requirements

Confusion may arise when proper terms are not recognized and used throughout the SEP. This is true for all ITS standards and teaching materials. Readers are advised to use only terminology defined by the standards in their specification and standard testing documents. Terminology is a common reference between users, developers, vendors, and system managers.

The User Needs document (if one exists separately or as part of the ConOps plan) provides input for the (System) Requirements. Sometimes the two get confused or merged into one, and it's useful to distinguish between them. Helping maintain this distinction one must use the term User Needs to User Requirements, but the terms are interchangeable. System Requirements, on the other hand, are formed and written in Engineer-speak. There is a step of Requirements Analysis performed to transform the User Needs into a set of System Requirements that will address them. (Please review Module A201 for details on requirements).

User Needs and Requirements Relationship

(Extended Text Description: A graphic box with title User Needs has an arrow next to it which points to a text box labeled as Requirements. Over the arrow term transformation appears. The first text box which is User Needs is thus shown related to the Requirements shown in second box. The User Needs box contains the text: User needs communicate the problem to be addresses, Through user needs, developer (supplier) understands why the system is needed, User needs represent what capabilities are desired and how they will be used operationally, User needs describe one or more features desired from a system. The Requirements box contains the text: Requirements are refinements that specifically state what the system shall do, how well it should do it, and under what conditions?)

Figure 2: User Needs and Requirements Relationship

Another distinction between the user needs and requirements is that ultimately verification is done against the Requirements, while validation is done against the User Needs. Validation answers, "Have we built the right system?" While the verification answers "Have we build the system right?"

Figure 2 shows how user needs are related to requirements.

User Needs Affect Interoperability

For an agency to achieve interoperability and interchangeability, procurement must ensure that a careful assessment of user needs is done and a common set of needs are established as a first step. For example, user need shown here state that a TMC desires to exchange messages with other centers. Without this user need written in the specification, system developers will be unaware of the users' intentions and underlying operational needs. This will become a problem that needs to be corrected later on. The user needs are central to system development and if we missed them or designer misrepresented user needs, incomplete or non-interoperable systems could result. What is important is that the agency personnel understand what they want their devices and systems to do for them because this will provide input to the application of the mixed standards for their procurement process.

Our learning objectives have helped us to start a discussion on selecting user needs from conformance groups and MIB objects. We should realize that when developing an agency specification the standard is tailored to an agency's needs and requirements. To obtain interoperable ITS devices from an agency specification, the agency should examine applicable standards and resolve the following items:

• Which optional conformance groups (user needs) for the ITS device should be supported
• Which optional objects for the ITS device should be supported;
• Specify minimum support values for certain capabilities (i.e., the minimum number of presets for a CCTV control and plans in a traffic signal controller, the minimum number of phases, size of event logs, number of fonts supported, etc.); and
• Interpret objects to have a consistent implementation for the ITS device (i.e., patternTableType from NTCIP 1202:1996).

User Needs Dictate Features

A feature is a behavior of the device. A device has more than one feature to serve desired (assigned) functions.

The features identify and describe the various functions that users may want the device to perform. These features are derived from the high level user needs identified in the problem statement but are refined and organized into a more manageable structure that forms the basis of the traceability table; the Protocol Requirements List (PRL).

User Needs Affect Interchangeability (Vendor-independence)

A condition which exists when two or more items possess such functional and physical characteristics as to be equivalent in performance and durability, and are capable of being exchanged one for the other without alteration of the items themselves, or adjoining items, except for adjustment, and without selection for fit and performance. (National Telecommunications and Information Administration, U.S. Department of Commerce).

According to the NTCIP Guide, interchangeability reflects the capability to exchange devices of the same type on the same communications channel and have those devices interact with others devices of the same type using standards-based functions. With interchangeability, system components can be changed out (switched) with similar components from different vendors because they possess common functional and physical characteristics. An example of interchangeability is signal controllers from different manufacturers interacting with each other to provide traffic signal coordination along an arterial throughway.

Understanding the Structures of Standards

Figure 3 provides quick visualization of two situations faced during specification preparation based on the mixed use of ITS standards and the user needs discovery process. It shows how user needs, requirements, and design concepts are organized for both SEP-based (top part) and non-SEP based standards (bottom part).

Those without SEP content do not have documented ConOps/User Needs, and the agency must specify "functions" directly from the standards by inferring design concepts. To aid in that effort, this second learning objective will guide us to understand structure of standards to discover user needs.

(Extended Text Description: There is a graphical representation to explain two situations faced during specification preparation based on the mixed use of ITS standards and the user needs discovery process. First row labeled as USER NEEDS EXISTS and shows five text boxes: from left to right; Subject of A102 Module, Agency specification, Standardized user needs, requirements and last one Design concepts. The second row is labeled as User Needs Don’t Already exist and shows three text boxes from left reads, subject of A202 Module, Agency specification and last one, design concepts. In the middle a question mark appears to suggest what we should do, since user needs and requirements are missing. )

Figure 3: PCB Modules Role in User Needs Discovery Process

Structure of Device Data Standards (C2F) with SEP Content

The device data standards shown in Figure 4 contain user needs within the standard's structure. The following example of DMS v2 application shows that the user will be required to explore ConOps section to map project needs to those in standards and the complete specification.

(Extended Text Description: A small graphic of a DMS (DMS NTCIP 1203v2.39 User Needs Inside) is shown in the slide next to text, which reads: Structure of a Device Standard with SEP Content - 1. ConOps/User Needs - 2. Functional Requirements - 3. Dialogs - 4. Management Information Base (MIB)-Objects Definitions - 5. Requirements Traceability Matrix (RTM).)

Figure 4: Structure of Device Standards with SEP Content

Center to Field (C2F) Standards with SEP Content (Figure 4)

1. NTCIP 1203 DMS v2 or later
2. NTCIP 1204 ESS v2 or later
3. NTCIP 1209 v2 Transportation Sensor Systems (TSS)
4. NTCIP 1210 Field Master Stations (FMS , Part I SSM (v1.46) (This standard is under development)
5. NTCIP 1211 Signal Control and Priority (SCP) v2.0
6. NTCIP 1213 Electrical and Lighting Management Systems (ELMS) v2.19

Structure of Device Data Standards (C2F) without SEP Content

The device standards shown below do not contain user needs and agencies preparing specifications will be required to extract user needs from the standard's structure. The following example of the CCTV application shows that the user will be required to explore Management Information Base-MIB and Conformance Groups (CG) to discover user needs. (This course is intended to help users in defining user needs for a local project using MIB-CG).

Center to Field (C2F) Standards without SEP Content (Figure 5)

1. NTCIP 1202 Actuated Traffic Signal Controller (ASC) v1 and v2
2. NTCIP 1205 v1 CCTV
3. NTCIP 1206 v1 Data Collection
4. NTCIP 1207 v1 and v2 Ramp Meters Control Units
5. NTCIP 1208 Video Switches
6. NTCIP 1212 Network Camera Operations

(Extended Text Description: A small graphic of CCTV is shown in the slide next to text, which reads: Structure of Device Standards without SEP Content - 1. CCTV Overview - 2. General - 3. MIB - 3. Conformance Groups (CG) - 5. Conformance Statement - [Both MIB and CG have user need content].)

Figure 5: Structure of Device Standards without SEP Content

Management Systems Standards with SEP Content (C2C)

Currently, TMDD v3 standard is the only management system standard available with the SEP content. It is helpful to study structure shown in Figure 6 to learn the techniques used and perhaps apply to those without SEP content. 1. TMDD Standard for Traffic Management Center to Center Communications, v3.0

(Extended Text Description: Text box contains text on Volume I and Volume II, which reads: TMDD v3.0 Standard Structure - Volume-I: ConOPs/Requirements/NRTM - Volume-II: Dialogs/Messages/Data Frames/Data elements/RTM.)

Figure 6: Structure of Management System

Management Systems Standards without SEP Content (C2C)

Standards are without user needs and user should extract user needs. For example IEEE 1512 family of standards are currently deployed with certain messages have the structure shown in Figure 7.

1. IEEE 1512 Incident Management
2. IEEE 1609.X DSRC
3. SAE J2354 ATIS
4. SAE LRMS Series
5. SAE J2735 DSRC Message Sets

(Extended Text Description: A small text box of IEEE 1512 family of standards is shown to the right of the text: Structure of Management System Standard without SEP Content - 1. Requirements [Without ConOps/User Needs] - 2. Dialogs - 3. Message Sets - 4. Data Frames-Data Elements.)

Figure 7: Structure of Management System Standard without SEP Content

Equipment Standards

1. NEMA TS-2 2003, Traffic Controller Assemblies with NTCIP Requirements?Version 02.06, http://www.nema.org/stds/ts2.cfm
2. Advanced Traffic Controller (ATC), Standards Files on Hand-ATC API v2.06b
3. ATC Cabinet (Under development)

Summary Note

User should recognize that since not all of the standards include the SEP content (as shown before); when working with a standard that does not include this content, the procurement writer is required to provide the extra details himself.

Nonetheless, these standards were generally developed based on a somewhat common, if undocumented, understanding of the most important user needs. In fact, the user needs addressed by the standard can often be identified by looking at the structure of the standard and the conformance statements contained in the standard. These will often group certain design elements together in a logical fashion so that the reader can see the intent of how the data is intended to work together. However, this level of understanding generally requires a more detailed knowledge of the given subsystem.

This task requires a much greater level of understanding and expertise than writing a specification for a standard that includes SEP content, and this is a topic addressed by higher-level modules in this procurement course.

Analyze Concept of Operations for User Needs

What is Systems Engineering?

Systems engineering (SE) provides a systematic process and tools that support ITS project management. Use of SEP is mandatory for federally funded ITS projects (Rule 940). The Systems Engineering Handbook by FHWA introduces SE as follows:

"Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem."

"Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs."

(Extended Text Description:A graphic of the systems engineering process (SEP) is shown. The main graphic of the SEP is a V-shaped diagram with some additional horizontal “wings” on the left and right side of the top of the V. Starting from the left “wing” the steps are regional architecture, needs assessment, concept selection, project planning, and systems engineering management planning. At this point the steps begin to descend the left side of the V with concept of operations, system requirements, high-level design, detailed design, and software hardware and field installation. At this point the steps begin to ascend the right side of the V with unit device testing, subsystem verification, system verification and deployment, system validation, and operations and maintenance. At this point the steps are on the right “wing” of the V with changes and upgrades and retirement/replacement. The following arrows supplement the figure:

• A time line at the bottom of the figure indicating that all steps proceed over time with the steps forming the V overlapping one another.
• A downward arrow on the left side of the V that indicates that these steps deal with decomposition and definition.
• An upward arrow on the right side of the V that indicates that these steps deal with integration and recomposition.
• A horizontal arrow near the bottom of the center of the V that connects the detailed design step to the unit testing step.
• A horizontal arrow a little higher that connects the subsystem requirements step with the subsystem verification step.
• A horizontal arrow a little higher that connects the system requirements step with the system verification step.
• A horizontal arrow near the top of the V that connects the concept of operations step with the system validation step.

)

Figure 8: Systems Life Cycle Process ("V" Diagram) Source: Systems Engineering for ITS, FHWA, Page 11

Figure 8 shows the systems life cycle process presented in the "V" model. The systems engineering approach defines project requirements before technology choices are made and the system is implemented. On the left side of the "V", the system definition progresses from a general user view of the system to a detailed specification of the system design. The system is decomposed into subsystems, and the subsystems are decomposed into components - a large system may be broken into smaller and smaller pieces through many layers of decomposition. As the system is decomposed, the requirements are also decomposed into more specific requirements that are allocated to the system components.

As development progresses, a series of documented baselines are established that support the steps that follow. For example, a consensus Concept of Operations (ConOps) (USER NEEDS) supports system requirements development. A baseline set of system requirements then supports system design. The hardware and software are implemented at the bottom of the "V",

and the components of the system are then integrated and verified in iterative fashion on the right. Ultimately, the completed system is validated to measure how well it meets the user's needs.

The following summary of SEP benefits guides us in further discussion. SEP Benefits

• Improves coordination between the project phases:
  • From Concept of Operations to Requirements
  • From Requirements to Specification/Design
  • From Design to Implementation and Testing.
• Supports System Acquisition
  • Structured Methodology and Work Products
• Supports Quality Assurance and Control
  • Structured approach to Validation and Verification
  • Traceability of Requirements to Design and Test

Concept of Operations (ConOps)

IEEE Standard 1362 for ConOps states: "A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users' viewpoint. The ConOps document is used to communicate overall quantitative and qualitative system characteristics to the user, buyer, developer, and other organizational elements (for example, training, facilities, staffing, and maintenance)" - [IEEE Std 1362, abstract].

NTCIP Guide offers this definition of ConOps: A Concept of Operations (ConOps) is a document, written from the user and organization's point of view, that clearly defines the situation or problem scope, identifies user needs, and the operational context for the information exchanges that the system interface will support. The ConOps should include components shown in the box with the participation from all users that benefit from or are impacted by the system.

(Extended Text Description: Pullout box with the following text: Elements of Concept of Operations (ConOps), - Identification of Stakeholders - System Overview - User Needs Assessment - Stakeholder Roles and Responsibilities - Operational Scenarios)

User Needs Location on Systems Life Cycle Process Diagram

Figure 9 shows the location of user needs at various stages of the systems development life cycle. Regional user needs are typically identified and collected by the regional architecture process, scenario driven user needs are documented in ConOps, and maintenance operations/related needs are again reassessed at that stage.

User Needs Locations on "V" Model

(Extended Text Description: The graphical view of SEP life cycle process used in Figure 8 is also used here to show where user needs are located. In this slide, at the top of the Vee, there are three boxes in yellow. The first box is Multiple Stakeholders Needs Assessed and points to Regional Architecture on Vee. Second box marked as Operational Problem Solving and Agreement points to Concept of operations on the Vee, and last one is marked as Reassessment Gaps-New Needs and points to Operations and Maintenance which is on the right top of Vee. From the original presenter's notes: First location: Regional stakeholders identify, discuss, develop consensus, and agree on common user needs for mutual benefits at the regional architecture level. User needs are assessed by the regional architecture process. Second location: Stepping out of the architecture and concept phases, the agency articulates Concept of Operations (ConOps) and scenarios-driven user needs, and defines what a device or system being acquired is to do. All of this is documented in the ConOps. Most of us will agree that both regional architecture and the ConOps plan are a gold mine for user needs. Third location: As shown in the right side of the diagram, at the operations and maintenance stage, user needs are again reassessed. We often find out what works, what doesn’t, and crucial gaps, etc.)

Figure 9: Location of User Needs at Systems Life Cycle Stages Source: Systems Engineering for ITS, FHWA, Page 11

Write a User Need

Why Are We Writing User Needs?

A procurement writer is required to develop a specification to acquire a standards-based system by deriving user needs from standards.

The problem for the procurement writer develops when a project needs to deploy standards without SEP content. These standards do not contain documented user needs from which an agency can select or customize. There are several such standards (both devices and systems) developed. For example, traffic controller or CCTV standards.

This is a problem for agencies: What do you write? How do you get user needs and from which sources? Once we get through these steps, one needs to prepare a project's operational needs.

Introduction

As stated earlier, a user need describes a business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use. This representation may occur in many ways expressed by different users with a varied understanding of the baseline case. This could lead to incomplete system development or ambiguous statements confusing developers. To avoid such occurrences, users must understand how to write user needs and put them in proper context and meaning of desired interoperability and/or need for vendor independence.

User Needs Wording

According to the IEEE 1512 Implementation Guide; "Definition of user needs is one of the key aspects of the system engineering process. User needs tend to remain stable over time. (If needs changed frequently, it would be impossible to build a system interface to satisfy those needs.) It is this inherent stability in the user needs that bounds the scope of the system interface. Well-written needs describe one or more system features and the intent of that need to address a user problem or responsibility. User needs then drive the requirements for the system interface definition and allow development of complete and correct requirements. It is very important that the user needs be developed with all users involved. Creating user needs might involve several iterations to resolve conflicts. After it is complete, agreed upon, and approved, the user needs help manage the expectations of users and the rest of the development process." (Ref. IEEE 1512 guide).

Criteria for Writing User Needs

In general, ITS Standards with SEP content have followed the following SE criteria to define user needs and we need to understand this and apply to user needs extracted from standards without SEP content.

1. Uniquely Identifiable: Each need must be uniquely identified (i.e., each need shall be assigned a unique number and title).
2. Major Desired Capability (MDC): Each need shall express a major desired capability in the system, regardless of whether the capability exists in the current system or situation or is a gap.
3. Solution Free: Each need shall be solution free, thus giving designers flexibility and latitude to produce the best feasible solution.
4. Capture Rationale: Each need shall capture the rationale or intent as to why the capability is needed in the system.

The above criterion is used in the process of extracting and writing a user need from the standards without SEP content as discussed in the next section.

Note 1: Users are also reminded to use proper terminology: user needs are "written" (subject of Module A102/A202), while requirements are "formed" (subject of module A102 and A203). Both user needs and requirements are prepared with corresponding criteria.

Note 2: For SE-based standards, both user needs and requirements are provided by the respective standards. For non-SEP based standards, users are required to prepare user needs and requirements using guidance provided in these modules.

Example of a Well-Written User Need

The previous stated criteria are applied in the following user need example taken from NTCIP 1203 v2 standard (Figure 10).

Figure 10: User Need for Control of DMS from Multiple Locations

An implication of user need is shown in Figure 11, which illustrates how multiple users can be well-served. Conversely, if a user need is not well-written and does not meet expectations of concerned stakeholders the project outcomes will suffer. Many agencies desire interoperability but may also not achieve it if user needs are not defined or missed. For example:

"What if the user had missed the above need in the project specification, and later expects to use the DMS form multiple locations? What if the DMS supplier is NOT aware of your intentions to control the sign from local and remote locations?"

(Extended Text Description: To illustrate control of a DMS from more than one location, a graphical representation of TMC A and TMC B is shown as buildings on the left and both have arrow terminating in a sign controller which drives a DMS sign on top shown with a message “EXIT 15 Closed Reopen December 14”. There is picture of lap top below sign controller. )

Figure 11: Control of DMS from Multiple Locations

Example of a User Need from NTCIP 1203v2 DMS standard 2.5.2.1 Control a DMS from More than One Location

This feature addresses the need for DMS to be controlled both remotely (e.g., from one or more central computers) and locally (e.g., from the controller directly or from a laptop computer connected to the controller). Whether the DMS is controlled remotely or locally, the features and capabilities should be the same. This feature also addresses the need to prevent different sources of control from interfering with one another by attempting to control the DMS simultaneously.

Obviously the impacts on multiple users/developer/vendors are significant. A well written user need is the reliable way to achieve what you desire or need.

Extract User Needs from other Relevant Standards

NTCIP

National Transportation Communications for Intelligent Transportation System Protocol or

NTCIP is a protocol that has a specific set of handshaking rules, procedures, and conventions defining the format, sequence, and timing of data transmissions between devices that must be accepted and used to understand each other. The NTCIP family of standards includes both center-to-field communications for devices and center-to-center communications among centers.

Please note that the NTCIP does NOT control a device directly (explicitly), but it does it by rather using commands from the SNMP (GET, SET), it tells a device what the management station wants it, the device to do (implicitly).

Management System (Station)

A computer or computer network that can interact with the device via the defined interface to realize the features of the device, such as a traffic management system referenced in NTCIP device standards.

Management Information Base (MIB)

Set of object definitions that define the attributes, properties, and controllable features of devices on a network, which can be remotely monitored, configured, and controlled. The information is provided in a format called Abstract Syntax Notation 1 (ASN.1), which is an international standard for defining objects. An object is defined as shown in Figure 12.

(Extended Text Description: Text is placed in a box to illustrate structure of a CCTV object, with the following text:

Example of a CCTV Object - Learning Objective 5.

3.2.1 Maximum Number of Presets Paramater

rangeMaximumPreset OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION "A preset is the pre-specified position where a camera is pointed to a fixed point in space (includes positions for pan, tilt, and zoom). The maximumPreset is a number indicating the total number of possible preset positions supported by the device. A value of zero (0) identifies that the device does not support presets."
::= { cctvRange 1 }

Extended Text Description continued: The example is labeled with the following at the bottom of the text: Has unique ID, which points to ::= {cctvRange 1}. This object must be selected, which points to "mandatory." We infer from this description that user need is for N number of presets, say 4 as a Capability, which points to INTEGER (0..255) and "A value of zero (0)".)

Figure 12: An Object Defined

Conformance Groups

A conformance group is defined as a basic unit of conformance (NTCIP standard) and contains both mandatory and optional objects. Each NTCIP device standard completed without SEP content has a section on conformance groups. A Conformance Statement (in the form of a Table) lists required conformance groups to comply with subject device standard.

Example of a CG excerpted from the NTCIP 1205 standard for training purposes (courtesy of NEMA).

4.1.3 Motion Control Conformance Group

The Motion Control Conformance Group consists of objects that specify features within a CCTV. The conformance requirement for each object within the group is shown. Please refer to the Conformance Statement Table 4-2 for the conformance requirement for the group. The Motion Control Conformance Group shall consist of the following objects:

Object or Table Name	Reference	Conformance Requirement Within the group
presetGotoPosition	NTCIP 1205	mandatory
presetStorePosition	NTCIP 1205	mandatory
position Pan	NTCIP 1205	mandatory
positionTilt	NTCIP 1205	mandatory
positionZoomLens	NTCIP 1205	mandatory
positionFocusLens	NTCIP 1205	mandatory
positionlrisLens	NTCIP 1205	mandatory

Discovering User Needs from ConOps

As shown in Figure 13, a ConOPs contains the big picture. It has clues to practically everything a user may want to analyze; problem definition, stakeholders and their needs and priorities, and operational scenarios from agency mission and objectives.

(What should be done if a ConOps doesn't exist? - One must be developed, as a project concept). No project should be done without a ConOps plan.

(Extended Text Description: Discovering User Needs from a ConOps. Text is placed in box and shown in five vertical boxes, which read, from top to bottom: Current Situation or Problem, What are the Operational Scenarios? (with the box's background of yellow), Who are the Users?, Are there Regional Aspects?, Validation Strategy or Plan.)

Figure 13: Discovering User Needs from a ConOps

Process to Extract User Needs from a Standard

Figure 14 outlines a four step process; READ-RECOGNIZE-INFER-WRITE to extract and write user needs from the conformance groups

(Extended Text Description: Extracting User Needs from Device Standard without SEP Content. This slide outlines a four step process; READ-RECOGNIZE-INFER-WRITE to extract and write user needs from the conformance groups. A graphic is showing two rows and three columns arrangement. First column indicates Conformance group 1 at the top (Groping of Objects per Feature(s)/Function(s)) and Conformance Group n (Groping of Objects per Feature(s)/Function(s))at the bottom or second row. This represents READ process step. A box in the middle of the first row is called Recognize step (Each conformance group indicates a single (undocumented) user need (and one or more requirements)), and next box is INFER step (User needs can be inferred using conformance group(s) listing of objects). The fourth step, Write (Write User needs for feature(s)) is in second row last column.)

Figure 14: Process to Extract User Needs

(Note: MIB contains objects that represent a capability though a range of function; Conformance Group contains grouping of objects to support features/functions) [Readers are advised to consult only official copy of a standard published by an SDO and check details on date and version numbers]

Extracting a User Need from a Standard without SEP Content

(Extended Text Description: The title page of NTCIP 1205 CCTV standard is shown next to the text: Step-1: Read: Those Standards without SEP content do have MIB and conformance groups listed in documentation. They represent “functions” or user needs that are served by functions. [In this example, go to NTCIP 1205 CCTV Figure 15]. Check details. Step-2: Recognize: CGs have a collection of objects contained in MIB that match them to what you are looking for or purpose they serve. [Go to CG Table 4.2] Step-3: Infer: Infer from CGs Motion Control with MIB objects, a need to control pre-sets, also know that mandatory CG must be selected so, UN will be mandatory. The capacity (how many presets you need) is controlled by a range in an Object definition. User desiring interoperability will have to select same range support at minimum. )

Figure 15: NTCIP 1205 CCTV

3.2.1 Maximum Number of Presets Parameter

rangeMaximumPreset OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION "A preset is the pre-specified position where a camera is pointed to a fixed point in space (includes positions for pan, tilt, and zoom). The maximumPreset is a number indicating the total number of possible preset positions supported by the device. A value of zero (0) identifies that the device does not support presets."
::= { cctvRange 1 }

(Extended Text Description: Two tables are referencing each other. The first table's full content is below:

The Motion Control Conformance Group

Conformance Group	Reference	Conformance Requirement
Configuration	NTCIP 1201:1996	mandatory
Database Management	NTCIP 1201:1996, Amendment 1	optional
Time Management	NTCIP 1201:1996, Amendment 1	optional
CCTV Configuration	NTCIP 1205	mandatory
Extended Functions	NTCIP 1205	optional
Motion Control	NTCIP 1205	optional
On-Screen Menu Control	NTCIP 1205	optional

The second table's full content is below:

User Need ID	User Need Title	User Need
UN 1.0	Need to control a remote CCTV device form traffic conditions for congestion management and events in the TMC region
UN 1.1	Need to Control a Remote CCTV Device	A center needs to remotely pre‐set control pan/tilt/zoom
UN 1.2	Need to Configure a Remote CCTV Device	A center needs to remotely pre‐set up to five pre‐set positions

Note: Each non-SEP standard may require you to infer multiple CGs and MIB objects

Extended Text Description continued: Arrows connect the two tables as follows: An arrow from CCTV Configuration in the first table connects to UN 1.2 in the second table. Arrow connects from Motion Control in the first table to UN 1.1 in the second table.)

Step-4: Write: Give a unique ID and title [write criteria stating that UN must be uniquely identifiable]; there is a rationale to provide for use of camera-to-monitor conditions an operational need UN 1.0, and a major desired capacity, to control CCTV (UN 1.1).

Using the above steps (READ-RECOGNIZE-INFER-WRITE) and prescribed Criteria discussed above a set of user needs are organized.

IEEE 1512 standard for Emergency Management System User Needs

In the previous example, we used CCTV device standard example from which it is possible to extract user needs. In this example, user needs are developed using criteria discussed earlier using a system standard.

Basis of development: We used operational user need-sharing incident information, which contributes to a better coordination resulting in a reduced response or incident duration (a high level objective of the agency)

(Extended Text Description: A table with the follow text has external arrows pointing to various column headers or cells. The full text of the table is as follows:

User Need ID	User Need Title	User Need
UN 1.0 Share Incident Information with Emergency Management Centers
UN 1.1	Share Incident Information with First Responders	EM Operators need to know about incidents to dispatch first responders immediately thereafter, resulting in improved incident response times thus saving lives.
UN 1.2	Share Incident Information with Secondary Responders	EM Operators need to know about incidents to dispatch secondary responders to incident support locations as soon as possible.
UN 1.3	Share Incident Information with HAZMAT and EMS Providers	EM Operators need to provide information on the nature of HAZMAT incidents, thus helping reduce fatalities of HAZMAT and EMS providers
UN 1.4	Share Incident Information during Large Scale Incidents	EM Operators need to coordinate traffic operations with TMCs for large scale incidents and with other EM Centers to improve evacuation safety and times of large area.

Extended Text Description continued: Labels outside the table point to the following items as follows. Arrows from Uniquely Identifiable point to the column headers User Need ID and User Need Title. An arrow from Major Desired Capability and an arrow from Solution Free point to EM Operators need to know about incidents to dispatch secondary responders to incident support locations as soon as possible. An Arrow from Captures Rationale points to EM Operators need to know about incidents to dispatch first responders immediately thereafter, resulting in improved incident response times thus saving lives.)

Extracting User Needs from Operational Scenarios

Understand Scenarios : Experiences have shown that for the right reasons, operations and maintenance users will view an incident from different perspectives. Operations staff such as first responders will focus on getting to the incident scene as quickly as possible, treating victims and traffic control, while maintenance users will focus on ensuring that response equipment is working properly and on repairing the roadway infrastructure. Yet how a system works for all of its users during all defined modes of operations and maintenance is a key determinant of success for system projects. Different and potentially conflicting views of system use will result in a system that only partially meets the user's expectations.

Operational scenarios describe operational activities, user interactions with the system, and help to identify one or more user needs. For example, a scenario might include the procedures on how public safety agencies make requests for action or how maintenance requests are monitored and made. Operational scenarios are used in the concept of operations to help visualize what is needed and to establish intent. User needs identified in one or more operational scenarios will then be written to capture the full intent. There are many ways that these scenarios unfold and can be documented that tell different stories from perspectives of different user classes over a variety of circumstances.

Why focus on operations? (pullout box)

"Because system users do not always view operations from the same perspective, nor do users always agree upon operations. In other words, users involved in the same operational activities will not always agree on what the system should do or how the system should work. For example, operations and maintenance users will view an incident from different perspectives.

Operations staff such as first responders will focus on getting to the incident scene as quickly as possible, treating victims and traffic control, while maintenance users will focus on ensuring that response equipment is working properly and on repairing the roadway infrastructure. Yet how a system works for all of its users during all defined modes of operations and maintenance is a key determinant of success for system projects. Different and potentially conflicting views of system use will result in a system that only partially meets the user's expectations. Operational scenarios describe operational activities, user interactions with the system, and help to identify one or more user needs. For example, a scenario might include the procedures on how public safety agencies make requests for action or how maintenance requests are monitored and made. Operational scenarios are used in the concept of operations to help visualize what is needed and to establish intent. User needs identified in one or more operational scenarios will then be written to capture the full intent." (Ref. IEEE 1512 Guide, page 23).

There are four basic elements to operational scenario development that may impact the user needs discovery process:

• Included User's Perspectives - Each user of the system is included to some degree within each scenario; this is typically done by generating a "story" written from the perspective of each class of user.
• Variety of User Classes - Incorporating many of the user classes related to the system is preferred in assuring system effectiveness (meeting the goals) and assuring stakeholder "buy in."
• Stress/Failure Scenarios - Such scenarios describe characteristics that are conceivable to cause the system great stress - even to push the system to the point of failure.
• Multiple Circumstances - More than one scenario with multiple associated sub-events is necessary to develop a rich enough picture and story to illustrate the full extent and capabilities of the system.

Example: Incident Management Operational Scenario

Non-SEP standards such as IEEE 1512 do not contain design content that support operational scenarios (needs). User can derive needs from underlying operational scenario. The example shows how one can go about developing pertinent user needs. It implies that sharing incident information is the need to carry out coordination (a rationale).

Overall the need of the TMC is to manage congestion and reduced response or incident duration (a high level objective of agency]. We can gather such context quickly. This leads us to infer specific user need-share information with other centers.

(Extended Text Description: Graphically designed pullout box with the text: Operational Scenario A TMC operator receives information on a traffic incident and creates an Incident report. Operator determines a list of centers who are affected, then begins to inform centers.... Transit.... EM. At some point motorists must be informed via DMS, maybe even the outside media....)

Operational Scenario Requiring Multiple Standards

Multiple stakeholders have realized the benefits of standards and ability to coordinate operations during events. Needs are met by more than one standard and we should be able to understand how to assemble user needs.

Need for Multiple Standards

In the above situation, we will be required to use more than one standard and both SEP-based and non-SEP standards, in which case we have to gather user needs adequately to reflect operational needs from multiple standards as shown in Figure 16.

NTCIP 1203 v2 DMS standard has made listing of user needs available from which one can select according to the project's needs. This is often referred to as the "mapping" or "selecting" process.

NTCIP 1202 v1 ASC and NTCIP 1205 CCTV standards have not documented user needs and therefore agencies will have to use the process to extract user needs as described above.

Example of Using a Multiple Standards Operational Scenario

Very often ITS systems are developed using multiple ITS standards. User will be required to include user needs from all relevant standards. For example, Figure 16 shows how various NTCIP enabled device standards together can support a complex operational situation, often involving more than one jurisdiction.

Operational scenario that may use multiple devices

In a situation where multiple centers operate in a region, centers are expected to collaborate and coordinate operations during event management, use of each other's devices is likely and such operational need will require use of mixed standards such as DMS, CCTV, ASC, ESS and others.

(Extended Text Description: This slide conveys that ITS systems are developed using multiple ITS standards and include user needs from all relevant standards. For example, the graphic presented here shows how various NTCIP enabled device standards together can support a complex operational situation, often involving more than one jurisdiction. There is a little map in the center with a CCTV and DMS with message and a traffic controller. It shows that three different devices are used. This requires three standards and title pages of these standards (Traffic Controller, CCTV, and DMS) reinforce that message. )

Figure 16: Operational Scenario Requiring Use of Multiple Standards

Module 202 has outlined a process for developing user needs when they do not already exist for non-SEP based standards such as NTCIP 1205 CCTV, NTCIP 1202 ASC.

Sources of Case Studies: Concept of Operations

• Metropolitan Transportation Management Center Concepts of Operations. Intelligent Transportation Systems. Report No FHWA-JPO-99-020. Oct. 1999.

http://ntl.bts.gov/lib/jpodocs/repts_te/10923.pdf

This document describes the backgrounds, summary descriptions, successful practices, lessons learned, issues, and future directions of eight TMCs. For the developer of a TMS Concept of Operations, function, capability, and overall scope and scale of various TMS systems are described in one document, providing a useful guide. Systems included: Boston Central Artery/Tunnel Integrated Project Control System; Toronto, Ontario Compass Downsview TMC; Long Island, New York INFROM; Detroit, Michigan Intelligent Transportation System Center; Milwaukee, Wisconsin MONITOR; Atlanta, Georgia NAViGAtor; Phoenix, Arizona TrailMaster; and Houston, Texas TranStar. It also discusses potential future system improvements.

• TMC Concepts of Operation: Implementation Guide. ITS Joint Program Office, Federal Highway Works Administration, December 1999.

http://tmcpfs.ops.fhwa.dot.gov/cfprojects/uploaded files/TMCConOpsImplmGuide.pdf

This document reviews the purpose behind developing a Concept of Operations document for regional TMCs. It demonstrates the importance and provides examples and resources as identified and utilized in several developing TMCs throughout the nation.

• Fowler, Thomas B. and Paul J. Gonzalez. Developing Functional Requirements for ITS Projects Report No FHWA-OP-02-047. April 2002.

http://ntl.bts.gov/lib/jpodocs/repts_te/13621.html - This document gives an overview of systems engineering and functional requirements. It illustrates the relationship between functional requirements and the National ITS Architecture and contains a description of the systems engineering life cycle in terms of the "V" diagram. This document also identifies the benefits and problems associated with developing functional requirements.

Students may find the following example of 911 ConOps/operational scenario documents useful in understanding how user needs are defined to meet operational needs in emergency management operations using 911 systems.

Example of ConOps/Operational Scenario for 911

Source: Concept of Operations, NG 911, ITS, USDOT

http://www.google.com/search?q=ng+911+operational+scenerios

The purpose of this document is to provide a Concept of Operations for the Next Generation 9-1-1 (NG9-1-1) System (or "system of systems"). The U.S. Department of Transportation (USDOT) understands that access to emergency services provided by 9-1-1 in today's world of evolving technology will ultimately occur within a broader array of interconnected networks comprehensively supporting emergency services?from public access to those services, to the facilitation of the services, to the delivery of the emergency information to dispatchers and first responders.

Scenarios are used here to illustrate the NG9-1-1 concept by describing key users' perspectives in different circumstances. Although the overall NG9-1-1 System is designed for use by every PSAP throughout the nation, the scenarios are not intended to be an exhaustive list or description of all NG9-1-1 access methods, technologies, or functionality, but rather an indication of how NG9-1-1 will change the fundamental landscape of emergency communications delivery.

Validate User Needs Tracing User Needs for a Device Standard Traceability

Each user need shall be traced to one or more functional requirements and each functional requirement shall be derived from at least one user need. This traceability is shown in the PRL for SEP based device standards, in conformance groups in standards without SEP content, and in NRTM (Needs to Requirements Traceability Matrix) in system standards.

Each user need shall be traced to one or more functional requirements and each functional requirement shall be derived from at least one user need. This traceability is shown in the PRL for SEP based device standards, in conformance groups in standards without SEP content and in NRTM (Needs to Requirements Traceability Matrix) in system standards.

Slide points to user need tracing by inferring in NTCIP device standards without SEP content. Here is an example statement.

Traceability for Device Standard

(Without SEP Content)

• Conformance Statement Table:
  • Used in Device standards without SEP Content
  • E.g. NTCIP 105 CCTV

Refer to Participant Supplement page xx

The following table shows how a Conformance Group is formed in NTCIP 1205 CCTV standard with mandatory/optional objects. Please note that all mandatory objects must be selected.

Object or Table Name	Reference	Conformance Requirement Within the group
presetGotoPosition	NTCIP 1205	mandatory
presetStorePosition	NTCIP 1205	mandatory
positionPan	NTCIP 1205	mandatory
positionTilt	NTCIP 1205	mandatory
positionZoomLens	NTCIP 1205	mandatory
positionFocusLens	NTCIP 1205	mandatory
positionlrisLens	NTCIP 1205	mandatory

Verification & Validation (V&V)

The purpose of V&V is to help the development team build quality into the system interface life cycle. System verification and validation activities are very similar, but they address different issues. Verification addresses whether the system, its elements, its interfaces, and incremental work products satisfy their requirements. Validation confirms that the system, as built (or as it will be built), will satisfy the user's needs. Verification ensures the conformance to those requirements, and validation ensures the requirements and the system implementation provide the right solution to the customer⁷ problem. In other words, verification ensures that "you built it right;" while validation ensures that "you built the right thing." (Ref. INCOSE)

The owning agency prepares a validation strategy or plan during the ConOps stage. A Validation process is tied to user needs and it is viewed from the owner's/stakeholders' perspective. [Did the System perform as intended? Or Was the Right System built?]. Similarly, a verification process is viewed from the development team's perspective and is tied to requirements. [Was the System BUILT Right?]. Together they form a V&V plan as part of the systems engineering management plan (SEMP). This is accomplished at each phase of the life cycle process. That is the goal of SEP. This V&V allows identification and correction of defects in the process when it is most cost-effective to do so.

References

Systems Engineering Guides

1. Systems Engineering Guidebook for ITS FHWA-Caltrans, v3.0, 2009 https://www.fhwa.dot.gov/cadiv/segb/files/segbversion3.pdf
2. Systems Engineering for Intelligent Transportation Systems, FHWA, 2007 http://ops.fhwa.dot.gov/publications/seitsguide/index.htm
3. INCOSE Systems Engineering Handbook, v3.2.1 2010 http://www.incose.org/ProductsPubs/incosestore.aspx

National ITS Architecture Guides Discusses User Services and Subsystems

1. National ITS Architecture v6.1, 2009, http://www.iteris.com/itsarch/index.htm
2. Regional ITS Architecture, http://www.ops.fhwa.dot.gov/its arch imp/guidance.htm

Management & Operations (M&O) Documents Discuss User-Operational Needs (Scenarios)

3. Management and Operations of Intelligent Transportation Systems, an ITE Information Report, 2009. www.ite.org/emodules/scriptcontent/Orders/ProductDetail.cfm?pc=IR-125-E.
4. User Needs Assessment, Deschutes County ITS Plan, Oregon Department of Transportation, March 2005. www.oregon.gov/ODOT/HWY/ITS/PDFs/Bend/FinalReport/Chapter2UserNeedsAssessmentFINAL.pdf?ga=t
5. Sharing Information between Public Safety and Transportation Agencies for Traffic Incident Management, NCHRP Report 520, TRB, 2004. http://www.trb.org/Main/Home.aspx

ITS Standards Guides that Cover Topics on User Needs and SEP

1. NTCIP Guide, Information Report 9001, ntcip.org
2. Guide for Implementing IEEE 1512 Using a Systems Engineering Process Contents, IEEE Press, 2008, page 31-41. www.ieee.org

Useful Current Information on ITS Standards Available at these USDOT Websites

3. USDOT, RITA, ITS- JPO, http://www.its.dot.gov/index.htm (Fact sheets)
4. USDOT, FHWA, Operations, http://ops.fhwa.dot.gov
5. USDOT Standards Program, https://www.standards.its.dot.gov/

Standards Development Organizations (SDOs)

1. TMDD, www.ite.org/standards/tmdd/
2. NTCIP, www.ntcip.org/library/documents
3. ATC Controller, http://www.ite.org/standards/atc/
4. Emergency Management, www.ieee.org