Traffic management system:

Imagine using a manual system to control air traffic around a

major metropolitan center or to manage the life-support system of a manned spacecraft or the
accounting activities of a multinational bank.
Successfully automating such systems not only addresses the very real problems at hand but
also leads to a number of tangible and intangible benefits, such as lower operational costs,
greater safety, and increased
functionality. Of course, the operative word here is successfully. Building
complex systems is plain hard work and requires the application of the best engineering
practices we know, along with the creative insight of a few great designers.
This chapter tackles the development of such a problem.

Inception:

railroads are a business and consequently must be profitable. Railroad com-

panies must delicately balance the demands of frugality and safety and the pressures to
increase traffic against efficient and predictable train scheduling. These conflicting needs
suggest an automated solution to train traffic management,
including computerized train routing and monitoring of all elements of the train
system. Such automated and semiautomated train systems exist today in Sweden,
Great Britain, West Germany, France, Japan [1], Canada, and the United States.
The motivation for each of these systems is largely economic and social: Lower
operating costs and more efficient use of resources are the goals, with improved
safety as an integral by-product.
In this section, we begin our analysis of the fictitious Train Traffic Management
System (TTMS) by specifying its requirements and the system use cases that fur-
ther describe the required functionality.

Requirements for the train traffic management system:

Software development clearly remains the technology of highest
risk in the successful deployment of any large automated application, and our
goal is to limit this risk to a manageable level, not to increase it.
This is a very large and highly complex system that in reality would not be speci-
fied by simple requirements. However, for this chapter, the requirements that fol-
low will suffice for the purposes of our analysis and design effort. In the real world, a problem
such as this could easily suffer from analysis paralysis because
there would be many thousands of requirements, both functional and nonfunctional, with a
myriad of constraints. Quite clearly, we would need to focus our
efforts on the most critical elements and prototype candidate solutions within the
operational context of the system under development.
The Train Traffic Management System has two primary functions:
train routing
and train systems monitoring. Related functions include traffic planning, failure
prediction, train location tracking, traffic monitoring, collision avoidance, and maintenance
logging. From these functions, we define eight use cases, as shown
in the following list.
■ Route Train: Establish a train plan that defines the travel route for a par-
ticular train.
■ Plan Traffic: Establish a traffic plan that provides guidance in the
development of train plans for a time frame and geographic region.
■ Monitor Train Systems: Monitor the onboard train systems for
proper functioning.
■ Predict Failure: Perform an analysis of train systems’ condition to
predict probabilities of failure relative to the train plan.
■ Track Train Location: Monitor the location of trains using TTMS
resources and the Navstar Global Positioning System (GPS).
■ Monitor Traffic: Monitor all train traffic within a geographic region.
■ Avoid Collision: Provide the means, both automatic and manual, to
avoid train collisions.
■ Log Maintenance: Provide the means to log maintenance performed on
trains.
These use cases establish the basic functional requirements for the Train Traffic Management
System, that is, they tell us what the system must do for its users. In addition, we have
nonfunctional requirements and constraints that impact the
requirements specified by our use cases, as listed here.
Nonfunctional requirements:
■ Safely transport passengers and cargo
■ Support train speeds up to 250 miles per hour
■ Interoperate with the traffic management systems of operators at the TTMS
boundary
■ Ensure maximum reuse of and compatibility with existing equipment
■ Provide a system availability level of 99.99%
■ Provide complete functional redundancy of TTMS capabilities
■ Provide accuracy of train position within 10.0 yards
■ Provide accuracy of train speed within 1.5 miles per hour
■ Respond to operator inputs within 1.0 seconds
■ Have a designed-in capability to maintain and evolve the TTMS

Constraints:
■ Meet national standards, both government and industry
■ Maximize use of commercial-off-the-shelf (COTS) hardware and software
Now that we have our core requirements defined, at least at a very high level, we
must turn our attention to understanding the users of the Train Traffic Manage-
ment System. We find that we have three types of people who interact with the
system: Dispatcher, TrainEngineer, and Maintainer. In addition, the
Train Traffic Management System interfaces with one external system, Navstar
GPS. These actors play the following roles within the TTMS.
■ Dispatcher establishes train routes and tracks the progress of individual
trains.
■ TrainEngineer monitors the condition of and operates the train.
■ Maintainer monitors the condition of and maintains train systems.
■ Navstar GPS provides geolocation services used to track trains.

Determining system use cases:

In it, we see the system functionality used by each of the actors. We also see that
we have «include» and «extend» relationships used to organize relation-
ships between several of the use cases. The functionality of the use case Monitor
Train Systems is extended by the use case Predict Failure. During the
course of monitoring systems, a failure prediction analysis (condition:
{request Predict Failure}) can be requested for a particular system
that is operating abnormally or may have been flagged with a yellow condition indicating a
problem requiring investigation. This occurs at the Potential Failure extension point.
The functionality of the Monitor Traffic use case is also extended, by that of the Avoid Collision
use case. Here, when monitoring train traffic, an actor has optional system capability to assist in
the avoidance of a collision—at
the Potential Collision extension point. This assistance can support both manual and automatic
interventions. Monitor Traffic always includes the
functionality of the Track Train Location use case to have a precise pic-
ture of the location of all train traffic. This is accomplished by using both TTMS
resources and the Navstar GPS.

Elaboration:

Our attention now turns to developing the overall architecture framework for the
Train Traffic Management System. We begin by analyzing the required system
functionality that leads us into the definition of the TTMS architecture. From
there, we begin our transition from systems engineering to the disciplines of hard-
ware and software engineering. We conclude this section by describing the key abstractions
and mechanisms of the TTMS.

Analyzing System Functionality:

Now that the requirements for the Train Traffic Management System have been specified, our
focus turns to how the system’s aggregate parts provide this
required functionality. This perspective is often referred to as a white-box view
since the internal functioning of the system is seen externally. We use activity dia-
grams to analyze the various use case scenarios to develop this further level of detail.

Interaction Overview Diagram:

The interaction overview diagram can use any type of interaction—
sequence, communication, timing, or another interaction overview—to
show this detail. As we see here, this diagram can be used to map the flow
from one interaction to another, which can be useful if you have long, com-
plicated interactions.

Defining the TTMS Architecture:

The energy management system advises the train engineer in real time as to the
most efficient throttle and brake settings.

The onboard display system provides the human/machine interface for the train
engineer.

The data management unit serves as the communications gateway between all
onboard systems and the rest of the network, to which all trains, dispatchers, and other users
are connected.

Train location tracking is achieved via two devices on the network: location transponders and
the Navstar GPS

The network control system is ultimately connected to one or more dispatch centers, which
comprise the rail operations control system and other users.
It should be apparent that track layouts and wayside equipment may change over
time; in addition, the numbers of trains and their routes may change daily. The
Train Traffic Management System must therefore be designed to permit incorpo-
ration of new sensor, network, and processor technology.

From Systems Engineering to Hardware and

Software Engineering:

Up to this point in ourdevelopment, we performed systems engineering, rather

than hardware or software engineering activities, as we analyzed scenarios of the
use cases that specify the primary functional requirements for the Train Traffic Management
System. From this analysis, we were able to specify a block diagram of its major elements to
define a candidate TTMS system architecture. As
we continue our development, the architecture of lower-level hardware and soft-
ware elements will evolve based on the concepts that our system architects likely have in mind.
Eventually we decide what portions of the system functionality will be fulfilled by hardware,
software, or manual operations. At that point, development becomes even more of a
collaborative effort among the systems, hardware,
software, and operational engineering teams.

The key to maintaining sanity during the development of any complex project is
to engineer sound and explicit interfaces among the key elements of the system.
This is particularly important when defining hardware and software interfaces. At
the start, interfaces can be loosely defined, but they must quickly be formalized so
that different parts of the system can be developed, tested, and released in paral-
lel. Well-defined interfaces also make it far easier to make hardware/software
trade-offs as opportunities arise, without disrupting already completed parts of
the system. Furthermore, we cannot expect all of the developers in a large, possi-
bly globally distributed, development organization to have a complete view and
understanding of all parts of the system. We must therefore leave the specification
of these key abstractions and mechanisms to our best architects.

Key Abstractions and Mechanisms:

A study of the requirements for the Train Traffic Management System suggests
that we really have four different subproblems to solve:
1. Networking
2. Database
3. Human/machine interface
4. Real-time analog and digital device control

Each of these four subproblems involves largely independent issues. Our system
architects need to identify the key abstractions and mechanisms involved in each,
so that we can assign experts in each domain to tackle their particular subproblem
in parallel with the others. Note that this is not a problem of analysis or design:
Our analysis of each problem will impact our architecture, and our designs will
uncover new aspects of the problem that require further analysis. Development is
thus unavoidably iterative and incremental.
If we do a brief domain analysis across these four subproblem areas, we find that
there are three common high-level key abstractions:
1. Trains: including locomotives and cars
2. Tracks: encompassing profile, grade, and wayside devices
3. Plans: including schedules, orders, clearances, authority, and crew assignments.
Continuing, we may devise a key mechanism for each of the four nearly indepen-
dent subproblems:
1. Message passing
2. Train schedule planning
3. Displaying information
4. Sensor data acquisition
These four mechanisms form the soul of our system. They represent approaches
to what we have identified as the areas of highest development risk. It is therefore
essential that we deploy our best system architects here to experiment with alter-
native approaches and eventually settle on a framework from which more junior
developers may compose the rest of the system.

Construction:
In this section, we start by examining the semantics of each of this system’s four
key mechanisms: message passing, train schedule planning, displaying information and sensor
data acquisition. This leads into a discussion of release manage-
ment, which supports our iterative and incremental development process. We conclude this
section by analyzing how developing a system architecture supports
the specification of the TTMS subsystems.

Message Passing:
In the Train Traffic Management System include signals to activate
wayside devices, indications of trains passing specific locations, and orders from
dispatchers to train engineers. In general, these kinds of messages are passed at
two different levels within the TTMS:
1. Between computers and devices
2. Among computers
Our interest is in the second level of message passing. Because our problem
involves a geographically distributed communications network, we must consider
issues such as noise, equipment failure, and security.
Train Schedule Planning:
the concept of a train plan is central to the operation of the
Train Traffic Management System. Each train has exactly one active plan, and
each plan is assigned to exactly one train and may involve many different orders
and locations on the track.
Our first step is to decide exactly what parts constitute a train plan. To do so, we
need to consider all the potential clients of a plan and how we expect each of them
to use that plan.
In a more perfect world, with no communication noise or delays and infinite com-
puting resources, our solution would be to place all train plans in a single, central-
ized database. This approach would yield exactly one instance of each train plan.
However, the real world is much more perverse, so this solution is not practical.
We must expect communication delays, and we don’t have unlimited processor
cycles. Thus, having to access a plan located in the dispatch center from a train
would not at all satisfy our real-time and near real-time requirements.
However, we can create the illusion of a single, centralized database in our soft-
ware. Basically, our solution is to have a database of train plans located on the computers at the
dispatch center, with copies of individual plans distributed as
needed at sites around the network. For efficiency, then, each train computer could retain a
copy of its current plan. Thus, onboard software could query this plan with negligible delay. If
the plan changed, either as a result of dispatcher action or (less likely) by the decision of the
train engineer, our software would have to ensure that all copies of that plan were updated in a
timely fashion.

Displaying information:
Using off-the-shelf technology for our database needs helps us to focus on the
domain-specific parts of our problem. We can achieve similar leverage for our
display needs by using standard graphics facilities. Using off-the-shelf graphics
software effectively raises the level of abstraction in our system, so that develop-
ers never need to worry about manipulating the visual representation of display-
able objects at the pixel level.
There is a potential disadvantage to this approach, however. Ultimately, we might
have many different kinds of displayable objects, each implemented by different
groups of developers. If we let the implementation of each displayable object proceed
independently, we are likely to end up with redundant code, different implementation styles, and
a generally unmaintainable mess. A far better solution is to do a domain analysis of all the kinds
of displayable objects, determine what visual elements they have in common, and devise an
intermediate set of class utilities that provide display routines for these common picture
elements. These class
utilities in turn can build on lower-level, off-the-shelf graphics packages.

Sensor Data Acquisition:

As our requirements suggest, the Train Traffic Management System includes many different
kinds of sensors. For example, sensors on each train monitor the
oil temperature, fuel quantity, throttle setting, water temperature, drawbar load,and so on.
Similarly, active sensors in some of the wayside devices report among
other things the current positions of switches and signals. The kinds of values returned by the
various sensors are all different, but the processing of different
sensor data is all very much the same.

Release Management:
Since we are using an incremental development approach, we will investigate the
employment of release management techniques and further analyze the system’s
architecture and the specification of its subsystems.

System Architecture:
The software design for very large systems must often commence before the tar-
get hardware is completed. Software design frequently takes far longer than hard-
ware design, and in any case, trade-offs must be made against each along the way.
This implies that hardware dependencies in the software must be isolated to the
greatest extent possible, so that software design can proceed in the absence of a
stable target environment. It also implies that the software must be designed with
the idea of replaceable subsystems in mind.

Subsystem Specification:
If we focus on the outside view of any of these subsystems, we find that it has all
the characteristics of an object. It has a unique, albeit static, identity; it embodies
a significant amount of state; and it exhibits very complex behavior.
This approach to decomposing a large and complex problem affords us different
views of the system while it is being developed. A system release is thus com-
posed of compatible versions of each subsystem, and we may have many such
releases: one for each developer, one for our quality assurance team, and perhaps
one for early customer use. Individual developers can create their own stable
releases into which they integrate new versions of the software for which they are
responsible, before releasing it to the rest of the team.

Post-Transition:
A safe and useful control system is a work in progress. This is not to say that we
never get to the point where we have a stable system—in fact, we must with every
delivery. Rather, the reality is that for systems that are central to a business such
as rail transportation, the hardware and software must adapt as the rules of the
business change; otherwise, our system becomes a liability rather than a competi-
tive asset.