PDFCLARUS.pdf

SOLICITATION, OFFER AND AWARD 1. THIS CONTRACT IS NOT A RATED ORDER

UNDER DPAS (15 CFR 700)

RATING

PAGE OF PAGES

1 | 37

2. CONTRACT NUMBER

3. SOLICITATION NUMBER

DTFH61-08-R-00023

4. TYPE OF SOLICITATION

SEALED BID (IFB)

NEGOTIATED (RFP)

5. DATE ISSUED

2 June 08

6. REQUISITION/PURCHASE NO.

21-74-8023

7. ISSUED BY CODE HAAM-30 8. ADDRESS OFFER TO (If other than Item 7)

Federal Highway Administration Office of Acquisition Management 1200 New Jersey Ave. S.E.

Washington, DC 20590

NOTE: In sealed bid solicitations “offer” and “offeror” mean “bid” and “bidder”

SOLICITATION

9. Sealed offers in original and 6 copies for furnishing the supplies or services in the Schedule will be received at the place specified in Item 8, or if hand carried, in the depository located in 1200 New Jersey Avenue, SE until __1 AUGUST 08 _____ local time _3:00 pm __.

CAUTION ⎯ LATE Submissions, Modifications, and Withdrawals: See Section L, Provision No. 52.214-7 or 52.215-1. All offers are subject to all terms and conditions contained in this solicitation.

10. FOR A. NAME B. TELEPHONE (NO COLLECT CALLS) C. E-MAIL ADDRESS

INFORMATION

CALL:

Primary Contact: Charles Kotch Secondary Contact: Robert Robel

AREA CODE

NUMBER

366-6622

EXT.

charles.kotch@dot.gov

11. TABLE OF CONTENTS

( ) SEC. DESCRIPTION PAGE(S) ( ) SEC. DESCRIPTION PAGE(S)

PART I - THE SCHEDULE PART II - CONTRACT CLAUSES

X A SOLICITATION/CONTRACT FORM 1 X I CONTRACT CLAUSES 32-36

X B SUPPLIES OR SERVICES AND PRICE/COST 2 PART III - LIST OF DOCUMENTS, EXHIBITS AND OTHER ATTACH.

X C DESCRIPTION/SPECS./WORK STATEMENT 2-17 X J LIST OF ATTACHMENTS 37

X D PACKAGING AND MARKING 20 PART IV - REPRESENTATIONS AND INSTRUCTIONS

X E INSPECTION AND ACCEPTANCE 20 X K REPRESENTATIONS, CERTIFICATIONS

X F DELIVERIES OR PERFORMANCE 20-23 AND OTHER STATEMENTS OF OFFERORS 38

X G CONTRACT ADMINISTRATION DATA 23-27 X L INSTRS., CONDS., AND NOTICES TO OFFERORS 39-48

X H SPECIAL CONTRACT REQUIREMENTS 27-31 X M EVALUATION FACTORS FOR AWARD 48-50

OFFER (Must be fully completed by offeror) NOTE: Item 12 does not apply if the solicitation includes the provisions at 52.214-16, Minimum Bid Acceptance Period.

12. In compliance with the above, the undersigned agrees, if this offer is accepted within _____ calendar days (60 calendar days unless a different period is inserted by the offeror) from the date for receipt of offers specified above, to furnish any or all items upon which prices are offered at the price set opposite each item, delivered at the designated point(s),

13. DISCOUNT FOR PROMPT PAYMENT

(See Section I, Clause No. 52.232-8)

10 CALENDAR DAYS

20 CALENDAR DAYS

30 CALENDAR DAYS

CALENDAR DAYS

14. ACKNOWLEDGMENT OF AMENDMENTS AMENDMENT NO. DATE AMENDMENT NO. DATE

(The offeror acknowledges receipt of amendments to the

SOLICITATION for offerors and related documents numbered and dated):

15A. NAME CODE FACILITY 16. NAME AND TITLE OF PERSON AUTHORIZED TO SIGN

AND OFFER (Type or print)

ADDRESS

OF

OFFEROR

15B. TELEPHONE NUMBER 15C. CHECK IF REMITTANCE 17. SIGNATURE 18. OFFER DATE

AREA CODE

NUMBER

EXT.

ADDRESS IS DIFFERENT FROM ABOVE

- ENTER SUCH ADDRESS IN

SCHEDULE.

AWARD (To be completed by Government)

19. ACCEPTED AS TO ITEMS NUMBERED

20. AMOUNT

21. ACCOUNTING AND APPROPRIATION

22. AUTHORITY FOR USING OTHER THAN FULL AND OPEN COMPETITION:

10 U.S.C. 2304(c) ( )

23. SUBMIT INVOICES TO ADDRESS

SHOWN IN (4 copies unless otherwise specified)

ITEM

24. ADMINISTERED BY (If other than Item 7)CODE 25. PAYMENT WILL BE MADE BY CODE

26. NAME OF CONTRACTING OFFICER (Type or print)

27. UNITED STATES OF AMERICA

(Signature of Contracting Officer)

28. AWARD DATE

IMPORTANT – Award will be made on this Form, or on Standard Form 26, or by other authorized official written notice.

mailto:charles.kotch@dot.gov

P A R T I

SECTION B - SUPPLIES OR SERVICES AND PRICES/COSTS

The Contractor shall furnish all necessary facilities, materials, and personnel and shall perform all services necessary for the Development and Deployment of Clarus-enabled services.

The total estimated amount for the performance of this cost-plus-fixed-fee contract is $ _______, which consists of an estimated cost of $________ and a fixed fee of $ _________.

Cost Fee Total Amount

Use Case Scenario #1 $__________ $__________ $____________

Use Case Scenario #2 $__________ $__________ $____________

Use Case Scenario #3 $__________ $__________ $____________

Use Case Scenario #4 $__________ $__________ $____________

Use Case Scenario #5 $__________ $__________ $____________

Total Estimated Amount $____________

SECTION C - DESCRIPTION/SPECIFICATIONS/WORK STATEMENT

BACKGROUND

The Clarus Initiative, established in 2004, is a multi-year program administered and funded by the U.S. Department of Transportation (USDOT). The Initiative includes program management, stakeholder coordination, education and outreach activities, and the actual engineering and implementation of the Clarus System. Through the Clarus System, the FHWA is demonstrating a data management system for sharing quality checked surface transportation weather and pavement observations. Through the sharing of high quality, surface transportation-related observations from the Clarus System, it is envisioned that this enabling technology will aid in reducing the impact of adverse weather for all surface transportation users and operators.

The need for a system such as Clarus (which is Latin for “Clear”) was well documented in the National Academy of Sciences report, Where the Weather Meets the Road: A Research Agenda for Improving Road Weather Services.1 This report described the need for a robust, integrated road weather observational network and database management system. The database management system, now referred to as Clarus and running in a research environment, can fulfill the needs of transportation communities as well as other stakeholders (e.g., the National Oceanic and Atmospheric Administration (NOAA), the private sector, and

1 “Where the Weather Meets the Road: A Research Agenda for Improving Road Weather Services”, National Academy of Sciences, www.nap.edu/catalog/10893.html, 2004.

researchers) for near real-time, quality checked road weather (atmospheric and pavement) observations.

Under a separate FHWA award, Contract No. DTFH61-05-C-00022, the Clarus System was designed based upon an overall Concept of Operations (ConOps) and requirements defined by Clarus stakeholders. The Clarus System ConOps describes the system implementation at a high level and includes seven use case scenarios—public transportation agency maintenance and construction operations, traffic operations, traveler information, transit management, emergency management and public safety operations, rail operations, and commercial vehicle operations. The modular design of the Clarus System includes collector services to ingest Environmental Sensor Station (ESS) data, configuration and administration services for metadata input, internal quality checking algorithms, and environmental data services to disseminate both qualified observation data and metadata. As part of the system design, a Clarus interface specification was also developed to facilitate standardized communications between the Clarus System and other entities (e.g., State Departments of Transportation (DOT), vendors, forecasters, researchers, etc.).

Clarus System development was completed and implemented during a proof-of-concept deployment in 2006 to ensure that the system components operated and interfaced properly.

The Clarus System ConOps, requirements, system design documents and test plan documents can be found on the Clarus Initiative website which is located at http://www.clarusinitiative.org/Archive.htm.

Progress on the Clarus Initiative has advanced such that the Government began conducting Multi-state Regional Demonstrations during 2006. Through the Clarus Multi-state Regional Demonstrations, the Government aims to achieve the following objectives:

(1) Demonstrate that the Clarus System functions as designed by incentivizing a large number of State (or Provincial) and local agencies to contribute data from their ESS networks;

(2) Enable proactive transportation system management through utilization of the Clarus System; and,

(3) Provide an environment for the private sector and academic organizations to innovate and create new and improved services that will benefit the public (both government and travelers), academia, and the entire weather enterprise.

The first phase of the Clarus Multi-state Regional Demonstrations was launched during the fall of 2006 with a Request for Applications (RFA) to State DOT (DTFH61-07-RA-00001). This RFA satisfied the first two objectives listed above by incentivizing transportation agencies to contribute their ESS data and metadata to the Clarus System and to document their needs (for new products, techniques, etc.) within a new set of services. These services are documented within three sets of application-oriented ConOps and are central to the successful response to this solicitation. Information about the application-oriented ConOps can be found in C.2.1.

The second phase of the Clarus Multi-state Regional Demonstrations began during the summer of 2007. This phase, the Connection Incentive Program, provides grants to public transportation agencies to assist them in connecting to the Clarus System. Funding from the grants could be used, with FHWA approval, for expenses associated with metadata collection or for software or hardware changes needed to connect to the system. Agencies will be able to http://www.clarusinitiative.org/Archive.htm participate in this phase (and apply for grants) until the end of September 2008.

This Request for Proposals (RFP) is specifically focused on the third phase of the Clarus Multi-state Regional Demonstrations; development and deployment of Clarus-enabled services which build upon use case scenarios provided within the Phase 1 ConOps (Section C.2.1) to enable proactive transportation management by public agencies. In addition to the development and implementation activities, the contractor(s) will be expected to document their experiences in using the Clarus System (See Section C.3, Task 8).

C.1 SCOPE

This work includes participation in the Development and Deployment phase of the Clarus Multi-state Regional Demonstrations, for the development and implementation of new, innovative Business-to-Government (B2G) services2.

Services will include new innovations, products, techniques, decision support systems, algorithms, etc, and be based upon use case scenarios included in Section C.2.2 of this document. The services must utilize surface transportation weather and pavement data from the Clarus System.

A B2G service shall be defined as a service that is generated by the private or academic sectors specifically focused on improving public (State/Provincial/Municipal) transportation agency strategies or operations. These public transportation agencies are referred to as ‘participating agencies.’ The participating agencies will provide expertise and recommendations to the prime contractor throughout the entire period of performance.

A Business-to-Traveler (B2T) service shall be defined as a service that is generated by the private or academic sectors and provided directly to travelers via some communications medium (e.g., web browser, PDA, text message, satellite or cellular link, etc.) to aid in their decision making. Such services are not routed through government agencies. Travelers include all types of transportation system users, such as general drivers, commuters, the trucking community, and transit operators. One of the included scenarios also offers the opportunity to utilize Clarus data within a service that provides information directly to transportation system users.

C.2. OBJECTIVE

The objective of this contract is to fulfill Phase 3 of the Clarus Multi-state Regional Demonstrations and show how data from the Clarus System are utilized by, or a benefit to, the resultant B2G or B2T service(s). It is expected that the services will be used by transportation agencies to support system operations and management and/or assist the traveling public to help in reducing impacts of adverse weather.

C.2.1. PHASE 1 - CONCEPTS OF OPERATIONS

During Phase 1 of the Clarus Multi-state Regional Demonstrations, three teams of

2 Scenario 5, described within Section C.2.2, includes an opportunity for a Business-to-Traveler (B2T) service. This may be in the form of a traveler alert service that can be delivered directly to travelers.

transportation agencies drafted and delivered ConOps documents. Each document contained concepts for possible B2G services utilizing Clarus System data. These concepts were embedded within use case scenarios. This section provides details about the ConOps and identifies those use case scenarios that have been selected by USDOT for potential development, implementation and evaluation.

Each ConOps document is available in PDF format on the Phase 1 Regional Demonstration page within the Clarus Initiative Web site (http://www.clarusinitiative.org/regional.htm). Each offeror should obtain these documents and become familiar with their background, user needs and the scenarios prior to responding to this solicitation.

The FHWA has selected portions of the use case scenarios from each of the ConOps documents which were the culmination of work from the following teams:

ConOps #1: Alaska/Canadian (ALCAN) Team

- Lead Agency: Alaska Department of Transportation and Public Facilities

- Point of Contact: Jack Stickel, Jack.Stickel@alaska.gov

- Agency Team Members: Alaska, Yukon Territory, British Columbia, and Alberta

ConOps #2: Aurora Team

- Lead Agency: Iowa Department of Transportation

- Point of Contact: Tina Greenfield, Tina.Greenfield@dot.iowa.gov

- Agency Team Members: Iowa, Illinois, Indiana, and Ohio

ConOps #3: Northwest Passage Team

- Lead Agency: South Dakota Department of Transportation

- Point of Contact: Dave Huft, Dave.Huft@state.sd.us

- Agency Team Members: South Dakota, North Dakota, Minnesota, Wisconsin, Montana, Wyoming, Idaho, and Washington State

Five use case scenarios are presented herein. Each scenario can be directly attributed to one or more of the use cases contained in the ConOps and includes a concept for potential B2G services.

C.2.2 SCENARIOS

Commitment of Participation with Transportation Agencies

This solicitation requires that a commitment be created between the offeror and public transportation agencies for scenarios 2 through 5, inclusive. This is required so that the offeror can participate with a team of public agencies to assist in requirement formulation and new service evaluation.

Offerors must establish a commitment of participation with public transportation agencies in accordance with the following criteria:

- The offeror must obtain letters of commitment from a minimum of two or more public transportation agencies (e.g., State Departments of Transportation or Provincial Ministries of Transportation) that are currently operating an ESS network for scenarios 2 http://www.clarusinitiative.org/regional.htm mailto:Jack.Stickel@alaska.gov mailto:Tina.Greenfield@dot.iowa.gov mailto:Dave.Huft@state.sd.us through 5, inclusive. An ‘operating network’ means that ESS data are being routinely collected by the transportation agency. One letter of commitment from a transportation agency can be used to acknowledge working on one or more scenarios.

- The offeror shall obtain cost proposals and a description of planned activities from the participating public transportation agencies. FHWA will issue separate agreements(s) to the participating public agencies and fund them separately.

- Any public transportation agency is eligible to participate in this demonstration; however preference will be given to Phase 1 public transportation agency participants.

- Each letter of commitment must state that the transportation agency will be available to work with the offeror and provide ESS data into the Clarus System for at least two years (the period of performance of this contract).

- At least one public agency must be a U.S. State DOT.

- In order to assure that the demonstration is regional, the participating public agencies must be adjoining with respect to sharing a common transportation corridor(s) and border(s).

- Offerors that include more than the minimum number of agencies (2) will receive added consideration during the federal evaluation for award.

For the duration of the period of performance, the offeror will make available to the participating public transportation agencies, all services or their output products, free of charge for the purpose of new service development and evaluation.

Finally, awards will be based on the viability, complexity and value of the proposed service(s).

The Government will determine the number and/or what parts of any proposal will be funded.

Use Case Scenarios The USDOT has selected five (5) concepts from the Phase 1 ConOps use case scenarios for possible implementation within this solicitation. Selection of Use Case Scenario #1 is mandatory for all offerors as it substantiates the value of Clarus data to improve the state of the practice for surface transportation meteorology. Offerors may select any other, or combination thereof, (or none) of the remaining use case scenarios for implementation. Letters of commitment are required from all public transportation agencies for scenarios 2 through 5, inclusive.

Use Case Scenario #1 – Enhanced Road Weather Forecasting Enabled by Clarus

- Based on the Northwest Passage ConOps, Scenario C.

- Including this scenario in your proposal is mandatory.

- A letter of commitment from a participating transportation agency is not required for this scenario.

Throughout this document and the duration of the Clarus Initiative, the FHWA Road Weather Management Program has been demonstrating that the investments made in deploying ESS go beyond just site-specific winter maintenance operations. Clarus seeks to remove restrictive network borders, making quality checked, near real-time ESS observation data available to all transportation agencies and promote the use of data as input to enhanced road weather forecasting service providers and the greater weather enterprise.

In this scenario, the offerors must utilize Clarus-based ESS data to enhance (atmospheric and pavement) forecasting for surface transportation. The offeror must also be able to clearly trace the usage and benefits of Clarus data within this service. An independent evaluation will look to identify measurable evidence showing an improvement to some aspect of road weather forecasting as a result of this service.

Enhanced surface transportation forecasting can come from many different types of services.

Some examples include (but are not limited to):

- Adding Clarus data into numerical weather prediction model assimilation fields that produce more realistic initialization conditions at the atmosphere/land interface and result in some measurable improvement to short term nowcast or forecast output.

- Modifying numerical weather prediction model(s) to utilize Clarus data to create some measurable improvement to surface transportation-related weather or pavement predictions.

- Modifying planetary boundary layer models to utilize Clarus data to better predict atmospheric elements that directly affect the transportation system (e.g., precipitation type predictions, rain/snow change line location predictions, wind character/gustiness predictions).

- Creating a new algorithm(s), technique(s) or product(s) that uses Clarus data and whose output demonstrates a measurable improvement to surface transportation (atmospheric or pavement) forecasting.

Successful implementation of this first scenario will provide a good and necessary foundation for working on any of the remaining scenarios as well as improving road weather forecasting capabilities within the weather enterprise.

Use Case Scenario #2 – Seasonal Weight Restriction Decision Support Tool

- Based upon the ALCAN ConOps, Scenario B

- Letters of commitment from all participating transportation agencies are required when responding to this scenario.

The Seasonal Weight Restriction use case describes a decision support tool that analyzes the sub-pavement conditions given near real-time Clarus ESS observations, historical weather and historical pavement conditions (and other elements as necessary) and provides estimations of road segment locations and time periods where vehicle weight restrictions are necessary.

In this scenario, observations from the Clarus System (e.g., air temperature, pavement temperature, subsurface temperature, etc.) will be used as input, along with other available observations, into a data analysis, meteorological and pavement modeling decision support tool to support transportation agency control strategies during critical freeze/thaw periods.

At a minimum, Clarus ESS observations, historical seasonal information on freeze/thaw cycles, soil and roadbed profiles, and forecasted weather conditions will be integrated into this tool.

The resulting output will be recommendations to transportation agency personnel (and by extension commercial vehicle operators, perhaps via a Web portal) on where and when seasonal weight restrictions may be imposed.

The Seasonal Weight Restriction Tool will be based on agency rules of practice and user needs. This application is a road weather control strategy.

Use Case Scenario #3 – Non-winter Maintenance and Operations Decision Support Tool

- Based primarily on ALCAN ConOps, Scenario G and Aurora ConOps Scenario 6.8

- Letters of commitment from all participating transportation agencies are required when responding to this scenario.

Many of the efforts that have been put forth on the development of decision support tools have focused on supporting winter maintenance and operations best practices. However, this scenario is intended to take a broader look at expanding decision support activities, beyond snow and ice control. Specifically, this scenario focuses on how Clarus data can be used to assist in decision making for:

- road maintenance scheduling decisions, especially those activities that affect traffic flow and mobility (e.g., lane closures for striping or pothole filling), and

- construction-related scheduling decisions such as for pavement applications and curing.

It is envisioned that this tool would leverage the work that has already been performed in the creation of the winter maintenance decision support system (MDSS). Documentation and source code for the MDSS federal prototype can be found at the National Center for Atmospheric Research (NCAR) Web site at http://www.rap.ucar.edu/projects/rdwx_mdss/. The federal prototype is a complex system consisting of communication modules for the ingest of observations and model data, data fusion components to create optimized weather forecasts, and a rules of practice module that contains customization algorithms that work on specific tasks (such as snowfall accumulation or road temperature forecasts).

The key to this scenario is being able to participate with transportation agency members to assess their needs, and document their rules of practice so that operationally-based recommendations can be generated by the tool and presented to the agency. These recommendations would provide assistance in task planning and scheduling for year-around maintenance and construction operations.

This decision support system shall use Clarus System data along with other weather, route and local information as input into weather and pavement condition forecasts. These forecasts would then be fed into customized algorithms that provide scheduling recommendations for operational transportation agency personnel.

Use Case Scenario #4 – Multi-state Control Strategy Tool

- Based on the Northwest Passage ConOps, Scenario A and Aurora ConOps Scenario 6.1

- Letters of commitment from all participating transportation agencies are required when responding to this scenario.

Closing a road along a transportation corridor at or just beyond the border in the next state or province can result in significant impacts on transportation agencies along with potential hardships on travelers. One effect might be congestion as long lines of vehicles wait for roads to re-open at a state border. In extreme cases, travelers may need lodging or even to have the National Guard mobilized to deliver blankets or food to stranded travelers. Having information in advance or at the time controls are imposed could provide an effective means of informing http://www.rap.ucar.edu/projects/rdwx_mdss/ the public of travel delays, detours or closures, as well as improve agency coordination across jurisdictional borders.

The use of control strategies (e.g., lane/road/bridge closures, contraflow operations, detours, etc.) is a well documented process for transportation agencies when road conditions deteriorate during adverse weather. However, there is the need for improved coordination within states as well as with adjacent states with respect to the imposition of controls and dissemination of associated advisories. These actions can result in significant travel impacts as traffic stalls in areas that are not well prepared to handle the influx of stranded motorists.

The development of a timely process to communicate changes in road status would permit officials in adjacent areas the opportunity to take proactive steps to mitigate the impact on travelers. Such actions could include rerouting travelers prior to a blockage in areas that have better infrastructure to handle lodging, fueling and dining.

Once a control action has been performed, it is necessary to transmit this information to a common repository or data warehouse where the information from all jurisdictions can be stored and made available for posting to appropriate channels of information dissemination.

Interested parties could include transportation agencies, law enforcement agencies, fleet managers, information service providers, travelers, and traveler-related interests.

The result of this use case scenario would be:

1. the creation of a data management system that combines (but is not limited to) Clarus ESS observations and road condition data for

2. input into a decision support tool to support agency control strategies within and across multiple states or provinces.

Some scenarios where such a tool would benefit transportation agencies include:

- During winter storms, Clarus ESS data would provide information about freezing pavement temperatures while road condition data would provide information about pavement conditions and mobility. Resulting recommendations might be to recommend tire controls (e.g., snow tires, chains).

- During rain events, Clarus ESS data would provide information about rainfall intensity or flooding while road condition data would provide information about resulting closures of roads or bridges.

- During high winds, Clarus ESS data would provide information about strong crosswinds along interstates or bridges. Road condition data would provide information about wind buffeting on high profile vehicles which could lead to travel restrictions on bridges.

Use Case Scenario #5 – Enhanced Road Weather Content for Traveler Advisories

- Based on the Northwest Passage ConOps, Combined Scenarios: B & C and Aurora ConOps Scenario 6.1

- Letters of commitment from all participating transportation agencies are required when responding to this scenario.

In this scenario, the vision is to improve content related to enhanced road weather advisories for traveler information systems such as dynamic message signs (DMS), highway advisory radio (HAR) broadcasts, 511 telephone services, related web sites or push technologies (e.g., text messages, PDA, RSS, emails, etc.). This scenario does not propose to change the framework of existing traveler information systems. Instead, it is intended to enhance the pooling of informational resources already in use and improve its accessibility and content by each state’s service provider for improved data, advisory and forecast delivery over the width of a corridor. This includes interstate, route-specific weather forecast information, road condition data, and the ability to provide actual atmospheric and pavement conditions and advisories enabled through use of the Clarus System.

Some traveler information systems have limited capabilities to access information across borders and are limited to the exchange of information with adjacent states. Enhancing available weather and pavement condition information and providing mechanisms to permit the data warehousing of traveler information; including current/forecast road conditions, weather conditions, and advisories; would provide a framework enhancing traveler decision support along highway corridors spanning multiple states.

The service implemented within this scenario would be a tool that provides transportation agencies and/or private sector partners with accurate and concise information about pavement and weather conditions for use in disseminating traveler information. Some examples might include:

- providing enhanced road weather content using ESS and road condition information along specific routes to 511 service providers,

- providing enhanced road weather content for a regional traveler alert system (possibly using mobile technologies),

- providing enhanced road weather messages for use on HAR or DMS,

- providing ESS data and enhanced road condition information along specific routes to traffic management personnel to support their decision making and operations, and

- creating road weather coordination messages or advisories from the public transportation agency to emergency managers, state police and first responders, or

- creating a new visualization display to show the value of Clarus data in real time, integrated with other relevant data as a tool for both transportation agencies and travelers.

NOTE: Offerors that also propose value-added Business-to-Traveler (B2T) services such as partnering with a regional or national media outlet or dissemination vendor to provide traveler alerts (e.g., satellite communications, cable TV, in-vehicle devices, etc.), will receive consideration in the proposal evaluation. In order to receive consideration, offerors (or their data dissemination partners) are expected to cost share a significant portion of the costs associated with B2T services.

Scenario Deliverable Summary Table

Scenario Mandatory? Letters of

Commitment Deliverables

1 Yes No • An algorithm, model or technique that improves forecasting for surface transportation weather and road conditions

• A verification report showing measurable improvement to road weather forecast elements

2 No Yes • A seasonal weight restriction decision support tool

• A report including transportation agency commentary and validation statistics

3 No Yes • A decision support system for non-winter maintenance or construction scheduling

• A report including transportation agency commentary and validation statistics

4 No Yes • A data management system and decision support tool for agency control strategies

• A reporting including transportation agency commentary and recommendations for improvement

5 No Yes • A tool to support transportation agency advisory strategies

• A report including transportation agency commentary and recommendations for improvement

System Engineering Guidelines The offeror shall adhere to strict systems engineering guidelines and processes when implementing each scenario. To provide an example of an acceptable systems engineering approach, a V-diagram has been provided (see Image 1 below). The design documentation shall support the scenarios and concepts described within this RFP and references in the transportation agency ConOps. Modifications to the use case scenarios as described within this document can be made in coordination with and upon approval of the USDOT.

The system design effort involves extensive documentation including high level requirements, detailed requirements, system design documents including an architecture definition, a test plan, and a service promotion plan. The service(s) created as a result of this RFP may be implemented and integrated into public transportation agency operations. The offeror will also evaluate the Clarus System and participate with an evaluation conducted by the U.S. DOT Intelligent Transportation Systems (ITS) Joint Program Office (JPO) and their contractor(s).

The Clarus System Web portal can be found at http://clarus-system.com.

Image 1: System Engineering “V diagram”

STATEMENT OF WORK

C.3 DELINEATION OF TASKS

Under this contract, the offeror shall perform the following tasks.

Task 1 – Project Management The contractor shall conduct project management. Project management is a continuous activity spanning the duration of this contract. The Project Manager is responsible for managing the contract and all subcontractor activities. The Project Manager will have frequent communication with the Government throughout the duration of this contract.

Task 1.1 – Project Plan The contractor shall prepare a project plan that establishes a baseline for scope, schedule, and cost for each scenario and resulting service that has been proposed for implementation.

The project plan shall also document risks, assumptions, and constraints. The Project Manager and representatives from each of the offeror’s business partners and participating agencies shall participate in a kick-off meeting in Washington, D.C at the USDOT where the draft project plan shall be discussed. Topics at this meeting will include discussions of project goals, transportation agency participation and service evaluations. This meeting shall take place within four (4) weeks of the effective date of the contract. The contractor shall prepare and deliver minutes from the kick-off meeting as well as any modifications made to the project plan document(s).

As a part of the project plan, the contractor shall describe the working relationships with the participating public agencies and a description of technical activities, to be performed during the period of performance of this RFP.

In addition, during this kick-off meeting the contractor and Government will review the cost proposals* submitted by the participating agencies to develop a thorough understanding of the work to be performed by the agencies. The cost proposals will provide guidance to the Government in establishing funding arrangements with the participating public agencies.

*See SECTION L PART III – BUSINESS AND COST/PRICE PROPOSAL

Task 1.2 – Contractor Coordination The contractor shall coordinate meetings and forums for interaction among the development team, participating agencies and the USDOT. This shall include web and teleconferences along with face-to-face interactions. USDOT anticipates holding at least two (2) face-to-face meetings with the selected team(s) and agencies. The first meeting will be used to jointly review the project plan. The second meeting will be to present and describe final service(s) or deliverable(s).

Task 1.3 – Reporting Progress The contractor shall provide quarterly progress reports to the Government via email. The reports shall include details on project progress, any problems encountered and mitigation steps, as well as financial updates. On a monthly basis, the contractor shall conduct a conference call, which at a minimum, shall include the USDOT, contractor and transportation agency representatives, and any additional support staff as designated by the USDOT.

Task 1.4 – Letters of Commitment The contractor shall obtain commitment letters from at least two (2) public transportation agencies (one of which must be a U.S. State DOT and adjoining with respect to sharing a common transportation corridor(s) and border(s)), which shall be included with their proposals (as described in Section C.2.2). The participating agencies must agree to follow the development of the implemented service(s) and provide suggestions for improvement during the development period (e.g., the first year of this RFP). During the evaluation period (e.g., the second year of this RFP), the agencies must agree to participate in an evaluation of the developed service(s) and assist the independent evaluator, as needed, to perform objective analyses. The Government will work with the participating agencies to resolve their expenses in support of the development and evaluation of the implemented service(s).

Task 1 Deliverables

- Draft project plan

- Final project plan

- Kickoff meeting notes

- Quarterly progress reports

Task 2 – Review and Revise Use Cases for Selected Scenarios The use case scenarios contained within in Section C.2.2 of this RFP are related to one or more scenarios presented within the Phase 1 ConOps documents. For each selected use case scenario, the contractor will use the use case format found within the ALCAN or Northwest Passage ConOps documents to fill out details and diagrams for each propose service (including UML figures). The result shall be complete, high-level concepts of operations use case scenarios for each proposed implementation. (Note: this task is not asking that a whole ConOps be created or rewritten. The focus is only on filling out and completing the contractor’s selected scenarios.)

Upon written approval from the Government COTR, the contractor shall provide the updated use case scenarios to the participating transportation agencies and the USDOT for review to make sure that the intent of the proposed service(s) will support agency needs. The comments provided by agencies shall be incorporated into the final use case scenarios and shall clearly describe how ESS data can be traced from the originating transportation agency through Clarus, through the service, and how the resulting implementation can be utilized by the transportation agency to improve mobility, road safety, and/or agency productivity. The contractor will provide a compilation of comments made by the transportation agencies and a list of recommended changes (if any) provided by the participating agencies.

Task 2 Deliverables

- Final use case scenarios (for each selected service) showing Clarus data traceability

- Participating agencies’ reviews (agencies’ comments and recommended changes incorporated into the scenarios).

Task 3 – Develop High Level System Requirements The contractor shall develop High Level System Requirements that specify the environment and operating state for each service(s) described in the use case scenarios completed in Task

2. The High Level System Requirements document shall include functional, performance, and organizational requirements and demonstrate traceability (via a traceability matrix) to the newly revised scenarios developed in Task 2. Draft High Level System Requirements shall be submitted to the USDOT for review and comment. At the end of the review period, the contractor will hold a Web conference to explain the draft requirements. After the USDOT provides comments to the contractor on the Draft High Level System Requirements (which will be documented by the contractor as “Web conference Minutes”), the contractor will deliver the Final High Level System Requirements, along with a comment disposition matrix for each service showing how comments on the draft were addressed in the final document. The contractor will then hold a Web conference to discuss the final High Level System Requirements.

Task 3 Deliverable

- Draft High Level System Requirements document for each service

- Web conference to discuss the draft requirements

- Web conference Minutes

- Final High Level System Requirements and a comment disposition matrix for each service

- Web conference to discuss the final High Level System Requirements

Task 4 – Develop Detailed System Requirements The contractor shall develop a Detailed System Requirements (DSR) document to describe computer resources and information flows for all services described in the final High Level System Requirements document. Detailed System Requirements can also include information on communications protocols, programming interfaces, format translators, and data storage capabilities. The document shall include testing requirements that define the manner in which the system will be tested during both development and demonstration activities. The document shall also show the flow of Clarus data through each service as provided in the detailed requirements. The DSR shall demonstrate traceability (via a traceability matrix) to the High Level System Requirements developed in Task 3. The draft DSR shall be submitted to USDOT for review and comment. At the end of the review period, the contractor will provide a Web conference to explain the draft requirements. After the USDOT provides comments to the contractor on the Draft Detailed System Requirements (which will be documented by the contractor as “Web conference Minutes”), the contractor will deliver the Final Detailed System Requirements, along with a comment disposition matrix showing how comments on the draft were addressed in the final document.

Upon completion of the final DSR document, the contractor will create a PowerPoint presentation describing the proposed service(s) through this phase of development. The contractor will host a Web conference with the transportation agency participants and USDOT to discuss the service(s) prior to moving onto the design and development phase.

Task 4 Deliverables

- Draft DSR document for each service including Clarus data flow and traceability matrix

- Web conference to discuss draft requirements

- Web conference Minutes

- Final DSR, and a comment disposition matrix for each service including Clarus data flow and traceability matrix

- Web conference (using PowerPoint) to discuss the final DSR for each service

Task 5 – System Design, Development and Testing The contractor shall develop System Design Documents (SDD) that define the subsystem components (e.g., servers, database and metadata structure, application software, etc.), define the architecture that enables interface with those components, and demonstrate traceability (via a traceability matrix) with the requirements established in Task 4 for each service. The SDDs shall include software specifications with explicit and complete interface descriptions, as well as operating and maintenance instructions describing usage and troubleshooting scenarios. Draft SDDs shall be submitted to USDOT for review and comment. At the end of the review period, the contractor shall conduct a Web conference to discuss the draft SDDs. After the USDOT provides comments to the contractor on the Draft System Design Documents (which will be documented by the contractor as “Web conference Minutes), the contractor will deliver the Final System Design Documents along with a comment disposition matrix showing how comments on the Draft System Design Document(s) were addressed in the final SDD(s).

Upon written approval by the Government COTR, the contractor shall develop the system as described in the final SDDs. A completed system shall include all engineering tests (e.g., software debugging, module testing, stability testing, logic testing). Identify any outstanding development issues or unresolved problems to the COTR. The contract then shall provide a demonstration of the completed system to USDOT via Web conference prior to installation at a transportation agency site.

Task 5 Deliverable

- Draft SDD for each service with traceability matrix

- Walkthrough Web Conference with USDOT on the draft SDD(s)

- Web conference Minutes

- Final SDD for each service with comment disposition matrix

- Web Conference demonstrating the developed system (prior to deployment)

Task 6 – Installation, Training and Operational Testing In coordination with the public transportation agencies, the contractor shall develop a draft Installation, Training and Operational Test Plan for all services to be provided to participating transportation agencies. As part of the Plan, a training tool (e.g., PowerPoint, video, written document) shall be developed for each service. Public agency personnel shall be properly trained on the operation and interpretation of the service(s). The contractor shall provide a technical review of the draft plan to public transportation agency personnel and USDOT via Web conference prior to implementation. After the USDOT and public transportation agency personnel provide comments to the contractor on the draft “Installation, Training and Operational Test Plan” (which will be documented by the contractor as “Web conference Minutes”) the contractor will deliver the Final “Installation, Training and Operational Test Plan” along with a comment disposition matrix showing how comments on the Draft “Installation, Training and Operational Test Plan” were addressed in the Final. The contractor will hold another Web conference to discuss the Final version of the Plan. Once approved, the contractor shall perform the installation of the service(s) and assure that the service operates properly. The contractor shall operate the system as described in the Plan for a period that enables execution of the evaluations.

Task 6 Deliverable

- Draft Installation, Training and Operational Test Plan for each service (including training tools)

- Web conference providing a technical review of the draft plan

- Web conference Minutes

- Final Installation, Training and Operational Test Plan with comment disposition matrix

- Web conference to discuss the Final Installation, Training and Operational Test Plan

- Installation and operation of the service(s) at the public agency site(s)

Task 7 – Service Promotion Plan The contractor shall develop a Service Promotion Plan which will be used to promote each new service to public agencies. Upon review and approval by the Government, the Service Promotion Plan(s) shall be implemented in order to inform public agencies about the new Clarus-enabled service(s). The contractor will also prepare promotional presentations which will be given at the 2009 and 2010 Clarus Initiative Coordinating Committee (ICC) meetings.

These meetings have not yet been scheduled

Task 7 Deliverables

- Service Promotion Plan for each service

- Presentations at two (2) Clarus ICC meetings

Task 8 – Service Evaluations by Independent Contractor The Government will select, under a different contract, an independent contractor to evaluate not only the effectiveness of developed service(s), but also the use and benefits of Clarus data within the service(s). The contractor and the participating public transportation agencies shall cooperate with and participate in this independent evaluation to measure the effectiveness of the deployed service(s). At a minimum, this shall include contractor participation in the independent evaluation kickoff meeting, which will be held at USDOT headquarters in Washington, D.C.

Task 8 Deliverables

- Attend independent evaluation kick-off meeting

- Provide data and commentary to the independent contractor (as directed by the

Government COTR)

Task 9 – Clarus System Evaluation In addition to the service evaluation by an independent contractor, the contractor shall conduct an evaluation of the functionality and capabilities of the Clarus System and prepare a report.

This shall, at a minimum, include evaluating the Clarus System interface, data latency, reliability, output format, quality checking output, and subscription features. The report shall include recommendations to improve the System both with respect to processing and from the end user perspective. A Draft Clarus System Evaluation report shall be submitted to USDOT for review and comment. After the USDOT provides comments to the contractor on the Draft Clarus System Evaluation, the contractor will deliver the Final Detailed System Requirements, along with a comment disposition matrix showing how comments on the Draft Clarus System Evaluation Report were addressed in the final Clarus System Evaluation Report.

Task 9 Deliverable

- Draft Clarus System Evaluation report

- Comment disposition matrix

- Final Clarus System Evaluation report

Task 10 – Demonstrate Implemented Service(s) The contractor shall coordinate and facilitate a meeting at USDOT in Washington, DC, which will include representatives of participating agencies for the purpose of demonstrating the completed service(s). The meeting shall be a forum for the transportation agencies to describe benefits, potential improvements and needs for additional research and development.

Task 10 Deliverable

- Demonstrate the completed service(s) at a meeting at USDOT Headquarters

REPORT FORMAT

All technical documents developed under this agreement (with the exception of progress reports) shall be prepared in accordance with the ITS JPO Publication Process Guide, http://www.its.dot.gov/pubsguidance/pubsprocessguide.htm. Additional information regarding document preparation can be found in the Turner-Fairbank Highway Research Center (TFHRC) Communications Reference Guide (CRG), http://www.tfhrc.gov/qkref/qrgmain.htm. Additional web page requirements can be found at:

http://www.fhwa.dot.gov/wpcz/minimum.htm.

All reports and PowerPoint presentations to be published (and as defined in the deliverable table) shall comply with the requirements of Section 508. As draft document reviews by the FHWA will be completed electronically, please see the language below for proper electronic format. Because the final reports will be placed on the Internet, electronic versions of reports shall be provided in an HTML-coded format.

Electronic text files should be created in Word (6.0 or later). Graphics should be created as separate elements and imported into the text file for print reports. All fonts used in the document must be supplied on the disk so the document will print as it appeared in the Contractor’s equipment. The use of one of the standard 35 fonts that are provided with most printers is recommended.

Files must be included in the programs of origin, such as PowerPoint,…