Embed Size (px)
Citation preview
ITS TELECOMMUNICATIONS:
PUBLIC OR PRIVATE?
A COST TRADEOFF
METHODOLOGY GUIDE
INTELLIGENT TRANSPORTATION SYSTEMSJOINT PROGRAM OFFICE
ITS Telecommunications: Public or Private?A Cost Tradeoff Methodology Guide
r Computer Sciences Corporation PB Farradyne IncLdL Systems Engineering Division
Table of Contents
Section 1 - Introduction
1.1 Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . l-l
1.2 Related Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . l-l
1.3 Report Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . l-6
Section 2 - Requirements Analysis
2.1 Step 1: Identify ITS Program Goals, Objectives and Requirements.. ................................. 2-1
2.1.1 Historical Information.. ......................................................................................... 2-3
2.1.2 Technical Exchange Meetings ............................................................................... 2-3
2.1.3 Use Case Analysis.. ............................................................................................... 2-4
2.2 Step 2: Derive Telecommunications Requirements.. .......................................................... 2-5
2.3 Step 3: Document Requirements ........................................................................................ 2-7
2.4 Step 4: Validate Requirements.. .......................................................................................... 2-9
2.5 Step 5: Manage Requirements ........................................................................................... 2-10
Section 3 - Developing Alternative Technical Architectures
3.1 Characteristics of a Technical Architecture Alternative.. ..................................................... 3-l
3.2 Development of Alternative Technical Architectures........................................................... 3-5
3.3 Products of the Technical Alternatives Development.. ........................................................ 3-6
Section 4 - Define Costs
4.1 Construction Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-l
iii 12/16/96
4.1-l Construction Cost Development Methodology ..................................................... 4-3
4.1.2 Construction Cost Parameter Summary ................................................................. 4-5
4.1.2.1 Backbone Infrastructure Cost Parameter Summary.. ............................. 4-5
4.1.2.2 Device Connection Cost Parameter Summary........................................ 4-5
4.1.2.3 Environmental Enclosure Cost Parameter Summary .............................. 4-6
4.2 Leased Circuit Costs ............................................................................................................. 4-6
4.2.1 Leased Circuit Cost Development Methodology.. ................................................ 4-6
4.2.2 Summary of Leased Circuit Cost Parameters ........................................................ 4-8
4.3 Communications Equipment Costs.. .................................................................................... 4-8
4.3.1 Cost Development Methodology ........................................................................... 4-9
4.3.2 Communications Equipment Cost Parameter Summary.. .................................. 4-10
4.4 Communications OAM&P Labor Costs ............................................................................. 4-10
4.4.1 Cost Development Methodology.. ...................................................................... 4-l 0
4.4.2 Communications OAM&P Labor Cost Parameter Summary .............................. 4-l1
4.5 Communications Software Costs.. ..................................................................................... 4-l 2
4.5.1 Cost Development Methodology ........................................................................ 4-12
4.5.2 Communications Software Cost Parameter Summary......................................... 4-13
Section 5 - Calculate and Compare Option Life-Cycle Costs
5.1 Calculatee Life-Cycle Costs ................................................................................................... 5-l
5.1.1, Present Value Analysis ......................................................................................... 5-l
5.1.1.1 Cost Tradeoff Analysis ........................................................................... 5-l
5.1.1.2 Lease-Purchase Analysis......................................................................... 5-3
5.1.2 Automate Calculations ........................................................................................... 5-4
iv 12/16/96
5.2 Compare Life-Cycle Costs .................................................................................................... 5-7
5.2.1 Life-Cycle Cost Summary: All Optionss ............................................................... 5-7
5.2.2. Annual Life-Cycle Cost for Option Groups.......................................................... 5-7
5.2.3 Lowest Cost Option Details ................................................................................... 5-8
5.2.4 Lease, Build, and Hybrid Break-Even Analysis .................................................. 5-10
Section 6 - Perform Sensitivity Analysis
6.1 Vary Cost Parameters ........................................................................................................... 6-l
6.1.1 Cost Elements, Parameters, and Rankings............................................................. 6-l
6.1.2 Sensitivity Analysis Techniques ........................................................................... 6-3
6.2 Identifyl and Cost New Options.. ........................................................................................... 6-4
Acronym List
V 12/16/96
List of Illustrations
Figure Page
l-l. Scope of ITS Methodologies ............................................................................................... l-2
l-2. ITS Telecommunications Network Boundaries.. ................................................................. l-3
l-3. High-Level ITS Telecommunications Tradeoff Processes .................................................. l-4
l-4. Cost Tradeoff Activities ...................................................................................................... l-5
l-5. ITS Telecommunications Cost Tradeoff Relationships ....................................................... l-7
2-l. Requirements Analysis Methodology ................................................................................. 2-l
2-2. Identify ITS Program Goals, Objectives, and Requirements .............................................. 2-5
3-l. Characteristics of Technical Architecture........................................................................... .3-2
3-2. Centralized Topology .......................................................................................................... 3-3
3-3. Decentralized Topology...................................................................................................... .3 -4
3-4. A Telecommunications Network Alternative for Maryland’s CHART ............................. 3-8
4-1. Roadside Device Connection.. ............................................................................................ .4-2
5-1. Sample Cost Computation Hierarchy.. ................................................................................ 5-6
5-2. Annual Communications Costs for the Lowest Cost Alternative.. ..................................... 5-9
5-3. Lowest Cost Alternative by Component ............................................................................. 5-9
5-4. Lease, Build, and Hybrid Break-Even Analysis Graph ..................................................... 5-10
List of Tables
Table Page
1- 1. ITS Communications Network and Non-communications Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . l-4
2-l. Information Needed From Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
2-2. Candidate Use Case Scenario Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
2-3. Hypothetical Program-Level Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2-4. Hypothetical Derived Telecommunications Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
3 - 1. Example of Telecommunications Technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 -2
3-2. Telecommunications Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
3-3. Telecommunications Network Building Blocks.................................................................. 3-4
3-4. Technology Implementation.. .............................................................................................. 3-5
4- 1. ITS Communications Network and Non-communications Components ........................... .4- 1
5-l. Real Interest Rates on Treasury Notes and Bonds.. ............................................................. 5-2
5-2. 10-Year Discount Factors for 2.8% Real Discount Rate ..................................................... 5-2
5-3. Nominal Interest Rates on Treasury Notes and Bonds.. ..................................................... 5-3
5-4. 10-Year Discount Factors for 5.55% Nominal Discount Rate ............................................ 5-4
5-5. Life-Cycle Cost Summary for All Options.. ........................................................................ 5-7
5-6. Annual Life-Cycle Costs for the Hybrid Acquisition Options.. .......................................... 5-8
6-l. Cost Element Parameter Impact Rankings .......................................................................... 6-2
6-2. Lease Option Pessimistic Sensitivity Analysis.. .................................................................. 6-3
6-3. Hybrid Option Optimistic Sensitivity Analysis.. ................................................................. 6-4
vii 12/16/96
Section 1 -Introduction
1.1 Purpose and ScopeThis cost Tradeoff AssessmentMethodology Report outlines genericsteps and strategy for analyzing the costsof obtaining telecommunicationscapacity to meet the requirements ofjurisdictional ITS programs. It is astructured methodology that usesgenerally accepted engineering methodsand follows Federal guidelines forperforming cost-effectiveness analysesas defined in the Office of Managementand Budget (OMB) Circular A-94,Revised October 29, 1992. A specialfocus has been placed on analysis ofcosts of owning versus leasingtelecommunications for the ITS.
A base assumption for the use of thismethodology is that the ITS for whichtelecommunications is needed existseither by mandate or public policydecision, and that the overall benefit tothe public for any approach to providingtelecommunications for the ITS isessentially the same.
This methodology was used by theMaryland Department of Transporta-tion’s State Highway Administration indetermining the best and most costeffective action for Maryland’s Chesa-peake Highway Advisories (for) RoutingTraffic (CHART) ITS program.
Documentation of this methodology hasbeen fully funded by the United StatesDepartment of Transportation (US DOT)in a public/private collaborative projectwith MDOT SHA, US DOT, Computer
Sciences Corporation (CSC), andParsons-Brinkerhoff, Farradyne, Inc.
1 .2 Related MaterialsDetails on the Maryland study, CHART,and other related materials are availablefrom both the US DOT ITS JointProgram Office and the Maryland StateHighway Administration.
Some technical elements of this costtradeoff assessment methodologyoverlap and expand on Federal guidancefound in Chapter 11 of theCommunications Handbook for TrafficControl Systems, report number FHWA-SA-93-052, April 1993. Figure l-ldepicts high-level phases of an ITStelecommunications project. This costtradeoff analysis methodology beginswith the description of ITS goals andobjectives and ends with recommenda-tions for the most cost-effective tele-communications network architecture tobe considered for implementation. Totallife-cycle costs and lease versus buyalternatives are emphasized, andguidance that is presented in Chapter 11of the aforementioned Federal Handbookis expanded upon.
l-l 12/16/96
The target environment for conductingtradeoff analyses using this methodologyis the telecommunications infrastructureand capacity needed to communicatewith ITS field devices from operationaland management centers. Figure l-2depicts the boundaries between the ITS
telecommunications network, the fieldtraffic management devices, and otherITS operational capability and showswhich components of the system areconsidered communications-related andwhich are not by this methodology.
ITS Field Device
ITS Field Device
ITS Field
I CommunicationsI Electronics TelecommunicationsII
I Public or PrivateI TelecommunicationsI
TelecommunicationsCost-TradeoffBoundary
II
. - - - -.-.- - -.-.-.- - - - -.-.-.-.-.-.- -.
IIIII
Figure l-2. ITS Telecommunications Network Boundaries
l-3 12/17/96
This ITS telecommunications costtradeoff methodology is defined by twomajor processes:
l Systems Engineering
l Cost Analysis
Figure l-3 depicts each process and thehigh-level interaction between them.The Systems Engineering process: 1)develops ITS telecommunications goals,objectives, and requirements; 2) assessesavailable technology that can meet therequirements; and 3) provides fortechnical trade-off studies and producesalternatives.
The Cost Analysis process: 1) identifiesthe cost categories; 2) gathers cost dataand develops the models to be used tocalculate the costs for each alternativearchitecture; 3) calculates and analyzesthe costs; and 4) investigates thesensitivity of the least cost alternative(s)to cost assumptions.
Figure l-4 provides a more detailed viewof how such a study might be performed.A team is assembled that includes thetransportation customer, various ITSstakeholders, and the telecommunica-tions engineer or practitioner.
Systems Engineering
IterationCost Analysis
Telecommunications Recommendation
Figure l-3. High-Level Telecommunications Cost Tradeoff Processes
l-4 12/16 /96
Program RiskFunding Constraints Goals and ObjectivesPolitical Issues - Stakeholder Views Institutional Issues Use Case Analysis
_ Schedule Constraints
6LI / Derive the Telecmm
i%E%@f Sensor Data Voice . . LAN Data
. . Video
Technical Architectures
Figure 1-4. Cost Tradeoff Activities
The activities identified are: Conceptually, the team begins at the top
l Defining the ITS program-leveland proceeds to the bottom of the figure.
requirementsThe team accepts input and filters out theprogram-level functional, operational,
l Deriving telecommunications re-quirements
l Assessing technology and topology
l Analyzing options
and performance requirements.
Other issues and constraints areevaluated and all of the availableinformation is used to derive technicalrequirements that the telecommunica-tions engineer uses to develop technical
l-5 12/17/96
tions engineer uses to develop technicalalternatives. The derived requirementscan cover all aspects of requirements andwill include specifics for each of thetelecommunications traffic the ITSsystem needs.
Finally, the alternatives are defined interms of acquisition strategy for lease,buy, or elements of both if appropriate.
The processes and activities illustrated inFigures l-3 and 1-4 have beendecomposed into the five-stepmethodology illustrated in Figure 1-5.Referring to the figure, these stepsinclude:
1. Perform requirements analysis
2. Develop alternative technicalarchitectures
3. Define costs
4. Calculate and compare option life-cycle costs
5. Perform sensitivity analysis
Each step is described in detail in thefollowing sections of this methodologyreport.
Figure l-5 illustrates the relationshipbetween the five-step methodology, thehigh-level cost tradeoff processes(Figure l-3), and the generictelecommunications project phasesintroduced in Figure l-l.
Note that in general, one step does nothave to be completed before the nextstep begins. Note also that Step 4 forsome technical architecture alternativescould terminate before completion. Thiswould happen if the cost of onearchitecture is observed to greatlyexceed the total cost of other optionsbeing analyzed. At this point, a decisioncould be made to stop the accumulationof all costs for the expensive architecturealternative.
1.3 Report OrganizationThe five steps comprising the tradeoffanalysis methodology are described indetail in Sections 2 through 6,respectively.
1-6 12/16/96
Section 2 -Requirements
AnalysisThe most reliable and accurate way ofperforming cost tradeoff is to consideralternatives that accomplish similarobjectives. In terms of a systemsengineering approach for telecommuni-cations, that means that each technicalalternative must be based on the same setof requirements before the cost analysiscan be meaningful.
Once generated, requirements should bevalidated so that some degree of consen-sus on behalf of stakeholders can beachieved. Requirements should alsoremain as constant as practicalthroughout the project to avoid develop-ing the wrong solution or solutions for amoving target. This implies that theymust be documented and managed oversometimes long periods of time. Andfinally, the requirements must eventuallyprovide enough technical detail so thatthe communications engineer candevelop reasonably detailed technicalalternatives. Figure 2-l illustrates therecommended five-step requirementsanalysis methodology. Each step isdescribed in detail.
Identify ITS ProgramGoals, Objectives,and Requirements 01
Derive TechnicalRequirements 02
Document Requirements
03
Validate Requirements
04
Manage Requirements
05
Figure 2-l. RequirementsAnalysis Methodology
2-l 12/16/96
2.1 Step 1: Identify ITSProgram Goals, Objectivesand RequirementsTo be effective, requirements must ofcourse reflect the goals and objectives ofthe ITS that the telecommunicationsnetwork is intended to support.Requirements analysis for ITStelecommunications should then beginwith the formulation of ITS goals andobjectives by the ITS stakeholders. Thisis similar to the situation whereengineering and construction of newroadways and bridges cannot begin untilcareful planning and studies identifywho they will serve and where they willbe. Only then can the nature of thevehicles expected to travel over them be
identified. Likewise efficient telecom-munications networks must beimplemented with similar knowledge ofwho will be served and how by the ITSprogram. Only then can the characteris-tics of the data, video, and voice trafficthat must be transported be identifiedwith any certainty.
Figure 2-2 identifies three primarysources of ITS program information tobe tapped:
l Historical information.Technical exchange meetings
l Use Case analysis
ITS Goals and Objectives
Validate Information
Derive Technical
2-2 12/16/96
Figure 2-2. Identify ITS Program Goals, Objectives, and Requirements
2.1.1 Historical Information
A review of all historical informationpertaining to the ITS program’s goalsand objectives is the starting point forthe requirements analysis process.Information to be reviewed includes ITSprogram plans, feasibility studies,procurement documents, requests forinformation, technical presentations,related study reports, and minutes ofmeetings held. If a Benefit-CostAnalysis has been performed in supportof the ITS program goals, this will anexcellent source of information.
Specific to ITS applications, an impor-tant goal of the historical informationreview process will be the generation ofcomprehensive data tables. These tableswill summarize the technical functionsperformed by all existing and future fielddevices to be included in the system;physical access requirements or con-straints for each device type; the geo-graphic location of and spacing betweenthese devices; power requirements; envi-ronmental needs; and the timeline fordevice deployment.
If not already available, GeographicInformation System (GIS)-based scaledmaps and overlays illustrating facilitylocations, device placement on targetroadways should be prepared. Thedeployment timeline information is alsoa very important driver fortelecommunications. For example, thetelecommunications needed (and hencethe cost) to support the deployment of allplanned devices starting in the first yearof the life-cycle will certainly lookdifferent compared to one that supports astaggered device deployment strategy
whether it is by roadway, priority offunction or device, or any other means.
In addition to information review, otherfact-finding should occur. The program’sstakeholders should be interviewed face-to-face to obtain their assessment of theITS program goals and objectives.
When the relevant information has beenreviewed, a consolidated preliminary listof requirements should be prepared.Requirement statements should bewritten in precise and unambiguousterms. The preliminary list of require-ments should then be validated by theprogram’s stakeholders, users, andprogram office.
2.1.2 Technical ExchangeMeetings
Diverse technical groups are available toprovide input, guidance, and to assist inthe identification and/or validation ofITS program-level requirements. Thesegroups may comprise the stakeholdersand typically include:
l Senior management
l ITS organizations
l ITS consultants
l Traffic engineers
l Construction engineers. Information Systems/InformationTechnology (IS/IT) groups
l Users and Operators
Table 2-l summarizes the informationand support that is likely to be obtainedfrom these groups. As program-level
2-3 12/16/96
For each Use Case scenario selected foranalysis, ITS users and operators, theirlocation, and associated devices andsystems are identified. Users andoperators are then asked, as a group, todefine how the interaction between usersand devices and systems should occurover time for each scenario. Specificquestions to be answered include:
How are components of the ITSused?
What is the user’s job?
What informationneed?
With whom/whatinteract?
does the user
does the user
In summary, Use Case analysis identifiesthe target functions or missions, capturesthe information required by each personto accomplish the function or mission,outlines necessary interaction with aninformation processing or technologysystem, and superimposes these along atimeline of events.
The Use Case analysis results can beeffectively presented graphically in theform of data flows. These data flowscan accurately describe a number ofimportant requirements issues. Examplesare how traffic, weather and pavementcondition information will be consumed,how soon and how often it is needed,how closed circuit television (CCTV)will be used and what needs to be seen,what quality and timeliness of video isneeded, which facilities require videomonitoring and the number of monitorsthat will be viewed simultaneously ineach facility, provisions for selectingimages and arbitrating cameraPan/Tilt/Zoom (P/T/Z), and what will be
viewed with cameras (e.g., incidents,road and/or weather conditions,maintenance objects, etc.).
Other Use Case scenarios can be definedto assist in developing strategies fordegraded modes of operation anddisaster recovery as needed. Forexample, the primary ITS control facilitycould become unavailable for manyreasons, including loss of externalcommunications, fire, sprinkler, flood,earthquake, or other hazard conditionsmaking the building or parts of itinoperable. With the aid of Use Casescenarios, the allocation of functions toalternate facilities, the associatedalternate routing of data, video, voice,and control over the telecommunicationsnetwork to these facilities, and theallowable elapsed time between failureand the initiation of degraded operationsfunctionality can be defined in astructured manner.
The documented results of each UseCase analysis should be reviewed andvalidated by the same personnel thatprovided the input data.
2.2 Step 2: DeriveTelecommunicationsRequirementsFor convenience, the telecommunicationsrequirements are generally assignedto requirement types. Requirement typesto be considered include:
1. Functional
2. Operational
3. Performance
Functional requirements identify what is to be done. Communications and
2-5 12/16 /96
information security requirementsconstitute a possible subset of functionalrequirements.
Operational requirements identify whoor what performs the function, where thefunction is performed, how manyperform the function, and when it isperformed. Physical security andinformation security proceduresrequirements constitute a possible subsetof functional requirements.
Performance requirements quantifymeasures such as how much and/or howoften, and/or how fast. Reliability,Maintainability, and Availability (RMA)requirements constitute a possible subsetof performance requirements.
The program-level requirements and theresults of the Use Case analysis must beanalyzed and translated into terms thatcommunications engineers can use toderive technical architectures. Video,data, voice, LAN, RMA, and security arerecommended architectural componentsthat should be derived from the program-level requirements.
Video - Program-level requirementsshould identify the number and locationsof the CCTV devices, video quality andmotion requirements, and the locationsof some but not necessarily all of theconsumers of video. From the Use Caseanalysis results, the followingcommunications requirements can bederived: the location of all consumers ofvideo; the number of images to beviewed simultaneously at each location;all locations that will select and controlthe video, and the maximum number ofimages to be transmitted between anytwo facilities, and the directionality ofvideo.
The video data rate (kilobits persecond/megabits per second[Kbps/Mbps] per image) can be derivedfrom the program-level video quality andmotion requirements.
Data - Program-level requirementsshould identify those device types thatwill be polled for status and/or data,those that will automatically transmitdata at pre-specified intervals, and thosethat will transmit data on an exceptionbasis only. Through analysis, theserequirements can be decomposed intoderived communications performancerequirements identifying: polling fre-quency; fixed data transmissionfrequency (where applicable), averageand maximum exception-based frequen-cies (where applicable); format and sizeof the status and data messages for eachdevice type; and the maximumallowable time to transmit eachmessage. The message size and timingrequirements can be further decomposedinto transmission rates (Kbps, Mbps) permessage.
Program-level requirements should alsoidentify who (which location) willprogram the traveler informationdevices. Through analysis, theserequirements can be decomposed intoderived communications performancerequirements identifying: the maximumfrequency at which a given device willbe programmed from each location; theformat and size of the data messagesexchanged for each device type; and themaximum allowable time to transmiteach message. The message size andtiming requirements can be furtherdecomposed into transmission rates(Kbps, Mbps) per message exchanged.
2-6 12 /16 /96
Voice - Program-level voice communi-cations functional and operationalrequirements can be decomposed intolower-level derived communicationsrequirements. A program-levelfunctional requirement could state thatvoice communications are required atcertain types of device sites and abilityto communicate with certain facilities orother field sites is needed. Derived tele-communications requirements for voiceshould include number of simultaneouscalls, voice quality, store and forwardfunctions and other voice related techni-cal needs.
LAN - Since most ITS systems willinclude Workgroup or enterprise LANinfrastructure for hosting operator func-tions, LAN functional and performancerequirements should be defined. LANinterconnectivity and interfaces, sizingfor LAN-based storage, LAN bandwidth,client-to-server response time to accessdata and download applications may bepertinent.
RMA - Network availability, av,defines the percentage of time during agiven period (day, week, month, year)that the telecommunications network isoperational. At the requirementsdefinition stage, availability may bestated as a goal, associated with somemeasure of overall effectiveness (e.g.,how it would provide for the publicsafety). At the technical architecturedevelopment stage, availability can beestimated using representativeconfiguration and equipment. It may notbe possible to completely ascertain if thegoal can be achieved until thepreliminary design stage where actualconfiguration and equipmentspecifications are used.
Network reliability, maintainability, andavailability are inter-related. Networkreliability, expressed in terms of themean time between failures (MTBF),defines how often, on average, thenetwork fails. Maintainability,expressed in terms of the mean time torepair (MTTR), defines how fast, onaverage, the network is returned tooperational status after a failure.Aailability is a function of the networkMTBF and MTTR:
av = MTBF/(MTBF+MTTR).
The merits (including life cycle costs) ofa particular network availability shouldbe weighed against the predicted orhistorical availability of the trafficmanagement devices. For example,assume that the availability goal is99.9%, and an initial estimate of thenetwork architecture’s availability is99.0%, and the average availability ofdevices is 99.2%. In this case, anincrease in the availability goal might becontemplated. On the other hand, if theavailability of the devices is 98%, anyfunds expended on enhancing theavailability of the network may not bewarranted since marginal gains at bestwould be accrued.
At the technical architecturedevelopment stage, network availabilitymay be increased in several ways.Research can be broadened to identifycandidate hardware components withimproved M T B F a n d MTTRcharacteristics. Alternatively, availabilitycan be increased by adding redundanthardware components in strategiclocations, or making the system faulttolerant if necessary. Redundancy isachieved by having standby hardwareand/or services available for use when
2-7 12/16/96
needed in strategic locations within thenetwork. When a failure occurs, aredundant system can be reconfiguredwithin a finite period of time and a fullor degraded mode operation can resume.
Fault tolerance is achieved by havingredundant “hot backup” hardwareand/or leased services available andready for instantaneous switchover whennecessary. With this type ofconfiguration, switchover is transparentand no interruptions in service areencountered.
Both approaches to increasing systemavailability will increase life cycleprocurement and operations andmaintenance costs. Depending on thesize and complexity of the network, afault tolerant approach could have aprohibitive price tag. As noted above,the additional effectiveness must alwaysoutweigh the cost.
Security - Security requirements can bederived by analyzing the threats to theITS telecommunications network thatcould impact public safety as a result ofnetwork failure and/or misuse. Thesethreats could be in the form of sabotage,unauthorized network access and misuse,tapping and listening, modification,destruction, interception, and loss ofdata. Program-level functional securityrequirements can be decomposed intolower-level derived requirements. Forexample, after analysis of the program-level security requirements it may bedeemed necessary to encrypt some datatypes. Telecommunications functionalrequirements to encrypt the data on thesending end and to decrypt the data onthe receiving end would then be derived.If access to network resources is to berestricted to certain groups of individu-
als, then lower-level requirements wouldbe derived. Derived requirements wouldstate how the access is to be restricted(e.g., use of specific workstations and/orassignment of user names andpasswords). Derived operationalrequirements would state when actionsare to be performed (e.g., require users tochange passwords once per month).
2.3 Step 3: DocumentRequirementsEach program-level and derivedtelecommunications requirement shouldbe assigned to the appropriaterequirement type (e.g., functional,operational, etc.). For each type ofrequirement, . each high-levelrequirement should be assigned a uniqueidentifier. A simple numbering schemewill generally be sufficient.
Each requirement statement should beconcise as possible, and unambiguous.By convention, requirement statementsare drafted using the verb “shall.” Agiven requirement statement can be sub-divided into two or more clearly-identified parts. Also, a requirementstatement can reference a table or tablesthat contain detailed information. Thisis normally done to reduce the size andcomplexity of the requirement statement.
Any requirement that was derived from ahigh-level requirement should retain theidentifier of the parent as part if itsidentifier. For example, assume that twoperformance requirements were derivedfrom performance requirement 24.Identifiers 24.1 and 24.2 could beassigned to the derived requirements.
Table 2-3 is a table of hypotheticalprogram-level requirements sorted by
2-8 12/16/96
requirement type and identifier within 2-4 and 2-5, respectively). Note also thatthe type. Note that functional deployment requirements 35, 40, and 43,requirement statements 3 and 4 each and operational requirement 96 all havereference different external tables (Table multiple lettered parts.
Table 2-3. Hypothetical Program-Level Requirements
ID Type Requirement
3 Functional Field traffic and roadway monitoring devices shall be deployedand perform the functions specified in Table 2-4.
4 Functional Traveler information devices shall be deployed and perform thefunctions specified in Table 2-5.
7 Functional Voice communications shall be provided at field device sites foruse by field maintenance personnel.
35 Operational
40 Operational
Detectors shall be spaced along the roadway using the followingguidelines:
a. in urban areas with non-recurring congestion, l/2 mile
b. in urban areas with recurring congestion, 1 l/2 miles
c. in rural areas, greater than 1 l/2 miles.
Devices to be deployed in future years shall be locatedgeographically in accordance with the most current revisions ofthe following maps and associated overlays:
a. for roadway X, refer to map 24
b. for roadway Y, refer to maps 16 and 32
c. for roadway Z, refer to maps 47,53, and 62.
2-9 12/16/96
Table 2-3. Hypothetical Program-Level Requirements (Cont’d)
ID
43
78
83
96
Operational
Operational
Operational
Operational
Requirement
Devices shall be deployed in the field in accordance with thefollowing scheduling guidelines:
a. priority 1 devices, within one year
b. priority 2 devices, within 1 to 3 years
c. priority 3 devices, between 3 and 7 years.
Overhead Traffic Detector (OTD) devices will report on anexception basis.
Road and Weather Information Systems (RWIS) devices will bepolled for data.
The following facilities shall receive ITS video data
a. Traffic Operations Centers (7)
b. Freeway Management Centers (2)
c. administrative facilities (15)
d. maintenance facilities (26)
e. other jurisdiction XYZ
1. facility #3
2. facility #7
3. facility #15
These techniques aid in reducing thetotal number of requirement statementswithout impacting critical information.
Table 2-4 is a table of hypothetical de-rived telecommunications requirements.Referring to the table, functionalrequirements 4, 5, and 7 are examples oflower-level requirements that are derivedfrom a high-level requirement.
The initial complete lists of program-level and telecommunications require-
ments are terrned the PreliminaryRequirements Baseline.
2.4 Step 4: ValidateRequirementsThe Preliminary Requirements Baselineshould be submitted for review by repre-sentatives of the appropriate funding,operating, and user organizations.Following the incorporation of reviewcomments, the Final Requirements
2-10 12/16/96
Baseline should be formally publishedand distributed.
2.5 Step 5: ManageRequirementsAs noted earlier, some requirements canbe expected to change as the programmatures and responds to external events.
If it becomes necessary to modify ordelete any requirements in the currentversion of the Requirement Baseline, oradd new requirements, a revised baselineshould be published, validated, and dis-tributed.
Tab/e 2-4. Hypothetical Derived Telecommunications Requirements
I D Type Requirement
2 Functional The network shall be capable of monitoring the status of fieldand roadway monitoring devices.
3 Functional CCTV images shall be digitized and compressed fortransmission.
4 Functional The network shall be capable of selecting, viewing, and P/T/Zcontrol of connected CCTV devices.
Functional The Traffic Operations Center shall be capable of selecting,viewing, and P/T./Z control of any CCTV connected to thenetwork
4.2 Functional The following facilities shall be capable of selecting, viewing,and P/T/Z control of CCTV devices within their respective areasof responsibility:
a. administrative facilities
b. maintenance facilities
5 Functional The network shall support the handoff and arbitration of P/T/Zcontrol of CCTV devices.
Functional The Traffic Operations Center shall be capable of handoff andarbitration of P/T/Z control of all CCTV devices.
5.2 Functional The following facilities shall be capable of handoff andarbitration of P/T/Z control of CCTV devices within theirrespective areas of responsibility:
a. administrative facilities
b. maintenance facilities
2-11 12/16/96
Table 2-4. Hypothetical Derived Telecommunications Requirements(Cont’d)
rID Type Requirement
7 Functional The network shall support the following functions associatedwith the VMS, TAR, and Dynamic Traveler Alert Sign devices:
a. arbitrate access
b. programming
c. auditing
7.1 Functional The Traffic Operations Center shall program all VMS, TAR, andDynamic Traveler Alert Sign devices.
7.2 Functional The maintenance facilities shall program the VMS, TAR, andDynamic Traveler Alert Sign devices within their areas ofresponsibility.
3 Performance CCTV images shall be compressed to a frame rate of 15 framesper second and transmitted at a rate of 384 Kbps.
4 Performance The network shall distribute CCTV images for simultaneousviewing at the designated facilities:
1. Traffic Operations Center - 16 images from any CCTV site,with no more than 7 from any one administrative facility
2. administrative facilities - 7 out of the total number of CCTVsites within the area of responsibility
3. maintenance facilities - 1 out of the total number of CCTVsites within the area of responsibility
4. other jurisdiction ABC - 1 image.
111 Performance ODT controllers shall be polled for status (up/down) at a rate ofup to once per minute.
112 Performance ODT data records are 50 K bytes long.
2 RMA The network shall achieve an availability of 0.98.
6 RMA The network mean time to repair (MTTR) shall not exceed 3.0 hours.
4 Security Network access shall be controlled by assigned user names andpasswords.
2-12 12/16 /96
Section 3 - DevelopingAlternative TechnicalArchitecturesKey to the lease versus own issue is firstknowing what kind of telecommunica-tions network is needed regardless ofhow it is obtained. A solution that iseither over engineered or under engi-neered will never completely satisfy allstakeholders from cost or technicalstandpoints. Lease or own should besecondary to describing the telecommu-nications approach that best meets thedocumented need. Once this is done,how to achieve the desired solution atthe lowest possible cost should beconsidered with respect to lease versuso w n .
Key to finding the right technicalsolution at the lowest cost is thedevelopment of multiple alternatives.The correct number of alternatives todevelop depends on the specific issuesand constraints present, as well as timeand funds available for the project. Aminimum of three to four alternativeswith substantial technical differenceswill increase the chances of finding thebest alternative. Consideration ofalternatives based on: 1) the commercialinfrastructure in place, 2) an optimalbuild technique, and 3) combinations ofthe two, will increase the chances offinding the most cost-effectivealternative.
The recommended approach todeveloping technical alternatives isbased on the concept of “technicalarchitecture.” A technical architectureincludes enough technical detail to allowlife-cycle costs to be accuratelypredicted while still allowing the
communications designer flexibility inchoosing specific products and servicesfor implementation later in the project.
The level of technical detail included is acompromise between the time spent andthe risk of severely under estimating oroverestimating costs. For a complexstatewide telecommunications networkto support ITS functions, devices, andsystems, a period of 4 - 6 months shouldbe sufficient for developing severaltechnical architecture alternatives.
Although cost is the major focus of thismethodology, once viable alternativesare identified and developed, they can beevaluated with regard to severalsubjective factors in addition to cost.These factors include schedule risk thatwill be incurred as a result ofimplementing each alternative, relativeease of implementation, ease of use andmaintenance, security, overall capacityconsiderations, and technical maturityand obsolescence factors as well as othersubjective engineering criteria.
This section defines the recommendedapproach to developing technicalalternatives that can be used toaccurately predict the life-cycle cost ofdeploying and sustaining a complex ITStelecommunications network throughlease, own, or lease/own hybridapproaches.
3.1 Characteristics of aTechnical ArchitectureAlternativeAn alternative technical architecture canbe completely described by fourcharacteristics:
l Standards and Technology
3-l 12/16/96
Each technology or combination oftechnologies should be evaluated todetermine if and how well it meets thefunctional and performance requirementsfor each architectural component andwhat the cost impacts of using aparticular technology will be over the lifecycle compared to other technologies.Relative advantages and disadvantagesshould be stated and evaluated withrespect to specific technical criteria.Evaluation of the governing standardshould be performed to measure thedegree of technical maturity andinteroperability between vendorsproviding the product or service thatimplements the technology.
Physical topology - topology describesthe relative placement and interconnec-
necessary components of the ITSnetwork. This includes field traffic man-agement devices and communicationselectronics, telecommunications networkswitching equipment, computer systems,and operations personnel at the manage-ment facilities together. Two basictopologies should be considered: allcommunications from field locationscentralized on a single site, and commu-nications decentralized utilizing hublocations other than the central site. Fora decentralized topology, the definitionof a telecommunications backbone andfeeder links should be performed.
Figures 3-2 and 3-3 show conceptualviews of centralized and decentralizedtopologies. Table 3-2 shows advantagesand disadvantages of telecommunications
tivity strategy for linking all the network topologies.
Field
I FieldElectronics
Figure 3-2. Centralized Topology
3-3 12/17/96
Figure 3-3. Decentralized Topology
Table 3-2. Advantages and Disadvantages of Network Topologies
Centralized l Easier to maintainl Conceptually simple
configurationl Maximum amount of
control for central site
l Single point of failure concernsl More capacity, connections, and
circuit miles required if leasedl Excessive amount of equipment
at central sitel All video must be brought to
central site for switchingl Not scalable
Decentralizedl Not accessible from other sites
l Scaleability . Higher technical complexityl Shortens higher
bandwidth circuits andavoids long-distance tollsif leased
l Can be accessed frommultiple sites
3-4 12/17/96
technology are incorporated into thetelecommunications network. Criticalinterfaces to the telecommunicationsnetwork from ITS field devices and thecontrol system’s computers and LANsare defined. Table 3-4 provides otherTechnology Implementation examplesthat should be considered duringalternatives development. All may not bepertinent depending on the choice oftechnologies for the architecturealternatives.
Table 3-4. Examples ofTechnology Implementation
Strategy
l Incorporation of redundancy andfault tolerance into thetelecommunications architecture
l Virtual and physical channelizationof switched facilities (e.g., TDM,ATM, SONET switches and/orfacilities)
l How carrier circuits might beaggregated at central office or otherprovider sites
l The application of available Qualityof Service and traffic categories
l How the network will be managed(e.g., provisioned, diagnosed, andrestored to and from built-inredundant capacity)
3.2 Development ofAlternative TechnicalArchitecturesThe development of alternative technicalarchitectures should be influenced bytwo major factors. First are thedocumented and validated requirements.The technical architecture steptransforms both the stated and derivedrequirements into something that can beassigned a cost for comparative analysis.Second are the inevitable issues andconstraints that are present internally andexternally to the state or localgovernment agency charged withdeploying the telecommunicationsnetwork.
Issues and constraints vary withjurisdiction but among those that caninfluence telecommunications technicalarchitecture and should be consideredinclude:
Funding - what level of funding isavailable for the ITS program? Whatpercentage of this has been allocated forthe telecommunications network? Forthe network’s operations, maintenance,and sustaining engineering.
Schedule - what are the schedule driversfor deployment of the telecommunica-tions network?
Institutional/political - what are therelevant institutional issues that impacthow the telecommunications networkwill be deployed? Are there one or moreexisting or planned future telecommuni-cations networks that link some or all ofthe facilities or geographic areas to beinterconnected by the ITS network? Ifso, can overall life-cycle costs bereduced by integrating these networks
3-6 12/16/96
into the ITS network? Do other agenciesor jurisdictions have sources of ITS-related video or data that are consistentwith the goals and objective of the ITSprogram? If so, is it technically feasibleto collaborate with these agencies?What is the net life-cycle cost differenceof such collaboration? Is there existingor planned future wireline or wirelesstelecommunications transmission capac-ity that could be made available througheither a barter agreement or cash througha monetary agreement for right-of-way?If so, is it technically feasible and cost-effective to utilize this capacity? Is darkfiber available? If so, what is the net life-cycle cost difference of integrating itinto the telecommunications network?
Geographic - Does the ITS devicepopulation density profile within thejurisdiction or the jurisdiction’s actualgeography and/or population profiledrive meaningful options on lease/buyhybrids that may yield lower costs?
Another key factor that should beconsidered during technical architecturealternatives development is the existingor planned information systemsarchitecture. Analysis of where the datashould be received, stored and processedin order to minimize thecommunications load, optimizeutilization, minimize initial andrecurring cost, and increase systemaccuracy, responsiveness, and perform-ance is a critical dependency to thetelecommunications network’s architec-ture and should be carefully examined.
At a more detailed level, the definitionof communications device spacing orclustering along roadways and/or aroundprovider points-of-presence should be
undertaken with the goal of minimizingtelecommunications cost,
3.3 Products of theTechnical AlternativesDevelopmentThe products of alternative technicalarchitecture development should includeat a minimum, a strawman configurationdrawing for each alternative. Anitemized list of representative buildingblocks that comprise the alternative’simplementation in the cost model shouldalso be produced. A strawman drawingis shown in Figure 3-4.
3-7 12/16/96
Section 4 - DefineCosts
The ultimate focus of cost tradeoffanalysis is the development of life cyclecost models for communications archi-tecture options to support managementdecision making. Considerable effortshould be allocated to the definition anda strategy for accumulation ofcomponent costs for the communicationsarchitecture options that have beenidentified.
Communications-related costs can begrouped into five cost elementsincluding:
1.
2.
3.
4.
5.
Construction - roadside enclosuresand cable plant installation (whereappropriate) for both build and leaseportions of all options.
Leased circuits - installation ofcommercial telecommunicationslines and recurring service andmaintenance of these lines.
Communications equipment - rep-resentative electronics and commu-nications hardware and computersthat would support data, video, andvoice transport.
Communications OAM&P labor -operations, administration, mainte-nance, and provisioning. Full-timeand on-call labor to operate, control,configure, administer, troubleshoot,provide spares, and repair communi-cations electronics and hardware.
Communications software - soft-ware to manage the collection,delivery, and distribution ofCHART data and information.
Note that in some applications, the basicstrategy used for accumulation ofcomponent costs can be a top-downapproach starting with those that wouldmost likely comprise the largest share ofthe total cost for each architectureoption. Based on this rationale, esti-mates for one or more “key” costelements, e.g., construction and leasedcircuit costs, might be identified andaccumulated first for all options,followed by communications OAM&Plabor costs, communications equipmentcosts, and finally communications soft-ware costs.
By using this strategy and order ofaccumulation, if any one option accumu-lated all components of cost and resultsin a total cost less than another optionwhose costs are not fully accumulated,accumulation of further costing may notbe needed for the higher cost option.
Sections 4.1 through 4.5 decomposeeach cost element into cost parametersand present the potential sources of costinformation.
4.1 Construction CostsThe construction cost element includes:
1. Backbone infrastructure
2. Device connections
3. Environmental enclosures
Backbone infrastructure and device con-nections are applicable to the build andhybrid acquisition options. Environ-mental enclosures can be found for allacquisition options, including lease.
Backbone infrastructure generallyconsists of copper or multiple strandfiber optic cable installed via a multiduct
4-1 12/16/96
for environmental enclosures at camerasites.
A recommended methodology for devel-oping the life-cycle construction costs ispresented in Section 4.1.1. Constructioncost parameters are summarized inSection 4.1.2.
4.1 .1 Construction CostDevelopment Methodology
The following three-step process isrecommended to efficiently developconstruction cost estimates. Thesequence is:
1. Identify applicable constructionmethods and parameters.*
2. Develop engineering parameters andcosts.
3. Derive schedules
4. Calculate life-cycle construction costfor all options.
* These steps will be performed inparallel
Identify applicable constructionmethods and parameters - Thecommunications backbone can beconstructed using one or more methodsthat are usually site specific to provide alow cost, fully engineeredcommunications solution. Some of thesemethods are:
. Backbone trenched with cable in aduct
l Backbone plowed with direct buried,armored cable
l Backbone jacked (bored) with cablein a duct
Backbone directional drilled withcable in a duct
Backbone trenched with directburied, armored cable
Backbone placed aerially with lashedor figure 8 cable
Backbone placed on a longitudinalbridge structure with cable in a duct
The construction methods to use, thepercent of the total construction antici-pated for each method, and the averageproductivity rate (miles per month) foreach method must be identified. Otherengineering parameters such as thedesired spacing between manholes, thetype of conduit, and in the case of fiberoptic backbones, fiber optic cable modeand strand count must also be deter-mined.
The locations of device sites relative tothe backbone segments and points-of-presence (POPS) to which they will beconnected are also needed.
Develop engineering parameters andcosts - The construction methods to useand the percent of the total constructionanticipated for each method can beobtained in-house and/or from engineer-ing consultants. These sources can alsoprovide other important engineeringparameters such as the desired spacingbetween manholes, the type of conduit,and fiber optic cable mode and strandcount.
The locations of device sites relative tothe backbone segments and POPs towhich they will be connected can beobtained from ITS program-suppliedGeographic Information System (GIS)-generated maps. Ideally, these maps willbe available in digital format. If so,
4-3 12/16/96
along-road and cross-road distancesfrom each device site to the backbonePOP can be calculated automatically.An overall average along-road and cross-road distance for each road segment canthen be calculated and used for costingpurposes.
If digitized maps are not available, thensupport from in-house engineeringpersonnel and/or engineering consultantsmay be needed to select “not to beexceeded” estimates of the deviceconnection metrics.
The locations of the facilities to beconnected to the network should beknown exactly, with the possibleexception of the location of the POPS forexternal interfaces. This information willbe established through coordination withthe external organizations.
Unit cost information must be obtainedfor all applicable construction servicesand hardware. These items include:
Backbone construction ($/mile foreach construction method used)
Furnish and install (F&I) manholes,handholes, fiber optic junction/spliceblocks, and environmentalenclosures ($/unit)
F&I conduit ($/foot for each type ofconduit used)
F&I cable ($/foot for each type ofcable used) [for fiber opticbackbones, mode-strand count com-binations]
For fiber optic backbones, F&I fiberoptic converters ($/unit).
Potential sources for the required unitcosts include in-house and/or consultantengineering personnel, bid pricing and
historical project data, and vendorquotations.
Derive schedules - Construction sched-ules will be coupled with the ITS pro-gram schedules. Ideally, preliminaryconstruction start and end dates will beknown for each road segment. Wherethis is true, the planned percentage ofconstruction to be completed per life-cycle year will be known. If either theplanned construction start or end datesare not known, the project duration canbe estimated by assuming constructionproductivity rates (e.g., average milesper week or month) based on the plannedconstruction methods. Given the projectduration, the unknown start or stop datecan then be derived.
Calculate life-cycle construction costsfor all options - The backboneinfrastructure cost is the total of the costincurred by the:
Construction methods ($/mile *number of miles for eachconstruction method used)
Cable F&I cost ($/foot * number offeet[including slack])
Conduit F&I cost ($/feet * numberof feet)
F&I cost for all of the related supportcomponents including manholes,handholes, and junction/splice blocks($/unit * number of units for eachcomponent).
The device connection cost is the total ofthe cost incurred by the:
l Construction methods ($/mile *number of miles for eachconstruction method used).
4-4 12/16/96
l Cable F&I cost ($/foot * number offeet[including slack])
l Conduit F&I cost ($/feet * numberof feet)
l F&I cost for fiber optic converters($/unit * number of units).
The environmental enclosure F&I cost isthe product of the enclosure unit cost andnumber of units purchased.
The costs for each construction projectcan be distributed across the life cycleusing the schedule information describedin the previous step. The total cost life-cycle cost of the construction element isthe sum of the backbone infrastructure,device connection, and environmentalenclosure life-cycle costs for allconstruction projects.
4.1.2 Construction CostParameter Summary
4.1.2.1 Backbone InfrastructureCost Parameter Summary
Infrastructure cost parameters commonto all fiber optic backbones include:
Applicable construction methods andunit costs (e.g., per mile) for thesemethods
Average productivity rate for eachconstruction method used
Communications handhole F&I unitcost
Manhole F&I unit cost
Cable splice block with enclosureF&I unit cost
Cable F&I unit cost
Conduit F&I unit cost.
Cost parameters that could vary fromroad segment to road segment include:
Number of backbone miles
Planned construction start date
Percent of total construction for eachconstruction method to be used.
Average distance betweencommunications handholes
Average distance between manholes
Average distance between cablesplice blocks with enclosures
Segment construction schedule.
4.1.2.2 Device Connection CostParameter Summary
Device connection cost parametersinclude:. Cross-road (perpendicular to road)
and along-road (parallel to the road)distance from the device site to thebackbone, if known on a site-by sitebasis. Estimated or computed averagecross-road and along-road distancefrom a device site to the backbone, ifexact distances are not known on asite-by site basis
l. Number of device sites to connect tothe backbone. Preferred construction method (andassociated unit costs) or anticipateddistribution of construction methods(by percent) for trenching and layingdevice connection feeder cable. For fiber opticunit cost F&Iconverters.
backbones, the per-cost of fiber optic
4-5 12/16/96
4.1.2.3 Environmental EnclosureCost Parameter Summary
Environmental enclosure cost parametersinclude:
. Environmental enclosure F&I unitcost
l Number of environmental enclosuresrequired.
4.2 Leased Circuit CostsThe leased circuit cost element includesone-time charges, fixed recurringcharges, and variable recurring usagecosts for various types of service. Thiselement applies to the lease and hybridacquisition options.
A methodology for developing the life-cycle leased circuit costs is presented inSection 4.2.1. Leased circuit costparameters are summarized in Section4.2.2.
4.2.1 Leased Circuit CostDevelopment Methodology
The following seven-step processsystematically develops leased circuitcost estimates. The sequence is :
1. Assign leased link identifiers.
2. Assign candidate types of service toeach leased link.
3. Solicit cost estimates from serviceproviders.
4. Analyze cost data.*
5. Develop final link configurations.*
6. Derive circuit activation schedules.*
7. Calculate life-cycle leased circuitcosts.
* These steps could be performed inparallel.
Assign leased link identifiers - Acommunications link is described by aunique pair of “from” and “to”locations. These locations can be fielddevice sites, state or local governmentfacilities, facilities of other groups thatconsume ITS information, and serviceprovider POPS. A given link could be“owned” in some options and leased inothers. Some links will be common tomany options and others may apply tofew options. Communications links forall options and the anticipated loads onthese links will be available when linkload analysis has been completed.
It is recommended that an alphanumericidentification scheme be devised tologically distinguish leased tail circuitsfrom leased backbone circuits. Forexample, tail circuit identifiers couldbegin with a “T” and backbone circuitswith a “B.” Tabulate the leased links forall options. Review the tabulations andflag the links that are common to two ormore options. These links should beassigned the same unique identifier. Theremaining links can then be assignedidentifiers. It is strongly recommendedthat a computer database of the linkparameters including the unique identifi-ers be developed and maintained tofacilitate computer-aided life cycle costcalculations.
Assign candidate types of service toeach link - There are many types ofservice to be investigated. Examplesinclude:
l Analog POTS
l Dedicated Digital ( e.g., 2.4 Kbps,9.6 Kbps)
4-6 12/16/96
l Dedicated Digital Tl
l ISDN
The appropriate type of service for agiven link may be a function of multiplefactors including:
1.
2.
3.
Device type (for circuits connectingdevices to the network)
Maximum data load on the circuit
Polling frequency (for circuitsconnecting polled devices to thenetwork).
Note that device polling could be asignificant cost factor and should not beignored. For example, selection of aPOTS line for a given circuit could yieldsignificantly lower fixed recurringcharges when compared to a 2.4 or 9.6-Kbps dedicated digital line. However,when the variable recurring cost for afrequently-polled (e.g., once per minute)device is added, the total POTS costcould be many times greater than thetotal cost of the dedicated digital service.
Having selected the type of service foreach link, quantify the number of linesrequired to support the maximum loadpredicted by the link load analysis.Update the link database to include theassignments of type of service andnumber of lines.
Solicit cost estimates from serviceproviders - In the short term, someuseful leased circuit cost data might begleaned from current actual costs and/orprevailing tariffs. However, for life-cycle costing that extends beyond two orthree years in the future, it is stronglyrecommended that a proactive stance betaken by soliciting and obtaining quotesdirectly from potential service providers.
A wide cross-section of serviceproviders should be approached withnetwork requirements, a limited numberof representative technical architectures,the link definitions and candidate typesof service. The intent is to have theproviders attempt to optimize thecandidate architectures (or proposevariations in these architectures) toachieve implementations that they canprovide competitively and to provide(possibly proprietary) cost data. Theproviders should be assured that proprie-tary cost data will not be disclosed.
Required cost data includes one-timecharges (e.g., per-line installationcharges), fixed recurring charges (e.g.,the monthly charge for dedicated Tlservice), and variable recurring charges(e.g., per call or per message charge). Itis desired that the pricing estimates willbe non-tariffed and applicable for theduration of the communications networklife cycle.
Analyze cost data - Ideally, manyservice providers will supply non-tariffed cost data for each link and typeof service pair. The analyst shouldidentify the quotes that give the best“bang for the buck” over thecommunications network life cycle andstore the fixed and recurring costinformation in the link database.
If it is not possible to obtain the non-tariffed rates, the tariffed rates can beused as for the initial cost comparisons.Then, as part of the sensitivity analysisdiscussed in Section 6, the nominal ratescan be scaled lower to reflect economiesof scale or anticipated price reductionsor discounts that would be forthcomingas part of a large-scale or Statewideprocurement.
4-7 12/16/96
Develop final link configurations -Review the initial assignments of type ofservice to each leased links. Verify thatthis is the most cost-efficient servicebased on analysis of the cost datareceived from the service providers.Where appropriate, change the type ofservice designation and required numberof lines for that service. Update the linkdatabase to include any revisions to typeof service and/or number of linesrequired for that service.
Derive circuit activation schedules -Leased circuit activation schedules willbe coupled with the ITS programschedules. Leased tail circuits for exist-ing device sites will be available foractivation during the first life cycle year.Leased tail circuits for future device siteswill be available for activation as thesesites are deployed.
Critical leased backbone circuits (e.g.,circuits connecting major facilities) willlikely be activated early in the networklife cycle. Less-critical circuits will beactivated as the need arises.
If firm program circuit activationschedule data is not available, it will benecessary to make scheduling assump-tions and to document theseassumptions.
The link database should be updated toinclude a life-cycle activation year foreach type of service and number of linesfor that link. Year could be specified asabsolute (e.g., 1997) or relative to thecommunications network life cycle(e.g., 1 for the first year of the life cycle,5 for the fifth year of the life cycle, etc.).
Calculate life-cycle leased circuit costs- The total life-cycle cost of the leasedcircuit element for a given option is the
sum of the one-time, fixed recurring, andvariable recurring life-cycle costs of allleased circuits identified for that option.
4.2.2 Summary of Leased CircuitCost Parameters
The cost parameters common to allcommunications links include:
l Geographic locations of theconnecting end points
l Type of service required
l Number of lines (circuits) per type ofservice
l Polling frequency (if polled devicesare connected by the circuits)
l Circuit activation schedule.
The cost parameters associated with agiven type of service include:
l One-time charge incurred per circuitinstallation
l Fixed monthly recurring charge(applies to distance-insensitive anddedicated distance-sensitive services)
l Variable monthly recurring usagecharge, e.g., per call, per messageunit (applies to distance-insensitiveand distance-sensitive services).
4.3 CommunicationsEquipment CostsThe task of estimating networkequipment costs for the networkacquisition options may require severaliterations depending on the complexityof the options. A methodology fordeveloping the desired equipment costsis presented in Section 4.3.1. Thenetwork equipment cost parameters aresummarized in Section 4.3.2.
4-8 12/16/96
4.3.1 Cost DevelopmentMethodology
The following three-step processsummarizes the recommended approachto systematically develop networkequipment cost estimates. The processencompasses the market survey andsystem architecture activities necessaryto determine a baseline equipment listfor each option. The sequence is :
1.
2.
3.
4.
5.
Perform a market survey
Develop a representative networklayout
Define sparing strategy
Derive schedules
Calculate life-cycle networkequipment costs
Perform a market survey - Perform amodest amount of market survey(equipment manufacturers and resellers)to identify representative make andmodel products which could satisfy thetechnical architectures that have beenidentified.
Develop a representative networklayout - Develop a representativenetwork layout based on the relevantequipment types to determine theappropriate equipment models andquantities needed to match deploymentto the locations identified for eacharchitectural option. Create a sampleequipment configuration for eachdistinct model, verify equipmentconfiguration with a vendorrepresentative and obtain purchase costand lease cost (where applicable)information from a manufacturer orreseller, or through market survey ifproduct is a commodity item
It may be necessary in some cases toderive and cost “custom” equipmentconfigurations that are tailored to meetspecific requirements. For example, thevendor might provide the cost of adevice with x number of ports, and whatis needed is the same device withy ports(y>x). The cost of the y-port “model”would be estimated using vendor-supplied per-port costs.
It is strongly recommended that a com-puter database of network equipmentpurchase and lease cost parameters bedeveloped and maintained to facilitatecomputer-aided life-cycle cost calcula-tions.
Define sparing strategy - Spare equip-ment must be readily available if the net-work is to be maintained in a timelymanner. Alternative sparing strategiesinclude either the purchase of integralspare units or the purchase of compo-nents. If integral spare units are pur-chased, the number of units of each typeof equipment to be replaced during thelife cycle must be estimated. The totallife cycle cost will be the product of thenumber of units and the unit cost. Ifcomponents are to be purchased, the lifecycle cost can be modeled as an annualrecurring cost based on an assumed per-centage of the original unit purchasecost.
Derive schedules - Network equipmentpurchase and lease schedules are linkedto the construction and leased circuitacquisition schedules. Hence, equipmentpurchase and lease schedules should bederived only after the construction andleased circuit schedules have beenderived. It may be necessary to makeequipment-related scheduling assump-
4-9 12/16/96
tions. If so, these assumptions should bedocumented.
The network equipment database shouldbe updated to include the life year forpurchase or initiation of lease arrange-ment as appropriate.
Calculate network equipment lifecycle costs - The total life-cycle equip-ment cost for an architectural option isthe sum of all equipment purchase,sparing, and lease costs for that option.
4.3.2 Communications EquipmentCost Parameter Summary
Network equipment purchase costparameters include:
l Equipment unit cost, includingwarranties
l Number of units to be purchased
l Purchase schedules.
Network equipmentparameters include:
lease cost
l Equipment unit lease cost
l Number of units to be leased
l Lease schedules.
Network equipment sparing costparameters include:
l Number of complete spare units topurchase or % of the per-unit equip-ment purchase cost to be spent onspare components
l Frequency (annually, biannually,etc.) at which new spare units orspare components will be purchased.
4.4 Communications OAM&PLabor CostsThe task of efficiently estimating com-munications OAM&P labor costs can becomplex. Efficient execution of the taskwill be greatly assisted using the struc-tured methodology presented in Section4.4.1. The communications OAM&Plabor cost parameters are summarized inSection 4.4.2.
4.4.1 Cost DevelopmentMethodology
A seven-step process is recommended tosystematically develop networkOAM&P labor cost estimates. Thesequence is :
1.
2.
3.
4.
5.
6.
7.
Define a communications operationsscenario
Define the communications OAM&Pfunctions to be performed
Identify the skills required toperform the OAM&P functions
Conduct a salary survey
Define the required staffing levels(number of full-time equivalentpersons) for each skill level
Define overhead rates
Calculate life cycle networkOAM&P labor costs
Define a communications operationsscenario - Define how the telecommuni-cations network will be operated andmanaged. Specify if standards-basedequipment will be used. Determine ifthe network will be managed from onecentral location.
4-10 12/16/96
Define the communications OAM&Pfunctions to be performed - Decom-pose the communications operationsscenario into high-level functions, e.g.,fault management, network equipmentmaintenance. Then decompose the high-level functions into lower-levelsubfunctions, e.g., maintain help desk,replacement of damaged or failed net-work equipment.
Identify the skills required to performthe OAM&P functions - Map theOAM&P functions into the skillcategories for personnel that will executethese functions. Possible skill categoriesinclude but are not limited to networksystems engineers, network operators,network equipment technicians, andplant maintenance technicians.
Conduct a salary survey - If any or allof the functions are to be performed in-house, match the in-house skill catego-ries (and associated salaries) with therequired OAM&P skills. Industrymonitoring entities, such as the GartnerGroup, routinely publish salaries(unloaded) for many telecommunica-tions-related skill categories. If any orall of the functions are to be performedby external organizations, review recentsurvey data and match the publishedskill categories (and associated salaries)with the required OAM&P skills.
Define the required staffing levels -Given the communications operationsscenario, determine which functions, ifany, require round-the-clock support (7days per week, 24 hours per day),extended support (e.g., 7 days per week,12 hours per day), and on-call (asneeded) support. The remaining func-tions can be performed on a “standard”40 hours per week schedule. Allocate
the required number of full-time equiva-lents by skill category needed to performthe round-the-clock, extended, and“standard” functions. Estimate themaximum number of hours (annual) byskill category needed to perform any on-call functions.
Define overhead rates - Use any avail-able in-house overhead rate data forthose functions (if any) that will beperformed in-house. Use any availablein-house data for contractor overheadrates for those functions (if any) that areto be performed by externalorganizations. Otherwise estimate lowerand upper bounds of the external over-head rates. Assumed overhead rates canbe varied when conducting sensitivityanalyses.
Calculate life-cycle communicationsOAM&P labor costs - F o r e a c hacquisition option and each life-cycleyear, sum the products of the number offull-time equivalents in each applicablelabor category, their salaries, and theappropriate overhead rate(s). Add in thelabor cost for on-call support bysumming the products of the number ofannual on-call hours, the equivalenthourly rates for the individuals providingthe support, and the appropriate over-head rate(s).
4.4.2 Communications OAM&PLabor Cost Parameter Summary
Communications OAM&P labor costparameters include:
l Staffing profile (skills required)
l Staffing distributions (number offull-time equivalent persons [in-house and/or external] and annualon-call hours required per skill
4-11 12/16/96
category per network architectureoption for each calendar, fiscal, orlife-cycle year)
l Salaries (unloaded) for all skillcategories
l Overhead rates
4.5 CommunicationsSoftware CostsThe task of efficiently estimating com-munications software costs can be com-plex. Efficient execution of the task willbe greatly assisted using the structuredmethodology presented in Section 4.5.1.The communications software costparameters are summarized in Section4.5.2.
4.5.1 Cost DevelopmentMethodology
A ten-step process is recommended forsystematically developing networksoftware cost estimates. The sequenceis:
1.
2.
3.
4.
5.
6.
Analyze all communicationssoftware requirements.
Allocate communications softwarerequirements to ITS components.
Estimate the number of licensesneeded for the candidate COTSproducts.
Contact vendors and resellers.*
Identify non-COTS products to beenhanced.
Estimate the number of lines of newcode.*
7.
8.
9.
Select productivity rates forenhancing existing software anddeveloping new software.
Derive a composite labor rate.
Derive network software schedules.
10. Calculate the life-cyclecommunications software costs
* The COTS and non-COTS steps canbe executed in parallel.
Analyze all communications softwarerequirements - The baseline communi-cations software requirements should bethoroughly reviewed and analyzed tofully understand the network functionsto be performed.
Allocate communications softwarerequirements to ITS components - Thecommunications software functionsshould be mapped to any candidateCOTS software products. If no COTScandidate is identified, then the functionwill be performed by either an existingnon-COTS product or by a new softwareproduct that must be designed anddeveloped.
Estimate the number of licensesneeded for the candidate COTSproducts - Given the operationsscenario, including the distribution ofcommunications functions, the numberof licenses that are required for eachcandidate COTS product can beestimated for each network architectureoption.
Contact vendors and resel lers -Vendors and resellers should becontacted to obtain current purchase andannual maintenance costs for thecandidate COTS products.
4-12 12/16/96
Identify non-COTS products to beenhanced - Enhancements to existingnon-COTS products may be needed toadd required functionality. The numberof lines of enhanced code must beestimated.
Estimate the number of lines of newcode - The number of lines of code tobe designed and developed for eachidentified new non-COTS product mustbe estimated.
Select productivity rates - Productivityrates (staff hours per delivered sourceinstruction [DSI]) for enhancing existingsoftware and developing new softwaremust be selected. If the softwareenhancement and development is to beperformed in-house, use available datafrom past projects. Otherwise, industrymonitoring entities, such as the GartnerGroup, could supply ranges of produc-tivity rates.
Derive a composite labor rate - Thecost of labor to enhance and developcommunications software could besignificant. Typically, software projectsinvolve the talents of managers,designers, developers, and testers. Acomposite labor rate for the above mixof skills is appropriate for a first-cutestimate of labor costs. If the softwareenhancement and development is to beperformed in-house, available data frompast projects can be used to derive acomposite hourly rate. Otherwise,industry monitoring entities such as theGartner Group could supply compositerate data.
Derive network software schedules -Network software schedules will bederived from the ITS programschedules. The ITS program scheduleswill dictate when and where software
functional capabilities are needed.Using this information, COTS softwareprocurement schedules can be defined.Network software enhancement anddevelopment start schedules can beestimated by working backwards fromthe latest allowable availability date forthat software.
Calculate the life-cycle communica-tions software costs - The C O T Sprocurement and annual maintenancecosts can be calculated given the specificCOTS products and number licenses tobe procured, the procurement and annualmaintenance costs per license, and pro-curement schedules. The total cost ofenhanced existing code and the total costto develop new code can be calculatedgiven the estimated lines of codeinvolved, the software productivity rate,and the composite staff labor rate. Thistotal cost can be distributed across lifecycle years using the start and end datesderived in the previous step.
.
4.5.2 Communications SoftwareCost Parameter Summary
Communications software costparameters include:
l List of required COTS softwareproducts and number of licenses foreach product
l COTS software product purchaseand annual maintenance costs. List of existing software programs tobe enhanced and the estimated linesof enhanced code
l List of software programs to bedeveloped and the estimated lines ofdeveloped code for each program
4-13 12/16/96
l Software productivity rate (staffhours per DSI)
l Composite staff labor rate
l Software procurement schedules
l Software enhancement/developmentschedules
4-14 12/16/96
Section 5 - Calculateand Compare Option
Life-Cycle CostsThis section discusses the process ofcalculating the life-cycle costs of theacquisition options and providesexamples of how the life-cycle costs ofthe different options can be presented foreffective comparison.
5.1 Calculate Life-Cycle Costs
Section 4 describes five ITScommunications cost elements andidentifies the key parameters that drivethe costs. This section introduces theconcept of present value analysis anddiscusses how it relates to cost tradeoffanalysis. It also offers guidance on howto automate the process of calculatingthe total life-cycle costs for all options.
5.1.1I Present Value Analysis
The costs of each acquisition option willbe incurred throughout the life cycle.Present value analysis converts all coststo their current (i.e., present) value. Itassumes that a dollar received or spenttoday is worth more than a dollarreceived or spent tomorrow. A dollarinvested today begins to earn interestimmediately. A dollar invested in thefuture cannot earn interest until it isinvested. The difference in present valuecost is the interest earned by the dollartoday before a future dollar is invested.When analyzing life-cycle costs forperiods of more than three years, theOMB recommends that costs beexpressed in terms of present value.
The baseline year (i.e., the first life-cycleyear) establishes the time reference point
for present value analysis. The costs infuture years are then calculated as if theyoccurred in the baseline year by usingdiscount factors.
Discount factors are calculated using theformula:
factor = l/(l+i)t,
where i is the appropriate discount rateand t is the life-cycle year.
When performing cost tradeoff analysisand lease-buy analysis, the cost of fundsis a key concern. The OMB providesguidance on the discount rates to be usedfor these types of analyses. These ratesare discussed in Sections 5.1.1.1 and5.1.1.2, respectively.
For a given life-cycle year, differentfactors apply for different assumptionsof when the costs will be incurred withinthe year. Typically, costs are assumed tooccur at either the beginning of the year,in the middle of the year, or at the end ofthe year. Many costs (e.g., construction,leased circuits, leased equipment, labor)are spread evenly throughout the year.Some major costs such as capitalequipment tend to occur at the beginningor middle of a fiscal year.
Generally speaking, mid-year factorsshould be used unless the timing of thecosts cannot be specified or if they areknown to occur at the end of the year. Ifthe latter is true, then end-of-year factorsshould be used.
5.1 .1 .1I Cost Tradeoff Analysis
Cost tradeoff analysis compares real(constant purchasing power) dollars. Tomake meaningful comparisons, constant-dollar cost flows must be discountedusing real Treasury borrowing rates for
5-l 12/16/96
I Discount Factors
Life-Cycle Year Beginning of Year Middle of Year End of Year
10 0.75870 0.76925 0.77994
5.1.1.2 Lease-Purchase Analysis
Some states may wish to explore theoption of leasing versus buying ITScommunications equipment. Equipmentlease-purchase cost analysis comparesnominal dollars that are not adjusted toremove the effects of inflation. Nominalcost flows must be discounted usingnominal Treasury borrowing rates formarketable securities of comparablematurity to the period of analysis. Table5-3 summarizes the current OMB
nominal interest rates on treasury notesand bonds of various maturities.Referring to the table, the average realrate is currently below 7 percent. Foranalysis of ITS programs with durationsother than those cited in the table, linearinterpolation can be used. For example,a six-year project can be evaluated witha rate equal to the average of the 5-yearand 7-year rates. For program durationsexceeding 30 years, the 30-year interestrate may be used.
Table 5-3. Nominal lnferesf Rates on Treasury Nofes and Bonds
I Treasury Note and Bond Maturity (Years..) I
3 5 7 10 30
Interest Rate (%) 5.4 5.5 5.5 5.6 5.7
Table 5-4 presents discount factors forthe first ten years of an ITS networklifetime. These factors have beencalculated assuming a 5.55% discountrate, which is the average of the 7-yearand lo-year rates shown in Table 5-3.As noted above, the mid-year factorsshould be used if it is assumed that thecosts occur evenly throughout the year.If the timing of the costs is uncertain orif it is assumed that the costs occur at theend of the year, the end-of-year factorsshould be used.
5-3 12/16/96
Table 5-4. 10-Year Discount Factors for 5.55% Nominal Discount Rate
Discount Factors
Life Cycle Year Beginning of Year Middle of Year End of Year
1 0.94742 0.97335 1 .ooooo
2 0.89760 0.92217 0.94742
3 0.85040 0.87368 0.89760
4 0.80569 0.82774 0.85040
5 0.76332 0.78422 0.80569
6 0.72319 0.74298 0.76332
7 0.68516 0.70392 0.72319
8 0.64913 0.66690 0.68516
9 0.61500 0.63184 0.64913
10 0.58266 0.59861 0.61500
5.1.2 Automate Calculations
Unless few architecture options areidentified, it may be necessary toperform a large number of calculations.Regardless of the approach selected tocalculate costs, the following functionalcapability is needed for all options:. Vary input parameters
l Distribute costs over life-cycle years
l Rollup annual component costs ofindividual cost elements
l Rollup annual costs of all costelements
l Convert dollars to present valuedollars
l Calculate cumulative total life-cyclecosts
5-4 12/16 /96
. Calculate cumulative costs forsubsets of the total life cycle, e.g.,first five years, first ten years, etc.
Given the potential need to gather, store,manage, and manipulate a large volumeof data, consideration should be given toautomate the cost calculation andreporting process. There are manycomputer-based commercial tools tochoose from, including spreadsheetapplications and database managementsystems. The choice of the specific toolis not as important as planning how thetool will be used.
The following suggestions are offered toassist in the planning process:
l Implement a table-driven system
l Implement a computation hierarchy
. Separate cost calculation functionsand reporting functions
By storing the values of key parametersin tables and referencing the tables inequations, any parameter updates willautomatically “ripple” through thesystem and into the results.
By devising a top-down/bottom-upcomputational hierarchy for each costelement, error traceability will increasewhile debugging time is reduced, and itwill be possible to generate reports withincreasing levels of detail. Figure 5-1depicts one possible hierarchy, featuringthe leased circuit cost element lower-level details. Referring to the figure, atotal of four levels of hierarchy aredepicted including:
l Option level. Cost element level
l Circuit level
l Link level
The lowest level of cost for the leasedcircuit cost element is the link level. Foreach option, the one-time and monthlyrecurring costs for each leased link andtype of service defined for that optionare stored in a data table or database.
The link cost data is input to the circuitlevel where it is combined with otherdata such as the number of lines per linkand the year the circuit(s) will beactivated. The result is the individuallife-cycle costs for each leased circuit.
The per-circuit life-cycle costs are inputto the cost element level, and rolled up toyield the leased circuit cost element life-cycle cost for each option.
The life-cycle costs for all cost elements,including the leased circuit cost element,are rolled up at the option level to definethe total life-cycle cost of each option.
Finally, by identifying the interfacebetween the cost calculation and reportgeneration functions (e.g., a commondata format) early on in the planningprocess, both functions can be developedand tested in parallel. This approachwill also facilitate the futureenhancement of either the costcalculation function, or cost reportingfunction, or both.
5-5 12/16/96
5.2 Compare Life-Cycle Costs
This section provides examples of thetype of reports that can be generated tofacilitate the presentation of life-cyclecosts for individual options, and thecomparison of the life-cycle costs of twoor more options.
The following sections present anddiscuss the following generic reports:. Life-cycle cost summary for all
options. Annual life-cycle costs for optiongroups
l Lowest cost option details
l Lease, build, and hybrid break-evenanalysis
52.1 Life-Cycle Cost Summary:All Options
Table 5-5 presents a sample resultssummary for a multi-year life-cycle costanalysis study that includes build, lease,and hybrid acquisition options. costsare expressed in both current anddiscounted dollars for comparison. Theoptions have been assigned identifiers inaccordance with the scheme suggested inSection 3.2.5. Referring to the table,there are two lease options (the optionidentifiers have a leading “L”), threehybrid options (the option identifiershave a leading “H”), and one buildoption (the option identifier has aleading “B”).
The lease options include two nominaltechnical architectures (Ll and L2). Thehybrid options include one nominaltechnical architecture (Hl) and twovariations (H1_1, H1_2). One buildoption (B1) is defined.
Table 5-5. Life-Cycle Cost Summary for All Options
5.2.2 Annual Life-Cycle Cost forOption Groups
cycle. Percentages of the total optioncost are also calculated for the five costelements for the five- and ten-year
Table 5-6 presents a sample format forpresenting detailed annual cost breakoutsfor the three hybrid acquisition options.Referring to the table, the costs of allfive cost elements are shown for both thefirst five years and ten years of the life
periods.
5-7 12/16/96
Table 5-6. Annual Life-Cycle Costs for the Hybrid Acquisition Options
5.2.3 Lowest Cost Option Details
Figures 5-2 and 5-3 present two differentviews of a lowest cost option.
Figure 5-2 is a stacked bar chart profileof the annual costs. The contributions ofthe five cost elements are stackedtogether in one bar for each life-cycleyear. The relative proportions of costallocated to each cost element can beinferred from visual inspection, and thetotal annual cost can be read directlyfrom the scale on the left side of thegraph.
Figure 5-3 is a pie chart depicting thepercentages of the total life-cycle costassigned to each of the five costelements. The relative proportions ofcost allocated to each cost element canbe inferred from visual inspection, andthe actual percentages are also shownnext to each pie “slice.”
These and other views could be used toconvey the results of cost tradeoffstudies.
5-8 12/16/96
Section 6 - PerformSensitivity Analysis
If there are uncertainties in the initialcost tradeoff analysis, it would behelpful to know if reasonable changes inassumptions, topologies, technicalarchitectures, and/or cost parametervalues could significantly change therankings of the options. Sensitivityanalysis is the process of quantifying theeffect of changes in communicationsmodels and/or cost input parameters onthe rankings.
Features that facilitate the performanceof sensitivity analysis can be plannedand incorporated into the cost modelsprior to the start of a cost tradeoff study.However, sensitivity analysis need notactually be conducted if the initialrankings show that one option is clearlysuperior to all others.
To summarize, sensitivity analysis canbe performed by varying parameters inexisting cost models, by identifyingadditional options through analysis andcosting these additional options, or both.Section 6.1 discusses variation ofparameters. Section 6.2 addressesidentification and costing of newoptions.
6.1 Vary Cost ParametersAs a rule, sensitivity analysis shouldaddress the key input parameters for themost significant cost drivers. They arethe most likely parameters to alter theinitial cost rankings.
The key parameters should be identifiedand ranked in order of relativeimportance prior to implementing thecomputational models described in
Section 5. Having done this, care shouldbe taken to assure that the keyparameters can be easily modified byupdating data tables and/or scalingdefault data values within the costmodels. For example, equations thatcontain key cost parameters to be scaled,could include an explicit scaling factorfor that parameter which can be easilyvaried by updating data tables.
A two- or three-level scale (high-low, orhigh-medium-low) can be used to rankthe likely impact of individual costparameters on total cost. Cost parameterrankings are presented in Section 6.1.1.Section 6.1.2 offers suggestions forconducting sensitivity analysis byvariation of cost parameters.
6.1 .1 Cost Elements, Parameters,and Rankings
Table 6-l lists the cost elements, asubset of the parameters driving the costof these elements, and subjectiverankings of the impact of eachparameter. The parameter list wascompiled for the purpose of illustrationand hence is not complete. In an actualcost tradeoff study, all cost parametersshould be analyzed and ranked.
6-l 12/16/96
Table 6-1.. Cost Element Parameter Impact Rankings
Cost EIement
Construction
Leased Circuits
Cost Parameter
unit costs for applicable construction methods
the estimated percentages of the total constructionfor each construction method
average cross-road trenching distance for deviceslocated on the same side of the road as thebackbone
average cross-road trenching distance for deviceslocated on the same side of the road as thebackbone
distribution of along-road distance from devicesites to the nearest network POP
communications handhole furnish and install unitcost
fiber optic converter unit cost
device polling frequency
long term rate structures
purchase cost
sparing rates
long term lease rates
salaries
overhead rates
staffing level
lines of code for enhanced and developedcommunications software
software productivity rates
software development labor rates
commercial off-the-shelf (COTS) softwarepurchase costs
Equipment
OAM&P
CommunicationsSoftware
Impact
High
High
High
High
High
Low
Low
High
High
High
High
Medium
High
High
Medium IHigh
High
6-2 12/16/96
6.1.2 Sensitivity AnalysisTechniques
The analyst will thoroughly review theinitial cost tradeoff study results toidentify the cost element or elements thatcontribute the largest shares of the total
option or by varying two or moreparameters simultaneously.Simultaneous multiple parametervariations will be useful in promptlydetermining if the highest-ranked optioncan retain that ranking in spite of worstcase cost growth assumptions.
life-cycle cost for each option. Havingdone this, tools such as a parameterimpact rankings table will assist inselecting the cost parameters to vary.
For example, assume that the lowest costoption is lease and the second lowestcost option is hybrid. The nominalvalues of selected lease cost parameters
The analyst then has the option ofperforming sensitivity analysis by
would be scaled as shown in Table 6-2to reflect cost growth.
varying one parameter at a time per
Tab/e 6-2. Lease Option Pessimistic Sensitivity Analysis
Cost Element Cost Parameter Scaled Cost
I Construction I unit costs for applicable construction methods I > nominal Iaverage cross-road trenching distance for devices~ located on the same side of the road as thebackbone
average cross-road trenching distance for deviceslocated on the side of the road opposite to thebackbone
> nominal
> nominal
I Leased Circuits device polling frequency I > nominal I
I long term rate structures > nominal I
I Equipment I purchase cost I > nominal I
I long term lease rates I > nominal I
Note: > means greater than.
On the other hand, the values of selected analysis will be required to resolvehybrid cost parameters shown in Table obvious inconsistencies. For example:6-3 would be scaled to reduce the . unit construction method costsnominal costs. If lease with cost growthremains the lowest cost option compared
cannot be simultaneously higher andlower than nominal
to hybrid with cost reduction, no furtheranalysis is needed. Otherwise, further
6-3 12/16/96
l average distances cannot besimultaneously higher and lowerthan nominal
l device polling frequencies cannot besimultaneously higher and lowerthan nominal. long term leased circuit rateprojections cannot be simultaneouslyhigher and lower than nominal
l equipment purchase costs cannot besimultaneously higher and lowerthan nominal
l long term equipment lease rateprojections cannot be simultaneouslyhigher and lower than nominal.
Table 6-3. Hybrid Option Optimistic Sensitivity Analysis
Cost Element
Construction
Cost Parameter Scaled Cost
unit costs for applicable construction methods < nominal
average cross-road trenching distance for devices < nominallocated on the backbone side of the road
average cross-road trenching distance for devices < nominallocated on the side of the road opposite to thebackbone
Leased Circuits device polling frequency < nominal
long term rate structures < nominal
Equipment purchase cost < nominal
long term lease rates < nominal
Note: < means less than.circuits and still satisfy all
6.2 Identify and Cost New communicationsOptionsWhile reviewing the initial cost tradeoffresults, the analyst may identify ways ofreducing the cost of one or more options,thus making them more competitive withthe lowest cost option. For example,upon review of the leased circuit costsfor some lease and/or hybrid classoptions, it may be possible to use adifferent type of service for some
requirements while at the same timereducing total life-cycle costs.
For the above example, the analystwould have the choice of eitherredefining existing opt ions orintroducing new options. Either way,these options would be costed andcompared to their peers.
6-4 12/16/96
Acromym List
ATM
ATR
BISDN
CCTV
CHART
CMS
CODECS
COTS
C S C
DCS
DDS
DSI
F&I
FDDI
FDM
FHWA
GIS
HAR
HDTV
IS/IT
ISDN
ITS
ITU
JPEG
JPO
Kbps
LAN
Mbps
Asynchronous Transfer Mode
automated traffic recorder
Broadband Integrated Services Digital Network
closed circuit television
Chesapeake Highway Advisories (for) Routing Traffic
changeable message sign
coders/decoders
commercial off-the-shelf
Computer Sciences Corporation
digital cross-connect system
Dedicated Digital Services
delivered source instruction
furnish and install
Fiber Distributed Data Interface
frequency-division multiplexing
Federal Highway Administration
Geographic Information System
Highway Advisory Radio
high definition television
information systems/information technology
integrated services digital network
Intelligent Transportation System
International Telecommunication Union
Joint Photographic Experts Group
Joint Program Office
kilobits per second
local area network
megabits per second
A-l 12/ 16/96
MDOT
MHz
M-JPEG
MPEG
MSHA
MSP
MTBF
MTTR
NTSC
OAM&P
OMB
OTD
P/T/Z
PBFI
POP
POTS
RMA
RWIS
SDH
SHA
SMDS
SOC
SONET
SSR
TAR
TDM
TOC
US DOT
VMS
Maryland Department of Transportation
megahertz
Motion Joint Photographic Experts Group
Motion Pictures Experts Group
Maryland State Highway Administration
Maryland State Police
mean time between failure
mean time to repair
National Television Standards Committee
operations, administration, maintenance and provisioning
Office of Management and Budget
overhead traffic detector
pan, tilt, zoom
PB Farradyne Inc.
point-of-presence
plain old telephone service
reliability, maintainability, availibility
Road & Weather Information System
Synchronous Digital Hierarchy
State Highway Administration
Switched Multimegabit Data Service
Statewide Operations Center
Synchronous Optical NETwork
spread sprectrum radio
travelers advisory radio
time-divsion multiplexing
Traffic Operations Center
United States Department of Transportation
variable message sign
A-2 12/16/96
