Module 2
Printer-friendly version of this page
Module 2 Presentation
The accompanying presentation
ITS ePrimer
Module 2: Systems Engineering
Authored by Bruce Eisenhart, Vice President of Operations, Consensus Systems
Technologies (ConSysTec), Centreville, VA, USA
Table of Contents
Purpose
The purpose of this module is to provide an overview of the systems engineering process (SEP)
that is central to the development of intelligent transportation systems (ITS) projects. The
SEP is an interdisciplinary, structured process that meets the needs of the users, providers,
and other stakeholders while maintaining the project schedule and budget. This module also
provides an overview of related topics, including the National ITS Architecture and other
architectures, the ITS Standards Program, and the use of the SEP for planning and deploying
ITS projects.
Back to top
Objectives
This module has the following objectives:
- Provide an introduction to the SEP and describe how to apply it to the development of ITS
projects.
- Provide an overview of ITS architectures.
- Review the role of ITS standards in the development process.
- Discuss the Architecture and Standards Rule and the role of systems engineering and ITS architecture
in addressing the requirements of the rule.
- Identify how the SEP supports transportation planning.
Back to top
Introduction
Systems engineering offers a framework for developing complex systems used in engineering
projects. In a retrospective on the National Aeronautics and Space Administration's (NASA)
Project Apollo, systems engineering is credited with the project's success in the 1960s. "NASA
personnel employed the 'program management' concept that centralized authority and emphasized
systems engineering. The systems management of the program was critical to Apollo's success.
Understanding the management of complex structures for the successful completion of a multifarious
task was a critical outgrowth of the Apollo effort."1
Systems engineering provides a structure for deriving order from chaos, as demonstrated in
this amusing video:
www.youtube.com/watch?v=t0tGd5igKZM&list=TL2cvF2Qi7Bc4. This module provides an
introduction to the SEP and its use in the planning and development of ITS projects.
The International Council on Systems Engineering (INCOSE) gives the following short definition
of the field:
Systems engineering is an interdisciplinary approach and means to enable the realization of
successful systems.2
The term interdisciplinary is a fundamental concept in systems engineering. To successfully
develop a system requires the application of basic engineering discipline, management discipline,
and expertise in the application domain of the system. In the case of ITS, that application
domain is transportation engineering. The intersection of these disciplines is the realm of
systems engineering.
Figure 1. Systems Engineering Improvement
![A venn diagram with three intersecting circles. The top circle has the word "Engineering." The lower left circle has the words "Application Domain Expertise." The lower right circle has the word "Management." There is an arrow pointing to the area of overlap from all three circles and the words "Systems Engineering" in the upper right corner at the end of the arrow.](images/ep2fig01.jpg)
Source: U.S. Department of Transportation's Research and Innovative Technology Administration
(RITA), National ITS Architecture SE Process Improvement Presentation.
The goal of systems engineering is to successfully develop a system. Although there are many
measures of success, the goal is to create a quality system that is developed on budget and
on schedule and meets the technical requirements and expectation of the stakeholders who will
use or maintain the system.
Systems engineering as an idea dates back to the 1930s. The basic principles and processes
were developed in the 1940s and 1950s to support the development of increasingly complex military
systems. In the past 20 years, the use of the SEP in more generalized systems development
has been codified in a set of international standards (see the Additional Resources section).
In the case of ITS project development, the use of standards is relevant because the systems
aspect of ITS is increasingly complex, combining hardware, software, and communications to
provide transportation services.
The U.S. Department of Transportation (USDOT) recognized the potential benefits of the systems
engineering approach for ITS projects. The Federal Highway Administration (FHWA) Rule 940
and Federal Transit Administration (FTA) Policy,3 which
were enacted in 2001, require that a systems engineering analysis (SEA) be performed for ITS
projects that use funds from the Highway Trust Fund, including the Mass Transit Account. In
addition, the FHWA rule requires the development of a regional ITS architecture, defined by
the rule as "a framework for ensuring institutional agreement and technical integration
for the implementation of ITS projects in a particular region." This module expands on
both of these topics.
Key Concepts of the SEP
The systems engineering process is defined by a set of key concepts that will be further developed
in the step-by-step review of the process below. These key concepts involve the following
approaches:
- Consider the entire life cycle of a system. The SEP does not just concern itself with the
timeline of a project's start to completion. The SEP considers planning activities that occur
before the project starts and covers steps following initial deployment, including operations
and maintenance and system retirement or replacement.
- Focus on stakeholder involvement. The SEP involves stakeholders in all steps in the process,
from identifying the needs through validating the system. Stakeholder involvement is a key
part of the successful application of the SEP.
- Understand the problem to be addressed. The SEP views the problem from the stakeholders' point
of view by defining needs from the user's perspective.
- Address project risks as early as possible. The earlier a risk is identified and resolved,
the less the impact will be on the project's cost or schedule.
- Clearly document the process and the output of each step. Stakeholders must review and document
the outputs of each step in the process and make informed decisions about proceeding to the
next step.
- Tailor the SEP to fit the needs of the project. The SEP is scalable based on the size, complexity,
and risk of a project; it is not a one-size-fits-all process.
Benefits and Costs of Using the SEP
The systems engineering process can improve the quality of the products created by an ITS
project, reduce the risk of schedule and cost overruns, and increase the likelihood that the
implementation will meet the user's needs. Other benefits include improved stakeholder participation
and better documentation of not only the end products but also the development process itself.
Anyone who has tried to pick up a project midstream after a key person unexpectedly left will
understand the benefit of good documentation during the development effort. In addition, the
benefits of using the SEP can continue throughout the life cycle of the system, reducing operational
costs by implementing the product correctly the first time and also reducing the need for
later modifications.
The SEP provides a number of benefits as listed above, but these benefits do come with some
reapportioning of development costs. In general, the use of the SEP will result in more effort
expended at the early stages of the development process—those steps leading up to detailed
design. Additional costs may also be incurred during the systematic verification described
below. But these planned costs can significantly reduce the likelihood of cost overruns resulting
from redoing work to address problems later in the development process. The amount of effort
spent on the SEP depends on the size, complexity, and amount of risk associated with the project.
Studies conducted in the broader arena of systems development have found that a systems engineering
effort typically represents about 10 percent of the overall project cost. In general, the
greater the size, complexity, or risk associated with the project, the greater the likelihood
that the effort associated with the SEP will pay off in achieving the benefits listed above.
Back to top
Overview of the Systems Engineering Process
The following description of the systems engineering process for ITS is based on two key documents
that have been developed by FHWA: Systems Engineering for ITS—An Introduction for Transportation
Professionals,4 and Systems Engineering Guidebook
for ITS.5
Many different process models have been developed over the years that specify a series of
steps that make up the systems engineering approach. The V process model illustrated below
has gained wide acceptance in the standards community and is the model chosen by USDOT in
the two references above. One of the key reasons for the choice of this model is that it illustrates
some key SEP principles about the relationship of the early phases of project development
to the results of the project. The following discussion will walk through each step in the
process. This V process model is taken from the Systems Engineering Guidebook, which
has a hyperlinked website with considerable additional detail about each step in the process.
Hyperlinks to the relevant section of the guidebook are accessed by clicking on the process
step icon. As the discussion proceeds from one step to the next, the steps, particularly on
the left side of the V, will usually be iterative in nature.
Figure 2. V Process Model
![This is an image that describes the V model of the Systems Engineering Process Life Cycle. Please see the Extended Text Description below.](images/ep2fig02.jpg)
(Extended Text Description: This is an image that describes the V model of the Systems
Engineering Process Life Cycle. The left side of the V represents concept development and
the decomposition and definition of requirements into function and physical entities that
can be architected, designed, and developed. The right side of the V represents integration
and re-composition of these entities (including appropriate testing to verify that they satisfy
the requirements) and their ultimate transition into the field, where they are operated and
maintained. Each step in the life cycle is delineated by a decision gate. Starting from the
left wing of the V and working down the V across the life cycle time line, it is broken into
Regional Architecture, Concept Exploration, Systems Engineering Management Plan Framework,
Concept of Operations, System Requirements, Subsystem Requirements Project Arch (HLD), Component
Level Design and finally Software Coding Hardware Fabrication at the bottom of the V. Working
up the V on the right side includes Unit Testing, Subsystem Integration & Verification,
System Integration & Verification, System Validation, Operations & Maintenance, Changes
& Upgrades and finally Retirement Replacement. There is a pullout box on the left side
labeled Cost Cutting Activities with the listed elements underneath: Stakeholder Involvement,
Elicitation, Project Management, Risk Management, Metrics, Configuration Management, Interface
Management, Process Improvement, Decision Gates, Trade Studies, Technical Reviews, Traceability.)
Regional ITS Architecture
The first step in the process is to consider how the system
to be developed is described in the regional ITS architecture, which represents a plan for
the deployment of ITS in the region. As a result of the requirements of 23
CFR 940 (discussed in the ITS Architecture section later in this module), over
400 regional ITS architectures have been developed throughout the United States. These regional
architectures identify the stakeholders in the region, the systems the region has implemented
(or plans to implement), and the ITS services currently deployed or planned for deployment
in the region. As part of these regional ITS architectures, the ITS projects planned for the
region are described, and in most architectures the ITS projects are mapped to some portion
of the architecture. The purpose of this initial step is to put a project into the context
of the region's overall ITS plan.
Concept Exploration
The concept exploration step in the process is used
to perform any initial feasibility analysis, benefits analysis, or needs assessment required
to facilitate the planning of the system. This results in a business case and specific cost-benefit
analyses for alternative project concepts. The output of this step can be a definition of
the problem space; key technical metrics of the system; and refinements to the needs, goals,
objectives, and vision. This step provides the justification for the project to move forward
into development. The activity may result in combining or dividing candidate projects based
on the best cost-benefit analysis. This step has the first of many "decision gates,"
which show as the light blue ovals between steps in the V diagram. These decision gates represent
key points in the process where a specific decision is made, based on documented outputs or
possibly technical reviews, to advance to the next step in the process. The decision gate
in this step is to gain management support and approval for the project to move into the programming
of funds phase of the process (where funds are allocated for the development of the system).
This step is often undertaken when some significant new initiative or system is envisioned.
In the case of many ITS projects, particularly those that involve upgrades to existing systems,
this step may not be needed or might be abbreviated.
Systems Engineering Management Planning
Each project that moves forward into development
must be planned. Planning takes place in two parts. In part one, the system's owner develops
a set of master plans and schedules that identify what plans are needed and, at a higher organizational
level, the schedule for implementation of the project. This part becomes the framework for
what is developed in part two. The plans are completed during the following steps in the SEP
(from the concept of operations to detailed design). These plans, once approved by the system's
owner, become the control documents for completion of the development and implementation of
the project. The key output of this step is the Systems Engineering Management Plan (SEMP)
document.
The SEMP is an extension of the classical project management plan, but it controls the technical
development of an ITS project. It is the top-level plan for managing the systems engineering
effort, defining how the systems engineering portion of the project will be organized, structured,
and conducted and how the total engineering process will be controlled to provide a product
that fulfills customer requirements. This SEMP is the first of a series of documents that
are created as part of the SEP to document the project and the process under which it is being
developed. These documents will be described in each of the subsequent steps and represent
one of the key concepts of the SEP—that is, clearly documenting the process as well
as the outputs of each step of the process.
The SEMP identifies all the required documents and plans that will need to be developed throughout
the project. The initial version of the SEMP (sometimes referred to as the SEMP Framework)
is developed at the beginning of the project and is usually not a large or complex document,
because it is basically an outline of what is to come. Although the SEMP is a fairly new concept
in ITS project development, it is an extremely important tool for managing the technical side
of the project. The SEMP is intended to guide the agency or owner of the project in the management
of the project. It is not meant to be a document written by the contractors on a project for
their own internal management; rather it is the primary tool for the project owner to monitor
contractor work and progress.
An excellent template for creation of the SEMP (as well as examples of SEMPs created on actual
projects) is given in the Systems Engineering Guidebook for ITS. The guidebook contains
templates and examples for all of the systems engineering documentation discussed in the steps
below.
Concept of Operations
The purpose of the concept of operations (ConOps)
step is to clearly convey a high-level view of the system to be developed that each stakeholder
can understand. This foundation document frames the overall system and sets the technical
course for the project. A good concept of operations answers who, what, where, when, why,
and how questions about the system from the viewpoint of each stakeholder, as shown in the
figure.
Figure 3. Concept of Operations
![Figure 3. Concept of Operations. Please see the Extended Text Description below.](images/ep2fig03.jpg)
(Extended Text Description: This graphic has a series of images including icons of
people standing in a row. In the upper left corner, there is a banded circle graphic with
an outer dark blue band with the words "Support Environment." The lighter blue middle
band has the words "Operational Environment." The inner white circle has the word
"System" at the top, then a series of interconnecting lines. A circle connects all
the text elements (starting at the top left and going counter-clockwise): Hardware, People,
Date, Facilities, Procedures and Software. There is a list of question words off the right
lower edge of the outer circle: What?, Where?, When?, Who?, Why? and How? To the right of
the circular graphic, there are words "Facilities Communication Among Stakeholders and
Interdisciplinary Team Members." Under these words are two rows of icons that represent
people with viewpoints. The first row of four icons are labeled Users, Operators, Maintainers
and Customers. The second row of five icons are labeled Managers, System Engineers/Architects,
Developers, Testers and Regulators.)
Source: ANSI/AIAA
G-043A-2012.6 (Reprinted with permission from the American
Institute of Aeronautics and Astronautics.)
The ConOps is one of the first key outputs of the SEP and forms the basis for the definition
of requirements in the next step. The ConOps stage of the SEP is used to ensure that the system
developers' documentation shows a thorough understanding of the users' needs.
This step embodies several of the key concepts of the SEP, which include (a) engaging the
stakeholders, whose input is key to the development of the ConOps; (b) focusing on the problem
and on user needs; and (c) beginning with the end in mind, that is, defining key system outputs
as well as key operations and maintenance considerations.
To accomplish these steps, the ConOps documents the way the envisioned system is to operate
and how the envisioned system will meet the needs and expectations of the stakeholders. At
this step the SEP V diagram shows the first of several arrows leading from the left side of
the V (the decomposition and definition side) to the right side of the V (the integration
side), indicating the creation of a System Validation Strategy or System Validation Plan.
The ConOps defines the user needs, and at this step, the SEP owners may create a plan for
the validation of those needs, which will be used to support the system validation step described
below.
System Requirements
One of the most important attributes of
a successful project is a clear statement of requirements that meet the stakeholders' needs.
EIA-632 defines a requirement as
"something that governs what, how well, and under what conditions a product will achieve
a given purpose."7 This is a good definition because
it touches on the different types of requirements that must be defined for a project. Functional
requirements define what the system must do, performance requirements define how
well the system must perform its functions, and a variety of nonfunctional requirements
define under what conditions the system must operate.
The requirements step is an important one. Every ITS project should have a documented set
of requirements that are approved and for which a baseline is established (using a configuration
management process, which is discussed later under cross-cutting activities). Of course, this
step does not mean that a new requirements specification must be written from scratch for
every project. Projects that enhance or extend an existing system may build on existing system
requirements, or in the case of field device deployments, the project may operate using agency
specifications for the device.
Involving stakeholders in requirements development is important because they are the foremost
experts concerning what functions the system should have, how well the system must perform
its functions, and under what conditions the system must operate. The job of the systems engineer
is to elicit this information from the stakeholders. The result of this step should be a documented
set of requirements that completely address all of the user needs defined in the ConOps. As
shown in the V diagram, the system requirements form the basis for creating a System Verification
Plan that defines a verification case and method for each requirement. The system requirements
also must trace back to the user needs in order to show that all the needs are being addressed.
Traceability is a key concept in the SEP and is discussed in more detail later.
Subsystem Requirements in High-Level Design
The systems engineering approach defines
the problem before defining the solution. The previous steps in the V diagram have all focused
primarily on defining the problem to be solved. The high-level design step is the first step
in defining the project solution. It is an important transitional step that links the requirements
that were defined in the previous step with a design framework that will be built upon and
implemented in the following steps.8
The key outputs of the high-level design step are to break the system into subsystems and
to define the key interfaces between the subsystems. One way to do this is to create a project-level
architecture for the system. This can be an ITS project architecture (as described later in
the section on ITS architectures) or it could be a more detailed view of major components
(meaning the subsystems or an additional level of decomposition) and communication links.
At this step, the process identifies the ITS standards to support the interfaces that have
been defined. (The topic of ITS standards is covered later in the module.)
Depending on the complexity of the system, requirements for each subsystem element may be
defined and documented the same way as the system-level requirements. This step usually concludes
with an important control gate review, sometimes called the preliminary design review.
Detailed Design
At the detailed design step (sometimes
referred to as component design), the development team defines how the system will be built.
At this step the focus is on how to define the system. To perform this step, each
subsystem is further defined by components of hardware, software, database elements, firmware,
and so on. For these components, detailed design specialists in the respective fields create
documentation (build-to specifications) that will be used to build or procure the individual
components. If custom hardware or software needs to be developed, specialists perform the
detailed design of these components or software modules. In practice, most of the hardware
used in ITS projects is existing vendor offerings, so little if any hardware design is required.
Development of custom software is more common, but even here most ITS projects use vendor
software that may be customized for the specific project. This detailed design includes the
detailed definition of interfaces, which includes the definition of the communications to
be used to link the various hardware subsystems or components in the project. Included in
the interface definition and communications design is the detailed customization of the ITS
standards to be used (see the later discussion of the ITS standards for more on this step).
The control gate used for this step is sometimes called the critical design review. An additional
output of this step is the creation of unit plans that will be used to verify that the units
meet the detailed design specification.
Hardware and Software Procurement or Development
This stage involves hardware fabrication, software
coding, database implementation, and the procurement and configuration of existing vendor
products. The system's owner and stakeholders monitor this process with planned periodic reviews,
for example, code walkthroughs and technical review meetings. Concurrent with this effort,
unit testing procedures are developed that will be used to demonstrate how the products meet
the detailed design. At the completion of this stage, the developed products are ready for
unit testing.
Unit Testing
The components from the hardware and software development
are verified in accordance with the unit verification plan. The purpose of unit testing is
to verify that the delivered components match the documented detailed design. In the case
of the procurement of existing vendor hardware or software, unit testing would take the form
of acceptance tests that are performed to show that the hardware and software meet the requirements
that have been allocated to each unit.
Subsystem Integration and Verification
At this step, the components are integrated
and verified at the subsystem level; that is, the subsystem meets its specified requirements.
The first level of verification is done in accordance with the verification plan and is carried
out in accordance with the verification procedures (step-by-step method for carrying out the
verification) developed in this stage. Prior to the actual verification, a test readiness
review may be held to determine that the subsystems are ready for verification. When it has
been determined that verification can proceed, the subsystems are then verified. When the
integration and verification are completed, the next level of subsystem is integrated and
verified in the same manner. This process continues until all subsystems are integrated and
verified.
One of the key features of subsystem integration and verification is its iterative nature.
Normally a project will integrate a portion of the system, verify it through testing, then
integrate some more of the system, verify it through testing, and so on until the complete
system is put together. This process would be true for a complex system. However, projects
with few components or subsystems will be able to quickly proceed through this step, illustrating
again a key point of the SEP—that it needs to be tailored to each project; the process
is not one size fits all.
System Integration and Verification
In systems engineering, there is a distinction
between verification and validation. Verification confirms that a product meets its specified
requirements. Validation confirms that the product fulfills its intended use. In other words,
verification ensures that you built the product right; validation ensures that you built the
right product. This is an important distinction, because there are lots of examples of well-engineered
products that met all of their requirements but ultimately failed to serve their intended
purpose.
System verification is often done in two parts. The first part is done under a controlled
environment (sometimes called a factory test). The second part is done within the environment
in which the system is intended to operate (sometimes called onsite testing and verification)
after initial system deployment. At this stage, the system is verified in accordance with
the verification plan developed as part of the system-level requirements performed early in
the development.
Initial System Deployment and System Validation
During deployment, the project development team installs the ITS in the operational environment
and transfers its operation to the organization that will own and operate the system. The
transfer includes support equipment, documentation, operator training, and other enabling
products that support ongoing system operation and maintenance. Acceptance tests are performed
as part of this step to confirm that the system performs as intended in the operational environment
before control is transferred. This step may take several weeks to complete to ensure that
the system operates satisfactorily in the long term. This is sometimes called a system burn-in.
Many system issues surface when the system is operating in the real-world environment for
an extended period of time.
System Validation
After the ITS has passed system verification and is
installed in the operational environment, validation tests are often run. Using the validation
plan developed earlier, the system development team or the system owner or operator performs
tests to determine if the deployed system meets the original needs identified in the concept
of operations. The State DOT, a regional agency, or another entity also may choose to perform
the tests. As a result of validation, new needs and requirements may be identified. This evaluation
sets the stage for the next phase of the system.
Operations and Maintenance
After the initial deployment and system
acceptance, the system moves into the Operations & Maintenance phase. In this phase the
system will carry out the intended operations for which it was designed. During this phase,
routine maintenance is performed as well as staff training. This phase is the longest phase,
extending through the evolution of the system and ending when the system is retired or replaced.
This phase may continue for decades. It is important that there are adequate resources to
carry out the needed Operations & Maintenance activities; otherwise, the life of the system
could be significantly shortened due to neglect."9
Changes and Upgrades
Once a system is in operation, it will still undergo
various changes and upgrades. These changes and upgrades can be addressed by going back to
the relevant steps of the V diagram and updating the outputs as required. Using the V process
for changes and upgrades will help maintain system integrity (synchronization between the
system components and supporting documentation). When this approach is used, the systems engineering
documentation produced in the original development can be updated to include the changes or
upgrades. One of the outputs of the SEP is an accurate and complete set of documentation,
which is extremely important to successful performance of this step. Depending on the nature
of the changes and upgrades, the V process used may be an abbreviated one (e.g., no changes
are needed to the ConOps, and only minor changes are needed to the requirements).
Retirement or Replacement
Eventually, every ITS will be retired or replaced
for a variety of reasons. The system may no longer meet agency needs, or continuing its operation
may not be cost-effective. Key system elements may be obsolete so itcan no longer be maintained.
Whatever the reason, the system owner will need to plan for its retirement or replacement.
The next step may be to perform a study to assess the costs and benefits of retirement or
replacement of the system. From a process viewpoint, this is equivalent to going back to the
concept exploration step and revisiting the business case for the system. In a fitting symmetry
to the V diagram, this final step is a planning step that can lead back to the beginning of
a new project—a system replacement.
Back to top
Cross-Cutting Activities
In addition to the steps previously covered, a number of cross-cutting activities are essential
to a successful SEP. The term cross-cutting is used because these activities are
not associated with a single step in the process but instead cut across many (or all) of the
steps. The following are a few of the cross-cutting activities that occur when using systems
engineering to develop almost any system.
Project Management
Project management is the process by
which cost, scheduling, and resources are managed to successfully complete a project. It is
a separate discipline that has its own defined process, along with a considerable body of
knowledge and standards. The application of the project management process is essential to
the successful completion of ITS projects. As such, project management and systems engineering
work hand in hand during project development. Project management practices provide a supportive
environment for the various development activities. The process provides the needed resources,
then monitors and controls costs and schedules. It also communicates the project's status
between and across the development team members, the system owner, and stakeholders.10 The system owner or agency has a vested interest in
making sure that the development team (usually a contractor team) follows good project management
practices, and they can require key outputs, such as the project management plan and project
status reporting, as part of the contract deliverables.
Risk Management
Risk management is the identification
and control of risks associated with the development effort. The goal of risk management is
to identify potential problems before they occur, plan for their occurrence, and monitor the
system development so that action can be taken early to prevent their occurrence. Identifying
risks early is one of the key concepts of the SEP.
Risk management includes the following general steps:
- Risk identification. The objective of the risk identification step is to identify early on
the key risks to project success. This will require the systems engineers, project management,
and stakeholders to brainstorm where the risks may lie in any particular project. The key
risk areas are technical aspects, cost, and schedule. In addition, risk identification should
consider potential risks associated with the following:
- Jurisdiction. Does the lead agency have jurisdiction or are there other responsible agencies?
- Software. Is there existing and proven software that can be used?
- Interfaces. Are new interfaces required or can a project rely on existing interfaces?
- Requirements and procedures. Are these well defined and documented?
- Experience. Does the staff have the necessary experience to procure, implement, and operate
the project?
- Risk analysis and prioritization. Once risks have been identified, the next step in the process
is to analyze and prioritize these risks. To do this, the developers need to answer three
basic questions:
- What will the impacts be if the risk does occur?
- How severe will this impact be?
- How likely is it that the risk will occur?
- Risk mitigation. For each risk identified, a plan needs to address the risk impacts should
they occur.
- Risk monitoring. Finally a risk mitigation strategy is needed for monitoring risks so that
the development team will be aware if the risks do in fact occur.
A risk management plan is usually developed at the beginning of the project (and is often
included in the SEMP). However the plan should be reviewed and updated on a regular basis
throughout the project to identify new risks and to assess whether the existing risks are
occurring. One of the common mistakes made when executing projects is to create a risk management
plan and not review and update it as the project proceeds.
Project Metrics
Project metrics are measures that are
used to track and monitor the project and the expected technical performance of the systems
development effort. The identification and monitoring of metrics allow the team to determine
if the project is on track, both programmatically and technically. Programmatic metrics might
be simple budget and schedule status. Technical metrics could involve measuring the number
of requirements defined or the number of requirements changed over a period of time. These
metrics are a key part of the project management process.
Configuration Management
Configuration management is defined as
"a management process for establishing and maintaining consistency of a product's performance,
functional, and physical attributes with its requirements, design and operational information
throughout its life."11 More than just defining
the current state of a system, configuration management involves managing changes that are
made to the system throughout its life.
USDOT provides the following definition: "Configuration management is the process that
supports the establishment of system integrity (the documentation matches the functional and
physical attributes of the system) and maintains this integrity throughout the life of the
system (synchronizes changes to the system with its documentation)."12
Configuration management consists of several key aspects:
- Configuration management planning—defining the configuration management process to be
used on the project. This plan is usually contained as a section of the SEMP.
- Configuration identification—identifying what items (i.e., documentation, hardware,
and software) will constitute the "baseline" to be tracked as part of the official
configuration of the system.
- Change management—defining the process used to incorporate changes to the baseline,
including how and when changes are made.
- Status accounting—keeping track of the current status and any changes in process for
each item of the baseline.
On any project, configuration management as a formal process commences when the first documentation
is developed and continues as the project moves from one step to another in the SEP. Documentation
is a part of the baseline and, once created, is subject to the change management process as
defined.
Traceability
Traceability is a key concept of the
SEP that ensures that the different outputs of the process properly relate to each other.
Traceability centers on the requirements developed for the project and how they relate to
other outputs of the project. Each need in the ConOps must trace to a requirement in the system
requirements document. If subsystem requirements are defined, then these must trace to system
requirements. The requirements must also trace to verification cases. If design specifications
are created, they need to trace back to the system requirements and forward (through test
plans) to the verification that is done. As described above, traceability goes both backward
(from requirements to needs) and forward (from requirements to specifications to verification.
Traceability is the key concept in the SEP that ensures that the system that is implemented
at the end of the project is directly connected with the user needs that were identified at
the beginning of the project.
Back to top
Related Topics
The following sections discuss a series of topics, including Federal regulations that are
relevant to the use of the SEP in the development of ITS projects.
ITS Architecture
ITS architecture is a key component of the first step of the V process model. An ITS architecture
is a framework for describing ITS-related transportation services. Three levels of ITS architecture
are relevant to any discussion of the systems engineering process: the National ITS Architecture,
regional ITS architectures, and ITS project architectures. Each of these types of architecture
is discussed below.
National ITS Architecture
The National ITS Architecture provides a common framework for planning, defining, and integrating
intelligent transportation systems. It is a mature product that reflects the contributions
of a broad cross-section of the ITS community (transportation practitioners, systems engineers,
system developers, technology specialists, consultants, and so forth).
The architecture defines the following elements:
- The functions (e.g., gathering traffic information or requesting a route) that are required
for ITS
- The physical entities or subsystems where these functions reside (e.g., in the field or the
vehicle)
- The information flows and data flows that connect these functions and physical subsystems
into an integrated system
§ 940.9 Regional ITS Architecture.
The regional ITS architecture shall include, at a minimum, the following:
(1) A description of the region;
(2) Identification of participating agencies and other stakeholders;
(3) An operational concept that identifies the roles and responsibilities of participating
agencies and stakeholders in the operation and implementation of the systems included in the
regional ITS architecture;
(4) Any agreements (existing or new) required for operations, including at a minimum those
affecting ITS project interoperability, utilization of ITS related standards, and the operation
of the projects identified in the regional
ITS architecture;
(5) System functional requirements;
(6) Interface requirements and information exchanges with planned and existing systems and
subsystems (for example, subsystems and architecture flows as defined in the
National ITS Architecture);
(7) Identification of ITS standards supporting regional and national interoperability; and
(8) The sequence of projects required for implementation.
Source: Rule 23 CFR 940.
The National ITS Architecture is maintained and updated by USDOT in collaboration with ITS
stakeholders. The first version of the National ITS Architecture was released in June 1996.
The latest update, Version 7.0, was released by USDOT in January 2012 (www.iteris.com/itsarch/index.htm).
The National ITS Architecture is comprised of three architectural layers: Institutional, Transportation,
and Communications:
The Institutional Layer includes the institutions, policies, funding mechanisms, and processes
that are required for effective implementation, operation, and maintenance of an intelligent
transportation system... The Transportation Layer is where the transportation solutions are
defined in terms of the subsystems and interfaces and the underlying functionality and data
definitions that are required for each transportation service. This layer is the heart of
the National ITS Architecture. The Communications Layer provides for the accurate and timely
exchange of information between systems to support the transportation solutions.
(Source:
www.iteris.com/itsarch/html/archlayers/archlayers.htm.)
The layer of the National ITS Architecture most relevant to this discussion of systems engineering
is the transportation layer, in which a logical (or function-based) architecture and a physical
(or systems- and interconnections-based) architecture are defined. The top-level interconnect
diagram of the physical architecture, which identifies the 22 subsystems of the architecture
and the types of interconnects, is shown below. The physical architecture defines the information
that flows between the key subsystems involved in delivering ITS services. These ITS services
are described by a set of service packages that define the portion of the overall architecture
required to provide a specific service (e.g., Traffic Incident Management). The overall pieces
of the National ITS Architecture are more numerous and interconnected than described here.
(For a more detailed view of the National ITS Architecture, refer to the website:
www.iteris.com/itsarch/index.htm.)
Figure 4. National ITS Architecture
![This diagram identifies 22 subsystems of the National ITS Architecture. Please see the Extended Text Description below.](images/ep2fig04.jpg)
(Extended Text Description: This diagram identifies 22 subsystems of the National
ITS Architecture. The diagram is divided into four main sections, with a series of connecting
communications formats. In the upper left corner, the Travelers section (yellow background)
has two sub-boxes within it: Remote Traveler Support (top, connected by a line to Fixed Point
– Fixed Point Communications) and Personal Information Access (bottom, connected by
a line to Wide Area Wireless (Mobile) Communications underneath and Fixed Point – Fixed
Point Communications underneath and to the right). At the top right, the larger Centers section
(green background) has two rows of sub-boxes within it. Top row, left to right: Traffic Management,
Emergency Management, Payment Administration, Commercial Vehicle Administration, and Maintenance
& Construction Management. Bottom row, left to right: Information Service Provider, Emissions
Management, Transit Management, Fleet and Freight Management, and Archived Data Management.
Every one of these sub-boxes under Centers is connected by a line to the Fixed Point –
Fixed Point Communications box underneath the Centers section and to the right of the Wide
Area Wireless (Mobile) Communications box (under Travelers section). To the lower left there
is a Vehicles section (blue background) with a set of diagonally ascending sub-boxes within
it (start lower left to the upper right of the box): Maintenance & Construction Vehicle,
Transit Vehicle, Commercial Vehicle, Emergency Vehicle, and Vehicle. Each of these sub-boxes
is connected by a line to the Wide Area Wireless (Mobile) Communications box above it, and
to the vertically-running Vehicle-Vehicle Communications box to the left of the Vehicles section.
To the lower right, there is a Field section (orange background) with a set of diagonally
descending sub-boxes within it (from upper left to lower right): Roadway, Security Monitoring,
Roadway Payment, Parking Management, and Commercial Vehicle Check. Each sub-box is connected
by a line to the Fixed Point – Fixed Point Communications box above it, and to the vertically-running
Field – Vehicle Communications box to the left (in between the Vehicles and Field sections).
Key Message from Author: Shows key depiction of Physical Arch—the "Sausage diagram".)
From the viewpoint of the SEP, the primary importance of the National ITS Architecture is
the template that it provides in the form of subsystems, information flows, and service packages
that form the basis of the regional ITS architectures that were discussed in the first step
of the SEP. This template allows the creation of regional ITS architectures throughout the
country that have a common underlying structure and definition.
Regional ITS Architecture
Whereas the National ITS Architecture guides ITS programs at the national level and addresses
all subsystems, technologies, and standards, regional ITS architectures define the plans,
programs, goals, and objectives for implementation on a more localized basis. Regional ITS
architectures have been developed for States, metropolitan areas, or other regions of interest.
They are developed through the participation of regional stakeholders, including owners and
managers of highway and transit agencies, public safety agencies, motor carrier organizations,
and other public transportation facilities.
A regional ITS architecture is developed to meet the specific needs of a region; define program
goals and stakeholder roles and responsibilities; and manage institutional agreements and
technical integration of ITS within the region. It represents a regional adaptation of the
National ITS Architecture. Creating a regional ITS architecture builds a shared vision for
ITS implementation and advances regional transportation improvement programs and long-range
transportation plans by planning operations and defining goals for regional ITS programs.
The components of a regional ITS architecture are defined by Rule 940 (and the corresponding
FTA policy). FHWA has developed a regional ITS architecture development tool called Turbo
Architecture, which is a database tool that holds the details of the region's stakeholders,
systems, ITS services, system interconnects, projects, agreements, ITS standards, roles and
responsibilities, and functional requirements. Additional information about regional ITS architectures,
along with examples of each of the required outputs, can be found in the document Regional
ITS Architecture Guidance Document.13
ITS Project Architectures
An ITS project architecture is a high-level view of a project that focuses on the systems,
interfaces, and information flows relevant to the project. As discussed in the overview of
the SEP, this is a typical output of the high-level design step. Although this type of architecture
can be created to varying degrees of detail, one easy and effective way to create an ITS project
architecture is to create the subset of the regional ITS architecture that relates to the
project. Using this formulation, the project architecture would define stakeholders, systems,
ITS services, interfaces, roles and responsibilities, agreements, and functional requirements
relevant to the project. Many of these ITS project architecture outputs can be used to perform
the systems engineering analysis required by another section of Rule 940 (see discussion below).
Turbo Architecture can be a useful tool for creating the ITS project architecture. The following
figure shows an example of a project architecture diagram created with Turbo Architecture
from the New Mexico Statewide ITS Architecture. This project, for improvements to the District
1 Traffic Operations Center, shows the key interfaces that will be developed as part of the
project.
Figure 5. Regional ITS Architecture
![Figure 5. Regional ITS Architecture. Please see the Extended Text Description below.](images/ep2fig05.jpg)
(Extended Text Description: This diagram provides a high level view of a project
focusing on the systems, interfaces, and information flows relevant to the project. There
are a series of seven main sections with numerous labeled flowchart lines linking the various
main sections. At the top left, there is a main section designated "NMDOT – New
Mexico Department of… / NMDOT Statewide TMC."
There are series of six bi-directional flowchart lines that link this main section to the
center middle main section designated "NMDOT – New Mexico Department of…
/ NMDOT District 1 TOC." The lines
are labeled: device control request, device data, device status, incident information, road
network connections, and traffic images. At the top right, there is a main section designated
"NMDOT – New Mexico Department of… / NMRoads" with a series of six
bi-directional flowchart lines linking it to the center middle main section (NMDOT District
1 TOC). The lines are labeled: device control request, device data, device status, incident
information, road network conditions, and traffic images. At the middle left, there is a main
section designated "City of Las Cruces / City of Las Cruces Traffic Operations Center"
with a series of bi-directional flowchart lines linking it to the center middle main section
(NMDOT District 1 TOC). The lines are labeled: device control request, device data, device
status, incident information, road network conditions, and traffic images. At the middle right,
there is a main section designated "TxDOT / TransVista" with a series of three bi-directional
flowchart lines linking it to the center middle main section (NMDOT District 1 TOC). The lines
are labeled: incident information, road network conditions, and traffic images. At the lower
left, there is a main section designated "Private Weather Information Provider / Private
Weather Support Services System" with one bi-directional flowchart line linking it to
the middle center main section (NMDOT District 1 TOC). The line is labeled: environmental
conditions data. At the lower right, there is a main section designated "US Customs and
Border Protection / US Border Inspection Systems" with one bi-directional flowchart line
linking it to the center middle main section (NMDOT District 1 TOC) with the label: border
wait times data. The center middle section is designated "NMDOT – New Mexico Department
of… / NMDOT District 1 TOC). It is linked to all the other main sections via the bi-directional
flowchart lines described above. Key message from Author: Defines the third type of architecture—project
architecture—and gives an example of a project arch drawn from Turbo Arch tool.)
Source: Consensus Systems Technologies (ConSysTec).
Although ITS project architectures are usually produced from a regional ITS architecture,
as illustrated above, in certain cases the project may not be described in the regional ITS
architecture. In that case an ITS project architecture in a form similar to the regional ITS
architecture can be produced and then used to help update the regional ITS architecture at
its next iteration.
ITS Standards
The RITA ITS Standards website describes the standards as follows:
ITS standards define how ITS systems, products, and components can interconnect, exchange
information and interact to deliver services within a transportation network. ITS standards
are open-interface standards that establish communication rules for how ITS devices can perform,
how they can connect, and how they can exchange data in order to interoperate. It is important
to note that ITS standards are not design standards: They do not specify specific products
or designs to use. Instead, the use of standards gives transportation agencies confidence
that components from different manufacturers will work together, without removing the incentive
for designers and manufacturers to compete to provide products that are more efficient or
offer more features. (www.standards.its.dot.gov/LearnAboutStandards/ITSStandardsBackground)
ITS standards address the data transferred on an interface, the communications protocols used
to send the data, and in a couple of cases the physical specification of hardware. From a
data standpoint, the ITS standards focus on interfaces and information exchanges identified
in the National ITS Architecture. Standards development is supported by the USDOT's Joint
Program Office's (JPO) ITS Standards Program, which provides a collaborative process to define
and update standards for use by all public and private entities in the development of ITS
applications and technology. The ITS Standards Program works with standards development organizations
such as the American Association of State Highway and Transportation Officials (AASHTO), the
Institute of Transportation Engineers (ITE), the American Public Transportation Association
(APTA), the Institute of Electrical and Electronics Engineers (IEEE), and the National Electrical
Manufacturers Association (NEMA) to address interface requirements between different ITS applications.
ITS standards provide the technical guidance
and requirements for each component of an ITS system. They guide every aspect of technical
applications and system communications, and compliance is required for all applications. To
properly specify ITS standards, officials must customize them to fit the needs and requirements
of the project. More information about ITS standards and how to specify them for projects
is available on the USDOT Professional Capacity-Building website. A set of ITS Standards Training
modules can be found at www.pcb.its.dot.gov/stds_training.aspx.
Back to top
Using the SEP for ITS Project Development
The SEP, as discussed earlier, may be viewed as an extension of the traditional project development
process that is already established in transportation agencies. Although project development
processes vary from State to State and from organization to organization within each State,
the transportation project development process tends to have the same major steps.
- Project Initiation. In this step, the project manager is identified, the project team is assembled,
and the project development is planned. A high-level scope of the project is developed, costs
are estimated, and the required forms and checklists are completed to garner approval for
the project from the sponsoring and funding agency(ies). For FHWA and FTA, this is a critical
point in the process where approval to proceed is given and Federal funds are obligated.
- Preliminary Engineering. In the traditional capital project development process, environmental,
right-of-way, and other studies are performed depending on the type of project. These studies
result in better understanding of the project requirements and constraints. ITS projects that
include a construction component will require these same studies as well as additional engineering
analyses to fully specify the project requirements for the ITS portion of the project.
- Plans, Specifications, and Estimates. The detailed design for the project, complete with detailed
project specifications, estimates of material needs, and associated costs, are documented.
In a traditional construction project, this process step provides companies with all the information
they need to develop an accurate bid.
- Construction. The project is built. For a traditional transportation project, this is construction
of the actual physical improvement. For an ITS project, this includes the procurement and
implementation of the actual hardware, software, and enabling products (e.g., manuals, operating
procedures, and training).
- Project closeout. After final inspection and testing, the completed project is accepted, as-built
plans are created, and a project history file is completed.
There is a close correspondence between the SEP and the traditional transportation development
process as shown in Figure 6.
Figure 6. Correlation Between SEP and Traditional Transportation Development Process
![Figure 6. Correlation Between SEP and Traditional Transportation Development Process. Please see the Extended Text Description below.](images/ep2fig06.jpg)
(Extended Text Description: The graphic relates SEP to the traditional transportation
development process. The lower portion of the graph is the "V" diagram from SEGB.
Please see Figure 2 for a full description of the "V" diagram. Above this version
of the graphic is a long yellow rectangle broken up into six sections. Each section represents
a stage in project development. Dotted blue lines run vertically down from each section to
indicate which project steps fall into each project phase. The sections are grouped as the
following: Project Initiation: Systems Engineering Management Plan Framework. Preliminary
Engineering: Concept of Operations, System Requirements. Plans, Specs, and Estimates: Subsystem
Requirements Project Arch (HLD), Component Level Design (Detailed). Construction: Software
Coding hardware Fabrication, Unit Testing, Subsystem Integration & Verification. Project
Closeout: System Validation. Operations & Maintenance: Operations & Maintenance.)
The project initiation phase includes activities that occur prior to the start of the project,
which includes the procurement process. The impact of the SEP on ITS project procurement is
described in the document Model Systems Engineering Documents for Adaptive Signal Control
Technology (ASCT) Systems.14 The preliminary engineering
corresponds to the concept of operations and system requirements steps. The step of plans,
specifications, and estimates relates to the design steps. Finally the construction step is
analogous to the development and verification steps of the SEP.
Systems Engineering Analysis Requirements
Rule 940 (Section 940.3 Definitions) contains specific requirements related to performing
systems engineering analysis (SEA) for ITS projects that use highway trust funds (see sidebar).
The rule defines an ITS project as "any project that in whole or in part funds the acquisition
of technologies or systems of technologies that provide or significantly contribute to the
provision of one or more ITS user services as defined in the National ITS Architecture."
Several key observations can be made about these SEA requirements. For example, item (b) says
that the analysis should be on a scale commensurate with the scope of the project. This is
a key concept in the SEP—that the level of effort should be tailored to the scope of
the project. As has been mentioned before in this module, the SEP is not a one-size-fits-all
process; rather, the effort expended should be related to the scope of the project. One important
way to assess the level of effort required is to consider the risk associated with the project.
A very low-risk project (e.g., installation of additional closed-circuit television cameras
to an existing system) might proceed with a minimum SEP, possibly referencing work done in
previous stages of the project. However, a project with more inherent risk (e.g., the initial
development of a Traffic Operations Center in a region) would likely want to go through the
process step by step.
The requirements in Section 940.11 correspond to the SEP, but not identically, because Rule
940 came out in 2001, prior to the development of the SEP for transportation projects that
is referenced in this module. However, if the SEP steps are followed as described above, all
of the requirements of the rule will be addressed by the steps from concept of operations
through detailed design. Many States have developed Systems Engineering Review Forms based
on the requirements, which can be used as a checklist to identify how systems engineering
outputs on a particular ITS project address the Rule 940 SEA requirements.
Relationship to Transportation Planning
Although the majority of the steps in the SEP address the life cycle of a specific project
(moving from systems engineering management planning to system validation), the wings of the
V diagram affect the planning of ITS systems. This planning occurs within the structure of
the overall transportation planning process.
Transportation planning is generally performed by State DOTs and metropolitan planning organizations
(MPOs). One key output of the planning process is a long-range transportation plan (LRTP).
This plan is sometimes referred to as a metropolitan transportation plan (MTP) at the MPO
level and a long-range statewide transportation plan at the State level. In metropolitan areas,
the transportation plan is the statement of the ways the region plans to invest in the transportation
system. According to the Federal regulation, the plan shall "include both long-range
and short-range program strategies/actions that lead to the development of an integrated intermodal
transportation system that facilitates the efficient movement of people and goods." The
second key output of the planning process is the Transportation Improvement Program (TIP).
At the two levels discussed in this module, these are usually called the Metropolitan TIP
or Statewide TIP. In the TIP, the MPO identifies the transportation projects and strategies
from the MTP that it plans to undertake over the next four years. All projects receiving Federal
funding must be in the TIP. The TIP is the region's way of allocating its limited transportation
resources among the various capital and operating needs of the area, based on a clear set
of short-term transportation priorities.15
The regional ITS architecture discussed in the first step of the SEP represents a regional
plan for the deployment of ITS. The architecture represents the wish list for ITS because
it contains a list of ITS projects without fiscal constraint. Because of the timeframe of
the regional ITS architecture, it will usually contain outputs that can be used in the development
of both the LRTP and the TIP. For example, the architecture usually contains a list of medium-
and long-term projects, which represent initiatives that have not yet been funded, and as
such they can be an input to the development of the TIP. If the projects are described in
the more general terms of strategies, they can provide an input to the strategies described
in the LRTP. Because ITS systems have life cycles that are often less than 10 years, transportation
planning needs to include explicit consideration of technology updating or replacement, for
example, as system preservation projects in the regional ITS architecture. A more complete
discussion of how the regional ITS architecture supports transportation planning can be found
in the Regional ITS Architecture Guidance Document16
and in Applying a Regional ITS Architecture to Support Planning for Operations: A Primer.17
Both the concept exploration and the retirement or replacement steps of the SEP provide outputs
that support ITS planning. In the concept exploration step, the output of the effort will
define the technical and cost parameters for projects or initiatives to be included in the
TIP or LRTP. As described earlier, this step looks at alternative concepts to find the one
with the best cost-to-benefit ratio or business case. In the retirement or replacement step
a study or analysis is performed to determine the best approach to addressing a particular
system's end of life. The results of the analysis or study are then moved to either the LRTP
(if the resulting replacement is further in the future) or to the TIP (if the replacement
is ready to be programmed as a TIP project).
Back to top
Summary
This module has provided a step-by-step overview of the systems engineering process as it
is applied to the ITS field. Related topics of the National ITS Architecture and ITS Standards
Program were addressed along with their relationship to the SEP. Finally, the module described
the relationship of the SEP to ITS project development and ITS planning.
Back to top
References
Back to top
Resources
- IEEE 1028-1997, IEEE Standard for Software Reviews, Institute of Electrical and Electronics
Engineers, 1998.
- IEEE 1220-2005, IEEE Standard for Application and Management of the Systems Engineering Process,
Institute of Electrical and Electronics Engineers, Sept 9, 2005.
- IEEE Std 1362-1998, IEEE Guide for Information Technology – System – Definition
– Concept of Operations (ConOps) Document, Institute of Electrical and Electronics Engineers,
1998.
- ISO/IEC 15288:2008, Systems
and Software Engineering—System Life Cycle Processes.
Back to top