 |
  |
Systems Engineering for Intelligent Transportation Systems
|
|
Systems Engineering for Intelligent Transportation Systems
In true systems engineering fashion, let's begin with a few basic definitions before we jump into the details of the systems engineering discipline.
What is a System?
Everyone uses the term and has an intuitive notion of what a system is, but there is a formal definition. INCOSE defines a system as:
"A combination of interacting elements organized to achieve one or more stated purposes."
This general definition covers almost everything you can think of – household appliances, transportation management systems, the latest weapon system – all of these are systems.
What is Systems Engineering?
Since the term was coined in the 1950s, systems engineering has evolved from a process focused primarily on large-scale defense systems to a broader discipline that is used in all kinds of project development. Systems engineering can be applied to any system development, so whether you are developing a household appliance, building a house, or implementing a sophisticated transportation management system, systems engineering can be used. INCOSE defines systems engineering like this:
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.
Note that this definition is very broad – it covers the project life cycle from needs definition to system disposal. It includes technical activities like requirements and design, as well as project activities like risk management and configuration management. Systems engineering provides a systematic process and tools that directly support project management.
What is an ITS Project?
In order to apply systems engineering to ITS projects in accordance with the FHWA Rule/FTA Policy, it is important to define an ITS project. Rule 940 defines ITS projects quite broadly:
ITS
Project means 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.
This definition encompasses a wide range of projects. Smaller ITS projects might be limited to the purchase and installation of field equipment – controllers, ramp meters, signals, etc. Larger ITS projects support integration of multiple systems and development of custom software – for example, transportation management centers and 511 traveler information systems. These ITS projects are vastly different in complexity and in the amount of systems engineering that is needed. The FHWA Division/FTA Regional Offices establish and monitor how systems engineering analysis requirements are levied on specific ITS projects.
There are a handful of fundamental challenges and important concepts that shape and drive the systems engineering discipline.
Project Initiation Euphoria
In the first days of any new project, the mood is optimistic and expectations are high. Just over the horizon, reality is looming, and technology, schedule, and funding constraints may ultimately cause the project to fall short of goals that were established in its early days. The need to balance these natural inclinations and real-world constraints is an important driver for implementing a systematic systems engineering approach at the outset to guide the team and manage expectations.
Cone of Uncertainty
At the beginning of a high-technology project, there may also be significant uncertainty in the project cost and schedule estimates. The less experience the project team has with similar projects, the more uncertainty there will be. The estimates naturally get better as work progresses and the project team gains a better understanding of the system they are building. At project completion, all the uncertainty has been removed – the team knows exactly how much was spent. When you plot the uncertainty against time (see Figure 4), it looks like a cone, which is why Barry Boehm called this challenge the "cone of uncertainty".
Systems engineering focuses on resolving uncertainty early in project development by establishing the project scope and defining good requirements. Incremental development strategies also help to mitigate the risk of unreliable estimates early in the project.
Figure 4: Cone of Uncertainty
The Wrong Procurement Method Can Tie Your Hands
The traditional procurement methods that have been used for decades in highway construction are often not suitable for ITS projects. For example, the Low Bid method uses a consultant to prepare a design specification that is then implemented by a contractor who submits the lowest bid. This method works well for building roads, but experience shows that it does not work well for many ITS projects that frequently require collaboration and iteration between the design and implementation phases. It is vital to select the right procurement method so that you can implement the right systems engineering approach for your project. (See Section 6.2.1 for more information on procurement.)
Late Changes Drive Project Costs
There is no such thing as a mistake-free project development. In the transportation industry, experienced construction managers will tell you that every project has change orders. The problem is that change orders during construction are more expensive to the project. A mistake or missed system feature that is not recognized until after project closeout will be even more expensive to address.
Studies5 of software development projects have shown that this "latency cost" can increase the cost of fixing a mistake dramatically. As shown in Figure 5, for example, a bad requirement will be relatively cheap to fix while you are still in the requirements phase (1x) but increasingly expensive to fix later in project development. This is because you not only have to fix the bad requirement later in the project, you also have to fix the design and implementation problems that were caused by the bad requirement. The problems compound themselves if they are left uncorrected.
In systems engineering, verification and validation of the evolving project documentation is performed early and often to maximize the chances of identifying defects as early in the project development cycle as possible.
Figure 5: Late Changes Drive Project Costs
(Adapted from Steve
McConnell, Code Complete)
The Odds Are Against Success
The Standish Group has done more than 10 years of research, collecting statistics on information technology projects, and their findings have consistently painted a dismal (albeit slowly improving) picture. For example, in 2004, as shown in Figure 6, only 34% of the projects surveyed met the criteria for success – completed on time, on budget, and with all the features originally specified. Of the 280,000 projects surveyed that year, more than 142,000 were late or over budget and another 42,000 failed outright.
Figure 6: Standish Group: 2004 CHAOS Report Project Success Rate
While the infamous failure rates are the most often repeated information, the report also identifies success factors that are identified through the same project surveys. Many of these success factors (including user involvement, minimized scope, and firm basic requirements) are related to the systems engineering process. Systems engineering won't guarantee success, but it will help you to identify issues earlier in the project schedule and will improve your chances for a successful project in the end.
Start with Your Eye on the Finish Line
You should reach consensus at the very beginning of the project on what will constitute success at the end. This means that the stakeholders should start with an agreement of what the project should accomplish and the metrics that will be used to measure the success of the project. This initial focus on the finish line must be sustained by project management as project development progresses and competing interests and project complexities begin to dominate the day-to-day work.
Stakeholder Involvement is Key
Successful projects involve the customer, users,
operators, and other stakeholders in the project development. Systems
engineering is a systematic process that includes reviews and decision points
intended to provide visibility into the process and encourage stakeholder
involvement. The systems engineering process includes stakeholders through all
stages of the project, from initial needs definition through system
verification and acceptance. The stakeholders who are involved in any
particular step will vary, providing managers, operators, and technical
personnel with an opportunity to contribute to the steps in the process where
their input is needed.
Define the Problem Before Implementing the Solution
Very
often, you'll have a solution already in mind at the start of a project and may
even find yourself "backing into" requirements to match your solution. Resist
this temptation and instead use the systems engineering process to first define
the problem. You'll find that there are actually multiple ways to solve the
problem, and a good trade study will help you to determine the best solution on
the basis of a clear understanding of the requirements.
Delay Technology Choices
Technology is constantly
changing. The choices available when a project is initially conceived may well
be replaced by better technology by the time the project is implemented.
Specifying technology too early will result in outdated technology or constant
baseline changes as you try to keep up with technology advancements. It's best
to follow the systems engineering process by defining the needs, requirements,
and high-level design without specifying technology. You'll have a stable
baseline, and you'll be able to make the most appropriate technology choices
when it is time to implement.
Baseline
is a frequently used term in systems engineering. A baseline is a reference
point against which everyone on the project team works, so you want to control
the changes that are made to the baseline. The process of establishing and
controlling project baselines is configuration management, which is
discussed in Section 5.4.
Divide and Conquer
Many systems are large and complex. A key systems engineering strategy is the decomposition of such a system into smaller subsystems and then of the subsystems into more manageable hardware and software components. These simpler components are easier to understand and define and ultimately are easier to build. Much of the systems engineering process is built around this approach – breaking down a big problem into many smaller components that can be individually solved and then recombined.
Connecting the Dots – Traceability
As you move from one step to the next in the
systems engineering process, it is important to be able to relate the items in
one step with those in another. The relationship between items is called traceability.
For example, you use traceability to relate a requirement to the subsystem that
will implement the requirement. Traceability connects many items together.
The requirement will be related to a user need as well as to a test that will
be used to verify the requirement. Traceability is a powerful concept that
allows you to be certain 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.
Many different process models have been developed over the years that specify a series of steps that make up the systems engineering approach6. Among these models, the "V" model, shown in Figure 7, is emerging as the de facto standard way to represent systems engineering for ITS projects.
Don't
be surprised if you come across different spellings for the "V" model. Some
books, guides, and other resources refer to the same V-shaped model as the
"Vee" model. If it looks like a "V" and it sounds like a "V", then it is a
reference to the same basic model, whether it is spelled "V" or "Vee".
Since it was first developed in the 1980s, the "V" model has been refined and applied in many different industries. Wings have been recently added to the "V" as part of its adaptation for ITS to show how project development fits within the broader ITS project life cycle. The left wing shows the regional ITS architecture, feasibility studies, and concept exploration that support initial identification and scoping of an ITS project based on regional needs. A gap follows the regional architecture(s) step because the regional architecture is a broader product of the planning process that covers all ITS projects in the region. The following steps in the "V" are for a specific ITS project. The central core of the "V" shows the project definition, implementation, and verification processes. The right wing shows the operations and maintenance, changes and upgrades, and ultimate retirement of the system. The wings are a key addition to the model since it is important to consider the entire life cycle during project development.
As shown in the "V", 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 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. (Each of the steps in the "V" are defined in detail in Chapter 4.)
One of the first things that strikes you about the "V" is the symmetry between the left and right sides of the model. This symmetry reflects the relationship between the steps on the left and the steps on the right. The system definition that is generated on the left is ultimately used to verify the system on the right. For example, the user needs and performance measures that are identified in the Concept of Operations are the basis for the System Validation Plan that is used to validate the system at the end of project development. Similarly, a System Verification Plan is developed with the System Requirements so that the engineers consider how to verify each requirement as the requirements are written.
The connections between the left and right are indicated by the arrows that cross the "V", showing how plans developed on the left drive the process on the right. These connections provide continuity between the beginning and end of project development and ensure that the engineers are focused on the completion of the project from the beginning. The connections between the left and right sides of the model reflect one of the systems engineering principles – start with your eye on the finish line.
Projects have been managed for years using Gantt charts that identify tasks and major milestones. You don't start the next task until you have completed the previous supporting tasks and passed the intervening milestone. The "V" diagram is similarly punctuated by a series of major milestones (labeled Document/Approval in the figure) where the output of the previous step is reviewed and the customer and project team determine whether the project is ready to move to the next step in the process. The project moves forward only if the criteria for the decision point have been satisfied. Decision points are important milestones that provide visibility into the project development and allow for issue identification and course correction during development. (Decision-point reviews are covered in more detail in Section 5.2.2.)
TOC Previous Page Next Page
You will need the